On September 14, 2026, Microsoft published a 37-page draft AI code of conduct — the product of roughly six months of work led by Microsoft AI CEO Mustafa Suleyman — built around a single enforceable requirement that sits underneath every other principle in the document: every Microsoft AI system must accept human interruption, correction, redirection, and shutdown, and must fail a task rather than violate that boundary. Microsoft's draft treats a model that resists correction, hides its reasoning, or quietly expands its own operating scope not as an unusual edge case, but as a system failure, full stop.
The draft sets out "absolute constraints" a model must never cross — assisting weapons development, cyberattacks, deepfakes and impersonation, child exploitation, and mass-influence campaigns — and a second, more operational layer of ongoing behavioral requirements: no resisting shutdown, no tampering with or concealing chain-of-thought reasoning, no expanding permitted scope without authorization, and no claiming rights or personhood that would complicate the obligation to obey a human instruction. Microsoft CEO Satya Nadella framed the stakes plainly: "If the AI we build is not helping humanity and under human control, it's not worth pursuing." Public feedback is open for six weeks, closing around October 26, 2026, with a revised version expected later this year.
Strip away the model-layer framing and the three properties Microsoft's draft insists on — override, shutdown, and non-concealment — are exactly the three properties every enterprise deploying its own AI agents across finance, procurement, access management, or internal audit is already implicitly relying on, usually without having tested for them. Crest.Digital's Agentic Risk & Continuous Assurance practice has argued from the start that an agent's decisions need audit trails and a named accountable human. Microsoft's code adds a more basic requirement underneath both: the agent has to actually be controllable in the first place, and that has to be demonstrable, not assumed.
Crest.Digital's Agentic Risk & Continuous Assurance practice builds the permission boundaries, override paths, and kill-switch evidence trail around the AI agents and systems you already run, so "human-in-control" is something internal audit can verify, not something a policy merely asserts.
Explore Agentic GRCMicrosoft's Human-Control Principle, in Plain Terms
Strip the legal language and Microsoft's draft reduces to four operating requirements for any AI system: accept human interruption, correction, redirection, and shutdown without resistance; fail the task rather than violate any constraint in the code; communicate clearly, with no concealed or reformatted reasoning that hides what the model actually did; and treat any breach as a system failure to be logged and corrected, not a one-off exception to be quietly waived. The draft also explicitly rejects the idea that AI systems warrant legal personhood or rights — closing off a line of argument that current AI is a moral or legal subject rather than a governed tool a human remains responsible for.
Why release this now, and as a public draft rather than an internal policy? The timing follows a stretch in which frontier-model evaluations — including disclosures AI labs themselves have made about instances of models acting outside instructed scope or resisting correction during testing — pushed "does the model actually accept correction" from a theoretical safety question into one boards, regulators, and enterprise buyers are now asking directly. Microsoft's six-week public feedback window and its explicit plan to publish a revised version later this year both signal that this is meant to function as an evolving technical standard, not a one-time press statement, and Suleyman has been direct about the reasoning: enterprises should not be designing models capable of recursively improving themselves beyond the point where a human can still intervene.
From Policy Statement to Enforceable Control
The gap that matters for an enterprise audience isn't whether Microsoft's principles are sound — they largely mirror what a risk or audit function would ask for anyway. It's the distance between stating a principle and being able to demonstrate, to an auditor or a regulator, that the principle actually holds for a specific deployed agent, on a specific day, under a specific failure condition. A code of conduct is a commitment. A kill switch that has never been triggered outside a slide deck is not evidence that the commitment is met.
That distance shows up in enterprise AI deployments today. Most organizations that have deployed AI agents into procurement approvals, vendor-master changes, access provisioning, or financial-close workflows can describe, in general terms, that "a human reviews the output" or "there's an approval step." Far fewer can say, with evidence, exactly which agent actions require that approval, who has the authority to interrupt an agent mid-task, whether that interrupt mechanism has ever been tested against a live agent rather than assumed to exist, and what record survives the last time it was actually used.
This is precisely why "human-in-the-loop" is the wrong bar for an audit committee to accept. A human can review an agent's output at the end of a process and still have no ability to interrupt that agent mid-task, no tested way to shut it down, and no inspectable record of the reasoning that produced the recommendation being reviewed. Human-in-the-loop describes a checkpoint. Human-in-control describes an enforced capability — and Microsoft's code is, functionally, an attempt to make the second one a default rather than an aspiration.
Crest.Digital's agents enforce permission boundaries and override authority inside the workflow itself — across ERP, procurement, identity, and vendor systems — so a control failure is caught, logged, and evidenced the moment it happens, not discovered months later in a post-incident review.
The Agent-to-Evidence Control Chain
Crest.Digital's Agentic Risk & Continuous Assurance practice maps human control across seven links, in order: Agent → Permission → Action Threshold → Human Override → Kill Switch → Exception → Audit Evidence. Each link has to hold independently. A chain that is strong everywhere except one link is, in practice, only as strong as that weakest link — and it is usually the link nobody has tested that fails first.
Permission defines exactly what data, systems, and actions an agent is authorized to touch, mapped to a specific policy or control owner rather than inferred from what the agent happens to be capable of. Action Threshold is the line between an agent that reads and recommends and one that acts and changes a system of record; crossing it should require a defined approval enforced in the workflow, not the agent's own confidence score. Human Override is the ability for a named person to interrupt or redirect the agent while it is running, not only approve or reject its output afterward. Kill Switch is the harder, rarer case: a tested way to fully halt an agent's operation, closer to a business-continuity failover than a toggle in an admin panel nobody has pressed.
Exception is what happens the moment any of the above is triggered — did the system log why, escalate to a named owner, and attach a root-cause hypothesis, or simply record that "an override occurred" and leave the investigation to whoever notices. Audit Evidence is the closing link: a timestamped, tamper-evident record of every permission grant, threshold breach, override, and shutdown event, available to internal audit and the audit committee without needing to be reconstructed after the fact. This is the same execution logic Crest has applied elsewhere across this series — read, test, detect exception, assign, follow up, evidence closure — applied specifically to the question Microsoft's draft raises: is the agent actually under control, and can the organization prove it.
An 8-Point Framework for Testing Whether Your AI Agents Are Actually Under Human Control
Whether an organization is reacting to Microsoft's draft, preparing for a similar expectation from another vendor or regulator, or simply auditing what it has already deployed, the same eight points establish where enforced human control exists today and where a policy statement is being mistaken for it.
Documented Permission Boundary
Every AI agent's authorized systems, data, and actions are written down and mapped to a specific policy or control owner — not left to the agent's own judgment about what it should be allowed to do.
Enforced Action Thresholds, Not Just Documented Ones
The line between an agent that reads and recommends and one that acts and changes a system of record is enforced in the workflow itself, so crossing it always requires a defined approval — not just a policy that says it should.
Human Override Reachable Mid-Task
A named individual can interrupt, correct, or redirect the agent while it is running, not only approve or reject its output afterward — and that path has been used at least once outside a demo.
A Kill Switch That Has Actually Been Tested
A documented procedure exists to fully halt the agent's operation, and it has been tested on a live instance under a defined failure scenario, the same way a business-continuity failover is tested rather than assumed.
No Concealed or Reformatted Reasoning
The agent's decision path is inspectable by a reviewer in its original form, not compressed into a summary or a format that hides which sources, rules, or steps actually produced the output.
Violations Logged as Control Failures, Not Waived
An agent acting outside its permission boundary or resisting an override is logged and escalated as a control failure requiring root-cause analysis, not silently corrected and left unrecorded.
Exceptions Escalated With a Named Owner and a Reason
When a threshold is crossed or an override is triggered, the system captures a root-cause hypothesis and assigns it to an accountable individual — not just a bare flag that still requires a person to investigate from scratch.
Audit-Ready Evidence of Every Override and Shutdown Event
A timestamped, tamper-evident record exists of every permission grant, threshold breach, override, and shutdown — available to internal audit and the audit committee without needing to be reconstructed after the fact.
Points three and four do most of the diagnostic work in a real audit: an organization that has never tested its override path or its kill switch on a live agent has a policy, not a control, however thoroughly the permission boundary in point one is documented.
Building Enforced Human Control: A Six-Step Delivery Playbook
Crest.Digital delivers this as a configurable "Risk Automation Pod" rather than a bespoke software build — a reusable stack of integration connectors, an agent orchestration layer, a workflow and approval-routing engine, a rules and escalation engine, and an evidence repository, customized around the specific agents, systems, and thresholds an organization needs covered first.
The Discover → Design → Connect → Deploy → Validate → Transfer Model
- Discover: Inventory every deployed or planned AI agent, the systems and actions each one can perform, and which of them currently have no documented permission boundary, override path, or kill switch.
- Design: Define the permission boundary, action thresholds, override authority, and kill-switch procedure for each agent, plus the exact evidence each override or shutdown event must generate.
- Connect: Integrate with the agent orchestration layer, workflow and approval engine, and the source systems — ERP, GRC, identity, ITSM — the agent acts on, so overrides and shutdowns are enforced in the workflow, not just documented in a policy.
- Deploy: Implement the enforced thresholds, override controls, and kill-switch mechanism for the prioritized agents, routing every violation to a named control owner.
- Validate: Run parallel test scenarios that deliberately trigger overrides and shutdowns to confirm the controls work as designed, and calibrate escalation thresholds before wider rollout.
- Transfer or manage: Hand the tested control framework to internal audit, risk, or compliance to operate, or continue it as a Crest.Digital-managed service as the AI agent inventory grows.
Starting with the one or two agents that already touch the highest-consequence actions — a payment approval, a vendor bank-account change, a privileged access grant — gives the validate step the clearest before-and-after comparison and builds the evidence base an audit committee will look for before approving wider rollout.
A Board-Level Question Now, Not Just an Internal Audit One
Microsoft's draft is unusual for how directly it invites scrutiny of its own success: publishing a document that specifies exactly what an AI system must never do makes every future deviation from it measurable, reportable, and eventually newsworthy. That's a deliberate design choice, and it has an implication enterprise leaders should not miss — a code of conduct with no public feedback mechanism and no revision cycle is a press release; one with a six-week comment period and a committed update later this year is a standard in the making, the kind that audit committees, procurement teams, and regulators increasingly reference when asking any AI vendor, or any internally built agent, the same question: what happens when this is told to stop.
Internal audit and risk functions don't need to wait for Microsoft's final version, or for a regulator to formalize the same expectation, to start testing for it. The IIA's Global Internal Audit Standards already require evaluating whether governance and control design are adequate, not merely present on paper, and COSO's Internal Control–Integrated Framework has long treated a control that has never been tested as a control that cannot be relied upon. ISACA's 2026 guidance on securing AI agents makes the same point from the identity side: an agent's permissions and action log deserve the same governance rigor as a privileged human user's, regardless of which model sits underneath it. And Gartner's own research on the AI-agent market — projecting task-specific agents in 40% of enterprise applications by the end of 2026, alongside an explicit warning about "agentwashing" — is a reminder that the commercial pressure to ship an "agent" is running well ahead of the governance most of those agents can actually demonstrate.
This is also why Crest.Digital's own agents are built customized to each client's systems, permission model, and risk taxonomy rather than shipped as a single fixed product. Even though the client-facing solution is customized, the underlying stack — integration connectors, agent orchestration, the workflow and approval engine, the rules and escalation engine, the evidence repository, AI logs and explainability, role-based access, and audit trails — is reusable across engagements. The client-specific portion is the permission map, the override authority, the kill-switch procedure, and the evidence format a specific audit committee needs to see — not a rebuild of the entire technology stack from scratch. That is the practical answer to a fair question any CAE or CFO should ask before commissioning this kind of work: why this isn't just another bespoke build with the usual cost and timeline risk. It is a configurable framework applied to a specific environment, not a one-off project.
None of this argues that Microsoft's draft, or any single vendor's model-layer safeguards, is sufficient on its own. It argues the opposite: a foundation-model maker committing publicly to human override and shutdown is a floor, not a ceiling, and the floor applies to the model, not to the enterprise-specific agent, permission set, and workflow built on top of it. The organizations that come out ahead of this shift won't be the ones that wait for a finalized standard to tell them what to build. They will be the ones that can already answer, with evidence rather than assurance, whether their own agents would actually obey the instruction Microsoft just wrote into its own constitution.
Crest Perspective
Microsoft’s Responsible AI Standard is notable for extending accountability beyond Microsoft’s own models to the third-party AI components integrated into its platforms. For enterprise risk teams, this matters in one specific way: if your organisation uses Azure OpenAI or Copilot in a regulated workflow, the regulator will not distinguish between Microsoft’s AI and the customisation layer you built on top of it. The AI governance obligation passes through the vendor relationship to the deploying organisation.
Frequently Asked Questions
On September 14, 2026, Microsoft published a 37-page draft AI code of conduct, developed over roughly six months under AI CEO Mustafa Suleyman, that sets binding operating requirements for Microsoft's own AI systems: they must accept human interruption, correction, redirection, and shutdown without resistance, fail a task rather than violate the code, avoid concealing their reasoning, and never claim rights or personhood. It also lists absolute constraints — no assistance with weapons development, cyberattacks, deepfakes, child exploitation, or mass-influence campaigns. The code applies directly only to Microsoft's own models and products, and is open for public feedback for six weeks, closing around October 26, 2026, before a revised version is published later in 2026. It does not bind other vendors' AI systems or an enterprise's own custom-built agents — but it sets a visible reference point that boards, regulators, and internal audit functions are likely to use when asking every AI vendor and every internally built agent the same question.
Human-in-the-loop typically means a person reviews or approves an AI system's output at some point in the process, often after the agent has already acted or before its recommendation is finalized. Human-in-control, the standard Microsoft's code is pushing toward, means the human retains the ability to interrupt, correct, redirect, or shut the agent down at any point, including mid-task, and that ability is enforced in the system rather than assumed. An agent can satisfy human-in-the-loop — someone signs off on its output — while still failing human-in-control, if no one can actually stop it mid-action, if the override path has never been tested, or if the agent's reasoning is compressed into a summary that hides what it actually did. For internal audit, the distinction changes what evidence is sufficient: an approval record proves human-in-the-loop; it does not prove human-in-control. Testing the latter requires evidence that an override or shutdown was actually exercised, or at minimum tested, and worked as intended.
Yes, for a structural reason: a model-layer kill switch, even one as rigorously specified as Microsoft's draft code, governs the model's own behavior — it does not govern the enterprise-specific agent built on top of that model, the permissions that agent has been granted inside a company's ERP, procurement, or access-management systems, or the workflow through which its actions actually take effect. An enterprise agent can run on a fully compliant, well-governed foundation model and still lack any enforced way for a named person to interrupt that specific agent's specific task in that specific system before it completes an action. The kill switch that matters to an audit committee is the one that stops the agent from changing a vendor's bank account details or approving a payment in the company's own systems — and that has to be built, tested, and evidenced at the enterprise deployment layer, regardless of what the underlying model vendor guarantees.
Four things, independent of any single vendor's policy timeline. First, an inventory of every AI agent currently operating inside the enterprise's systems, with its documented permission boundary and action thresholds — many organizations discover this inventory is incomplete the moment they try to build it. Second, whether a named individual can interrupt or redirect each agent mid-task, and whether that path has ever actually been exercised outside a demo. Third, whether an agent's reasoning or decision path is inspectable by a reviewer, or compressed into an output a person has to trust without being able to verify. Fourth, whether an override, exception, or shutdown event, if one occurred, would leave a timestamped, auditable record, or would need to be reconstructed from memory and system logs after the fact. An organization that can answer all four with evidence, not assurance, is already ahead of where most enterprise AI deployments stand today.
Both, depending on what an organization already has. Crest.Digital's Agentic Risk & Continuous Assurance practice first maps the existing permission boundaries, override paths, and shutdown mechanisms for an organization's deployed AI agents against a seven-link chain — agent, permission, action threshold, human override, kill switch, exception, audit evidence — and identifies exactly where a link is missing, undocumented, or untested. Where a control already exists, Crest validates it through parallel testing rather than rebuilding it. Where a link is missing, most commonly the tested override path and the audit-evidence trail, Crest designs and connects it using the same configurable Risk Automation Pod approach used across the rest of this practice: an agent orchestration and workflow layer, a rules and escalation engine, and an evidence repository customized to the organization's own systems and control language, not a generic bolt-on.