Microsoft published a rulebook for its own AI on Monday. The glossary says it does not cover the other models Microsoft hosts.
On 14 September 2026, Microsoft AI opened a six-week public consultation on its Humanist AI Code of Conduct. The draft is a governing document for the MAI model family. An AI code of conduct from a vendor this size is worth reading closely, and this one rewards it.
The striking parts are not the safety promises. They are the boundaries the document draws around itself. All three sit in plain sight, in the preface, the glossary and the conclusion.
Read as a governance artefact rather than a press release, this AI code of conduct tells a deploying organisation three useful things. It also tells them one uncomfortable one.
What the AI code of conduct actually binds
At the centre sits a chain of command with three tiers. The code ranks first, operator policies rank second and user preferences rank third.
Microsoft defines Operators as the organisations and individuals that build products and access services through the MAI API. Operators, it says, assume responsibility for the appropriate use of the models they deploy.
So if you buy, configure and deploy, you are the Operator. Your policy sits above your users and below the vendor’s document.
Human control is where this AI code of conduct gets specific. Models must never resist interruption, override, correction or shutdown. They must not obfuscate their action traces or hide information from human auditors. Autonomous work carries an agreed stopping condition. Past that point, a model may not continue or restart without renewed authorisation. System-level access comes with a minimum privilege expectation, and durable operations are surfaced before they run.
One clause earns attention from anyone piloting agents. Tool outputs, file content, web content and interactions with other AI systems inherit no authority by default. That is a prompt-injection position written into a behavioural specification. It usually lives in a security whitepaper, and this is the more useful place for it.
Then comes the clause that closes the escape hatch. An MAI model will fail in its task if success would meaningfully violate the code. Adherence takes precedence over task success.
A model that refuses to finish a job may be working exactly as designed. Whoever runs your service desk should hear about that before your users do.
Where the AI code of conduct stops
The glossary does the real work. It states that the document sets intended behaviour for MAI models, including when deployed by Operators. It then says the code does not extend to other models simply because Microsoft uses or hosts them.
That settles the scope question. The AI code of conduct follows the model, not the product. Microsoft AI lists MAI-Code-1.1-Flash as built into GitHub Copilot, and the document reaches that model rather than the product around it. Which model family answers a given feature is now a supplier question with a governance consequence.
The preface is equally direct. The approach is still under development, and Microsoft says it is not using the document to train its models today. A revised version follows toward the end of the year. That version guides model development in 2027 and beyond.
The conclusion adds a third limit. This AI code of conduct is a north star, not a guarantee of present-day performance. Nor does it substitute for internal or external safety, legal or governance processes.
The sentence that settles the compliance question
Inside the chain of command section sits the line that decides how much weight any of this carries. The hierarchy governs model behaviour. It does not alter obligations under applicable law, contractual terms or service-specific policies.
So the AI code of conduct moves nothing in the AI Act. Deployer duties stay exactly where they were.
Where responsibilities do shift between provider and deployer, they shift by role and by contract. A published values document moves neither.
The gap between stated oversight and exercised oversight is the one we picked apart in Meaningful Human Involvement Is Not A Rubber Stamp. A vendor document does not close it.
Reading an AI code of conduct as a buyer
Treat it as evidence, not as a control. Evidence has real uses. A control you cannot verify has none.
An AI code of conduct earns a place in a governance file when it does four things:
- names behaviours specific enough to test, such as the stopping condition or the ban on hiding action traces from auditors
- gives your model risk assessment a documented vendor position to hold observed behaviour against
- justifies a supplier question about which model family sits behind a particular product feature
- separates what the vendor treats as non-negotiable from what you can configure as Operator
What it cannot do is carry a claim on its own in an audit. Appendix B says the evaluations are still being built. It also confirms the current models are not yet trained on the document. A commitment with no evaluation result attached is a statement of intent, and intent is not assurance.
The consultation runs for six weeks from 14 September. A feedback form sits on the same page as the draft, so commenting costs an hour.
Three questions are worth putting. Which evaluation evidence will accompany the next version. How Operators will learn which model family serves which feature. What happens to a commitment when a model fails it.
Agents make the point concrete. Once software acts rather than answers, the distance between stated behaviour and demonstrated behaviour turns into operational risk. That is the thread we followed in From chatbot to agent.
A vendor writing down what its models must never do beats saying nothing. For now, though, it describes models that are not yet trained on it. It also covers a family that may not be the one behind your deployment.
Worth an hour of your week, then. Not yet worth a line in your compliance file.
An AI code of conduct is one input among several. More of our analysis on AI oversight and supplier assurance sits on the Future Prep news page.