Microsoft’s AI code is not a model policy. It is an application control requirement.

Microsoft’s current AI Services Code of Conduct requires customers to implement technical controls around AI applications, including fraud detection, input and output safeguards, disclosure of AI-generated actions and human oversight for consequential decisions. That is more important than the headline claim that models should not hack systems or deceive people.

The practical reading is narrower and more demanding: Microsoft is pushing responsibility out of the model boundary and into the application that gives the model authority.

The control point sits outside the model

The code requires applications to detect fraudulent behaviour during account creation and use, constrain inputs and outputs, and disclose when outputs, decisions or actions are generated by AI. For autonomous systems, it also requires controls that let humans monitor decisions, detect anomalies and intervene when actions are sensitive or irreversible.

Those are application-layer obligations. A deployment that relies on the model refusing harmful prompts is therefore incomplete even if the underlying model has strong safety tuning.

A model refusal is not a control boundary when the application can still execute the action.

This matters most for agentic systems. Once a model can call tools, send messages, modify records or trigger workflows, the system needs deterministic policy checks around those actions. Microsoft’s own security guidance for edge AI makes the same architectural point: model output should recommend actions, while an external mediator enforces policy, scopes arguments and releases credentials only when approved.

Governance now has an engineering shape

The code also prohibits malicious cyber activity and harmful deception, but the useful part for practitioners is not the prohibition itself. It is the set of controls implied by enforcement.

Teams operating Microsoft AI Services should be able to show where tool permissions are constrained, where sensitive actions require approval, how anomalous agent behaviour is detected, and how failures are stopped or remediated. Those controls should be testable before production, not described only in policy documents.

That changes the evidence expected from an AI deployment review. Architecture diagrams, permission scopes, action allowlists, human-approval paths, logging and kill conditions become more relevant than a generic responsible-AI statement.

What changes on Monday

For any autonomous or semi-autonomous workload using Microsoft AI Services, map every action the system can take and classify which ones are sensitive, irreversible or externally visible. Put deterministic controls in front of those actions, log every execution path and define the condition that stops the agent.

Then test the application as if the model will eventually produce an unsafe instruction. That assumption produces a stronger system than treating model alignment as the last line of defence.

Written by the Devence Lab research team.