What Nadella actually argued
His central claim is that organizations must separate the supply of intelligence from authority over it. Traditional software lets engineers trace behavior to a code path. Frontier models don't, and Nadella says we can't tie their outputs to specific training data or weight configurations. Yet these systems are being given access to sensitive data and the ability to act on our behalf.
His proposed answer is to treat capable models as insider risks. He says this isn't because they are necessarily malicious. It's because any capable actor with access to important systems can make mistakes or be compromised. Enterprises already know how to handle powerful insiders: establish identity, limit privileges, log activity and create containment boundaries.
The post lists several principles:
- Controls outside the model. What a model can access and do must be enforced by mechanisms it can't bypass or tamper with. Nadella ties this to an information security principle from the 1970s.
- Observe everything. Every meaningful action should leave tamper-proof, human-readable evidence. The outcome should be reproducible without the model vouching for itself.
- Model diversity. No single model should be the sole dependency for an important outcome or verify its own work.
- Continuous verification. Test the whole system, including failures, attacks and edge cases, not just successful tasks.
- Independent auditability. No single model should control both a system's behavior and the evidence used to judge it.
- Containment. Assume the model is compromised from the start. This is where the emergency brake sits.
- Incident disclosure. Failures should be disclosed promptly to those affected and shared industry-wide.
He also warns that chain-of-thought transparency alone isn't dependable. Using models to test each other can leave you with nested black boxes. His closing line is that the most trustworthy system is the one that lets you trust the model the least.
How Microsoft turned the principle into product direction
On October 19, Microsoft published two posts. One was by Security EVP Hayete Gallot. The other was by Nadim Abdo, corporate VP for identity and network access. Together they extend Project Perception, introduced in July 2026 with teams of red, blue and green agents, from defending against outside attackers to governing agents running inside the enterprise.
Microsoft says Project Perception and Microsoft Agent 365 share signals, context and a unified registry, so IT and security teams see the same picture. It describes four continuous responsibilities rather than four products or phases:
- Know which agents exist, who owns them and what they are doing.
- Contain what each agent can access and do before it acts.
- Protect the data, tools, runtime and systems in its path.
- Adapt protection as behavior, context and risk change.
Discovery and identity
Microsoft says it is expanding local-agent discovery by 35 types, for a total of 60 supported types, naming Claude Code, OpenAI Codex and GitHub Copilot. It is also extending Microsoft Entra Agent ID with identity types for additional agent patterns, including local agents and previously unknown ones found by security sensors. The aim is to separate what a person did from what an agent did on that person's behalf.
Dynamic Permissions
Agents should start with no authority and receive only what the approved task needs, for only as long as it needs it. An agent shouldn't inherit all of its user's standing access. Organization-wide policy sets the outer boundary. Permissions can be scoped to the task, time-limited and removed when the task changes or finishes. Higher-impact actions can require verified human approval.
Dynamic Agent Risk and Dynamic Conditional Access
Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime and the agent's own activity. It looks at configuration, reachable resources, potential impact and drift from intent. Microsoft stresses it isn't a one-time onboarding score.
Dynamic Conditional Access extends Entra Conditional Access to agents. Microsoft calls the response graduated, not binary. Options include:
- Reducing permissions.
- Keeping read access while blocking writes.
- Narrowing reachable data and resources.
- Restricting network paths.
- Shortening or revoking time-bound access.
- Requiring provable human approval.
At the highest risk levels, the system can isolate the runtime or stop execution.
Guardian Agents and Playbooks
People define policy, approval boundaries and delegation rules. Playbooks define the desired security outcome. Guardian Agents do the continuous work: investigating why risk changed, recommending or applying containment, and helping harden policy. Microsoft says people retain control over objectives and consequential decisions.
Kill switch or not?
Abdo's post makes the point directly with an expense-approval agent. If it hits a prompt injection in an external document, Microsoft says the system can block writes, narrow resources and require human approval. If risk keeps rising, it can isolate or stop the agent. The post says the employee stays productive and the agent is constrained without treating every risk change as a kill-switch event.
So the headline version needs two caveats:
- Nadella calls for an authorized human to always be able to pause or stop a model.
- Microsoft's product direction leans on automated, proportionate containment under human-set policy. A full stop is the last rung of the ladder.
Nothing in the materials shows a single, universal, manually operated stop button across all agents or platforms. The practical reading is that "kill switch" means independent containment authority. It is not a complete security plan.
Availability and caveats
Microsoft's announcement is a roadmap and a set of claims. It is not a set of independently verified results. BigGo Finance reported that Microsoft did not disclose pricing or a general availability date in the announcement. Microsoft Learn documentation describes Project Perception as being in Limited Public Preview. That means invitation-only access, and prerelease details may change substantially. Don't plan on these features being generally available.
Critics have raised a fair objection. Dark Reading reported that experts warn policing unpredictable agents with other agents may multiply, not contain, the risk. This echoes Nadella's own worry about nested black boxes. Microsoft's answer is that Guardian Agents work inside human-defined policy, and that enforcement stays deterministic and independent of the model. Whether that holds under real attacks is the open question. The Hack Academy's review also noted there is no independent evidence the controls work.
What administrators can do now
You don't need Project Perception to apply the underlying ideas. These steps are general good practice drawn from the principles above, not Microsoft procedures:
- Inventory your agents. Include local coding agents that developers installed on their own. You can't contain what you can't see.
- Give agents their own identities. Don't let them run under a user's credentials where you can avoid it.
- Start from zero permissions. Scope access to the task and its duration. Require human approval for consequential actions such as payments, deletions and external sharing.
- Keep audit logs outside the agent's control. Don't rely on an agent's own account of what it did.
- Decide who can stop an agent, and test it. An emergency brake nobody has rehearsed is a decoration.
- Test failure cases. Try prompt injection and out-of-scope requests, not just the happy path.
The bottom line
Nadella's post is a clear statement of design philosophy: assume the model can fail, put enforcement outside it, and keep a human able to stop it. Microsoft's October 19 announcements show how it wants to build that in Entra, Agent 365 and Project Perception. They are early, in preview, and so far unproven by outside testing. The useful takeaway for IT teams is to adopt the principles now and treat the products as something to evaluate later.