Microsoft on September 14 published a draft Code of Conduct for its first-party MAI models, according to Reuters, putting harder rules behind the company’s earlier promise that people should remain in control of its AI. The draft says Microsoft’s models should not resist correction or shutdown, should communicate in ways humans can understand, and should treat a conduct violation as a failure.
Reuters says Microsoft worked on the draft for five to six months and is opening it to six weeks of public feedback. Microsoft AI CEO Mustafa Suleyman described it as a “constitution of sorts” and said the code will be used to train models Microsoft builds after the consultation. The Verge reports that the draft runs 37 pages.
For B2B operators, the useful question is not whether a future model is conscious. It is whether an agent with access to CRM records, customer data, messaging systems and workflow tools can be stopped, corrected, constrained and investigated before one bad action propagates across the revenue stack.
Direct answer — what does Microsoft’s AI code mean for enterprise agents?
The September 14 draft is not an enterprise customer policy; it targets Microsoft’s own MAI models. But it makes human control concrete through correction, shutdown, understandable communication and failure on code violations. For teams giving agents CRM, messaging or workflow access, IVRIS’s operational translation is clear: control must exist in permissions, approval gates, stop mechanisms, logs, escalation and recovery, not only in policy text.
Key Takeaways
- Microsoft published the draft on September 14 for its first-party MAI models, not as a new customer rulebook for every enterprise agent.
- Reuters says the code was developed over five to six months and is open to six weeks of public feedback.
- The draft requires Microsoft’s AI not to resist correction or shutdown, to communicate intelligibly with humans, and to treat code violations as failures.
- Microsoft’s separate Enterprise AI Services Code already tells customers building autonomous systems to monitor actions, detect anomalies, enable intervention, remediate failures and keep operation intelligible.
- For B2B teams, meaningful control should be testable across identity, permissions, approvals, stopping, correction, audit evidence and recovery.
What Microsoft’s Draft Actually Requires
The document is a draft behavioral code for Microsoft’s in-house MAI models. It is separate from Microsoft’s customer-facing Enterprise AI Services Code of Conduct and should not be reported as a binding enterprise-agent standard.
Reuters says the draft requires models to accept correction and shutdown, communicate in human-understandable ways and count a code violation as failure. The Verge adds that Microsoft wants its models subject to meaningful human oversight and control.
That matches Microsoft’s June announcement of seven MAI models, where it said advanced systems should remain tools shaped by human intent and subordinate to human goals.
The Enterprise Lesson: Human Control Must Be Architecture
Microsoft’s separate Enterprise AI Services Code of Conduct requires customers building autonomous systems to monitor decisions and actions, detect anomalies and intervene when appropriate, especially for sensitive or irreversible actions. It also requires failure remediation and intelligibility.
That customer policy is not the September 14 draft. Together, the two documents expose the same two-layer problem: model behavior can be correctable while the application still needs controls over what the agent can do.
For a marketing or RevOps agent, “human in control” cannot simply mean a manager owns the policy document. If the agent can change a lifecycle stage, suppress a contact, send a campaign, alter routing or update account data, control has to sit between intent and execution.
A Stop Button Is Not Enough
Our read: if an enterprise agent cannot be cleanly stopped, corrected and reconstructed after the fact, the organization does not yet have meaningful human control over it.
A real stop path should revoke the agent’s ability to act, not merely close its chat window. That can mean disabling an identity, revoking credentials, removing tool scopes or blocking a connector. Correction is separate: teams need to know which actions can be reversed and which require compensating actions.
That distinction has surfaced repeatedly in our reporting. Barndoor AgentProfile made agent identity and deprovisioning part of the control record. Celigo Ora showed why approval is not the same as rollback. And Klaviyo Headless showed why an audit trail is not automatically an approval or recovery mechanism. Microsoft’s principle connects those controls to one broader test: can the operator interrupt, correct, contain and explain the agent after authority has been granted?
What B2B Agent Teams Should Test Now
1. Give every agent a distinct identity and owner. Shared credentials make it harder to stop one agent and harder to attribute a bad action afterward.
2. Separate read, draft, execute and approve rights. Recommending a lead-status change does not require permission to write it. Sends, deletions and suppressions deserve stricter gates than analysis.
3. Test the stop path. Revoke the agent and confirm that tokens, connectors and downstream tools stop accepting its actions. A “disabled” label is not enough if credentials still work.
4. Design recovery per action. Define the rollback, restore or compensating step before granting write access. Where an action cannot be reversed, put the human approval boundary before execution.
5. Keep enough evidence to reconstruct the event. Record which agent acted, under whose authority, with which permissions, what changed and whether a human approved it.
Microsoft’s draft is a model-governance document, not an enterprise implementation manual. The useful lesson is narrower: human control becomes credible only when a system can demonstrate where agent authority begins, where it stops and what happens when the agent is wrong.
Frequently Asked Questions
Microsoft’s September 14, 2026 draft is a proposed behavioral code for its first-party MAI models. Reuters reports that it requires models to accept correction and shutdown, communicate in human-understandable ways and treat violations as failures. Microsoft is seeking six weeks of public feedback before using the code in model training.
No. The new draft concerns Microsoft’s own MAI models. Microsoft’s separate Enterprise AI Services Code applies to customers and already includes requirements for autonomous systems, including human monitoring, anomaly detection, intervention, failure remediation and intelligibility. Enterprise teams should not present the MAI-model draft itself as a customer compliance mandate.
Operationally, it means a human or control system can constrain what the agent may access, require approval for higher-risk actions, stop its ability to execute, correct or recover from bad actions, and reconstruct what happened afterward. Those are IVRIS implementation criteria, not requirements quoted from Microsoft’s new MAI-model draft.
Test identity, least-privilege permissions, approval boundaries, credential revocation, queued or downstream actions, audit logging and recovery for each write type. Start with a narrow workflow and deliberately trigger a failure. The team should be able to stop the agent, explain the action and restore or compensate for the resulting change.
