Nadella says treat AI models as insider risks. His emergency brake comes too late for most of your actions.
Satya Nadella just told every company running AI agents to treat the model like an insider risk. He is right. But the emergency brake that made the headlines only works on actions slow enough to catch, and most of the actions your agents take are not.
On Saturday Microsoft's CEO posted a long piece on X titled "Models as Insider Risks in Super Intelligence Era"1. TechCrunch led with the brake2. His argument: nobody can trace a model's output back to a code path, the way you could with old software. Yet companies are giving agents "access to our most sensitive data" and "the ability to take mission-critical actions on our behalf"1.
So treat the model the way you treat a powerful employee. "Not because they are necessarily malicious," he wrote, "but because any sufficiently capable actor with access to important systems can make mistakes or be compromised"1.
The line worth pinning to your wall
In his words, "we need to separate the supply of intelligence from the authority over it"1.
That sentence settles a lot of vendor arguments. The model supplies the intelligence. Your company keeps the authority. Nadella makes it concrete: the controls that govern "what a model can access and what actions it can take must sit outside the model"1. A system prompt that says "never pay a new vendor" is not a control. It is a request.
He also closes a door many teams lean on. "A model provider's assurances do not relieve us of that responsibility"1. Your vendor's safety card is not your control. If your agent pays the wrong account, the model provider is not the one explaining it to your auditor.
Seven principles, one gap
Nadella lists seven principles: model diversity, observe everything, verifiability, independent controls, independent auditability, containment, and incident disclosure1. Most map straight onto a working setup.
"Every meaningful model action must leave tamper-proof human readable evidence"1. That is a record you can read without asking the agent what it did. He goes further: you must be able to reproduce an outcome "without relying on the model to attest to it"1. An agent's own summary of its work does not count.
"No single model should control both a system's behavior and the evidence required to determine whether that behavior is aligned with the original intent"1. That is segregation of duties, applied to software.
Then the brake. "We must assume a model is compromised and contain it from the start. Think of it like an emergency brake. An authorized person should always be able to pause or shut down a model mid-task"1.
Here is the gap. A brake works on things that take time. Your AP agent's vendor bank change is one API call. A refund is one call. An email to a customer is one call. By the time a person sees the alert, opens the console and finds the right button, the money has left.
The brake is for the long task going wrong slowly. A migration that is deleting the wrong rows. An agent looping through a supplier list. For the single action you cannot take back, the stop has to come before the action, not during it. The agent asks. A named person says yes or no. Nothing moves until they do.
Nadella's "independent controls" principle comes close. Orgs should be able "to independently determine what a model can access and what actions it can take"1. But deciding what an agent may do, once, in an admin screen, is permission. Deciding whether this payment to this account goes out today is approval. You need both.
What to check this week
1. Sort your actions by how fast they finish. Take one agent that can change records or move money. List what it can do. Mark every action that completes in one step and cannot be undone. Those need a hold before they run. A brake will not reach them.
2. Name who can pull the brake. Nadella says "an authorized person"1. Which person, by name? Can they do it at 2am on a Sunday? Does pausing the agent also stop the sub-tasks it already started? Our piece on kill switch, pause and rollback lists what "stop" has to stop.
3. Test the record without the agent. Pick last week's run. Try to rebuild what happened from your record alone: what it read, what it changed, who approved. If you need to ask the agent, you fail his "observe everything" test. Logs are a patch explains why.
4. Split the doer from the checker. If the same agent does the work and writes the report on it, you break his auditability rule. A second model can help. A person signing off on the risky step helps more. See the two-person rule for AI agents.
What changes
The CEO of a company that sells models just said the model is not the control. That is the bar now. Sorting actions into "brake" and "hold" is how you clear it.
This is the layer Gatehouse sits in. The rules live outside the model. Risky actions wait for one named approver. Every decision lands in a record you can read without asking the agent.
Start with step 1 this week. Want a second pair of eyes on the list? Book a teardown.
Sources
Want the next one? News with a take, three times a week. Follow by RSS
Read next
Kill switch, pause and rollback: what 'stop the agent' has to stop
A kill switch that stops new runs but not the one mid-payment is half a switch. What stop has to cover: in-flight actions, queued actions, scheduled runs and the credentials.
The two-person rule for AI agents: overrides, dual authorisation, and Meta's Rule of Two
Two people to override a block. Where the rule comes from, what it should cover for an agent, and why Meta's 'Agents Rule of Two' is a different rule with a confusing name.
Logs are a patch. Sealed records are the fix.
Logs were built so engineers could debug software. Agents that approve, pay and send need something else: a record per decision, sealed when it's made, that someone outside can check.
