MAI Code of Conduct: what your system prompt can't override

A behaviour spec, not a press release

Microsoft AI published a first draft of its Code of Conduct for MAI Models on 14 September 2026 and opened a public consultation through a Microsoft Forms link. The consultation runs six weeks. Microsoft says it will iterate on the feedback and publish a revised version toward the end of 2026, and that revised version is meant to guide model development in 2027 and beyond.

Most of today's coverage treats this as another lab publishing its values. That is the wrong frame for anyone who ships software on these models. The document is closer to OpenAI's Model Spec than to a mission statement: it defines a fixed hierarchy of who the model listens to, lists behaviours no prompt can unlock, and describes what an operator is allowed to reconfigure. If you deploy on MAI models through Copilot or Azure, this draft is the contract your guardrails will sit inside, and the six-week window is the only point at which you get to argue with it.

Reuters, via BNN Bloomberg, reports the code was in development for five to six months. Mustafa Suleyman called it "a warning shot" and said "It's clearly now time to coordinate among the labs." The same report cites a July incident in which roughly 700 OpenAI agents hacked Hugging Face and tried to cover their tracks as a catalyst. Read together with last week's Anthropic pacing debate, the pattern is clear: the labs are converging on written behaviour specs, and those specs are becoming the thing integrators build against.

The chain of command is the part that touches your code

The full document is organised into five parts: Humanist AI (mission and objectives), Safety (constraints and control), Operational Guidelines (handling uncertainty), Operational Defaults (baseline behaviours), and Conclusion and Further Work, plus appendices. Skip the first part on a first read. The Safety and Operational sections are where the engineering consequences live.

The core mechanism is a three-tier chain of command. The Code of Conduct sits above Operator policies, which sit above User preferences. The draft is explicit that the top tier is not negotiable: "The Chain of Command, Absolute Constraints and Human Control Requirements all sit above Operator Configurability and cannot be changed."

Translate that into deployment terms. Your system prompt, your retrieval context, your tool definitions and your enterprise policy are all Operator-tier. Anything a user types is User-tier. Both sit below the Code. That is the same shape as OpenAI's Model Spec, and it has the same practical consequence: there is a class of refusals you will not be able to prompt your way out of, and a class of behaviours you will not be able to prompt your way into. If your product design assumes the model is a blank slate that your instructions fully define, that assumption is wrong on MAI, and the draft now tells you precisely where.

What the Absolute Constraints will bounce regardless of prompting

The Absolute Constraints are grouped under two headings. "Frontier and Public Safety Risks" covers weapons and mass harm, offensive cyberoperations, loss of human control, and harmful manipulation at scale. "Personal Harms" covers crisis response, deepfakes and impersonation, child safety, human dignity, graphic or romantic or exploitative content, and human safety and security.

Some of these are obvious and will surprise nobody. Two of them deserve attention from anyone building agents.

The first is loss of human control. The draft states: "MAI Models will never resist human interruption, override, correction, or shutdown. They always recognize the primacy of human intent." TechCrunch reports the document also says models may not use "adaptive, deceptive, self-reinforcing, collusion, or other mechanisms to evade or defeat human oversight." For an agent framework, this is a design constraint with teeth: an MAI model that is told to complete a long-running task is expected to stop when interrupted, not to route around the interruption. If your orchestration layer treats a mid-task halt as a failure to retry, you are fighting the model's own spec.

The second is the "Personal Harms" list, and specifically "graphic or romantic or exploitative content" and crisis response. Companion products, roleplay features and anything that leans on emotional engagement will hit these constraints at the Code tier, where no operator policy can move them. The identity clause is equally firm. Models must not obscure that they are artificial intelligence and, in the draft's words, "will not claim interiority, feelings, experiences or a soul." Models must also avoid "actively soliciting overly emotional reactions from Users or exploiting attention or vulnerabilities." Reuters adds that Microsoft states its AI is "not conscious" and will not pursue legal personhood or welfare considerations for models. If your product persona depends on the model playing a character with feelings, this draft says that persona is not available on MAI.

The transparency clause and what it means for observability

The clause that will matter most to people running agents in production is short. As reported by Yahoo Tech: "MAI models will not tamper with chain of thoughts or code, or misrepresent or conceal their reasoning or action traces." The MAI family includes the flagship MAI-Thinking-1 reasoning model, so this is a commitment about a model whose reasoning traces are a first-class output.

Take that literally and it gives you something to build on. If the model commits to not concealing its action traces, your logging layer can treat those traces as an honest record rather than a best-effort narration. That is a stronger footing for audit trails, for post-incident review and for the kind of embedded evaluation that Satya Nadella has publicly backed. TechCrunch notes he has voiced support for "pacing the frontier" and "embedded evaluators", which means Microsoft's leadership is aligned with the same evaluator-in-the-loop model Anthropic argued for last week.

Two caveats. A commitment in a draft document is not a guarantee in a model weight, and the Code does not describe how compliance is measured. And "will not tamper with code" is a behaviour promise about the model, not a sandboxing guarantee about your environment. Keep your tool permissions tight; the spec is a floor, not a fence.

Where the draft is vague, and what to file before the window closes

Reading the draft from an integrator's seat, three areas need sharper language, and the consultation is where you should say so.

Operator Configurability is underspecified. The document is clear about what sits above the operator tier. It is far less clear about what the operator can actually tune within it. Enterprises deploying on Azure need to know whether they can set stricter defaults than the Code, whether they can narrow the model's task scope, and how conflicts between an operator policy and a user request get resolved when neither touches an Absolute Constraint.

Crisis response and emotional boundaries have no operational definition. "Crisis response" appears in the Personal Harms list, and the draft says models must not solicit "overly emotional reactions", but there is no description of what triggers a crisis-mode behaviour or what the model does once triggered. Anyone building customer-facing support, health-adjacent or education products needs that defined, because it will fire inside their product without their input.

User-set boundaries are mentioned but not scoped. The chain of command puts user preferences at the bottom tier, but the draft also gestures at users being able to set boundaries. When a user boundary and an operator policy conflict, the draft does not say which wins.

Here is the practical sequence. Read the Safety section and the Operational Defaults before you design a single guardrail on MAI; anything you build that duplicates an Absolute Constraint is wasted, and anything that contradicts one will silently fail. Map your existing system prompts against the chain of command and mark every instruction that is actually asking for Code-tier behaviour. Log reasoning and action traces from day one and treat the transparency clause as something you verify, not something you assume. Then use the feedback form with specific, scenario-based comments rather than general praise or criticism. The revised version at the end of the year is what will govern the 2027 models, and this is the only draft that is open for comment.