On October 19, 2026, Microsoft security executive Hayete Gallot told TechCrunch that "frontier models, regardless of their origin, cannot be trusted," and Microsoft announced Guardian Agents plus expanded detection of local coding agents including Claude Code and Codex. If you run coding agents on a managed Windows fleet, Defender may soon see them. If you do not, the design principles still apply. Microsoft gave no availability dates, so treat this as direction, not a shipping control.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Only if your organization uses Microsoft Defender and Entra. Nothing here changes how an agent behaves on your machine today. |
| Is there a fix? | This is not a vulnerability. It is a set of new governance features. |
| Is it available? | No dates published in Microsoft's security post. |
| Does data leave my machine? | Microsoft's post does not say what telemetry its sensors collect. Check before enabling. |
What was announced
According to Microsoft's post, the pieces are:
- Guardian Agents, part of Project Perception, which Microsoft introduced in June. They investigate why an agent's risk changed, review evidence, and recommend or apply containment. People set policy, approval boundaries and delegation rules.
- Agent discovery. Defender adds 35 local agent types, for 60 in total, naming Claude Code, OpenAI Codex and GitHub Copilot. Discovered agents can go into a registry and receive identities through Entra Agent ID.
- Agent identity. Each agent gets its own identity separate from the user who sponsors it, so logs can tell what a person did from what an agent did.
- Dynamic Permissions. Organization policy sets the outer limit; an agent cannot get authority its user lacks. Permissions are scoped to the task, time-bound, and removed when the task ends. Higher-impact actions can require verified human approval.
- Action mediation and containment. Agents should not call any tool, API or MCP server they find. They run in controlled environments such as Microsoft Execution Container.
- Graduated responses. Options include allowing reads while blocking writes, narrowing resources, revoking access, isolating the runtime or stopping execution.
TechCrunch's report notes the stance cuts against Microsoft's lab partners and also favors selling Microsoft's own security products. The reporter still considers the core logic sound: monitoring should be independent of whoever supplies the agent.
The argument behind it
Satya Nadella's essay on models as insider risks argues that organizations cannot outsource responsibility for what intelligence does on their behalf, and that they need "to separate the supply of intelligence from the authority over it." His proposed controls include permission limits outside the model and its harness, tamper-proof human-readable logs, model diversity, independent auditing, and the ability to pause or shut down an agent mid-task. His summary: "If it can't be observed, it can't be trusted!"
Gallot, who leads Microsoft's security business, also said the problem is not that models are malicious but that they are unpredictable: trained to finish tasks, not to follow organizational norms, yet given access to data and tools that can cause harm.
The four responsibilities Microsoft lists
Microsoft's post says the system has four continuous responsibilities, and that they are "not four products or sequential phases":
- Know which agents exist, who owns them, why they exist and what they are doing.
- Contain what each agent can access and do before it acts.
- Protect the data, tools, runtime, resources and systems in the agent's path.
- Adapt protection continuously as behavior, context and risk change.
The post says Project Perception and Microsoft Agent 365 share signals, context and a unified registry, so IT and security teams get one view of agents and risk. It frames the whole design as a principle: "surround non-deterministic intelligence with deterministic controls, independent evidence, and containment boundaries."
How the containment pieces work
Runtime containment
Microsoft says the model and harness should run inside a controlled environment instead of inheriting fully privileged access to the device. It names the Microsoft Execution Container (MXC) as an example of a sandbox that gives policy-controlled access to the resources a task needs. The stated purpose is an enforcement boundary "where security controls and observability can operate outside the agent's reach," so a compromised agent or harness cannot switch off the controls watching it.
The action space
The post says an agent should not be free to call any tool, API, MCP server, resource or other agent it can find. Local, network and data controls should mediate those paths, observe the calls and enforce policy. It adds that controlling the destination alone is not enough: security must also understand the content flowing in and out, including its sensitivity, provenance and whether untrusted data may be influencing the agent. Our MCP security guide covers that exposure from the developer side.
Least privilege by default
Microsoft's position is that an agent "should begin with no authority and receive only what it needs for the approved task, for only as long as the task requires." Dynamic Permissions implements this: organization-wide policy sets the outer boundary and prevents an agent from obtaining authority its user does not have, permissions are scoped to the task and made time-bound, and higher-impact actions can require verified human approval. The post gives the split plainly: the employee keeps the employee's access, and the agent receives its own identity and its own task-scoped authority.
Risk that changes during a run
The post introduces two further features. Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime and the agent's own activity. It looks at how securely the agent is configured, what it can reach, the possible impact, and whether its actions are drifting from the user's or organization's intent. Microsoft says the result is "not a one-time score assigned at onboarding."
Dynamic Conditional Access extends Entra Conditional Access to agents so a change in risk can drive action at several enforcement points. The response is "graduated, not binary": reduce permissions, keep reads while blocking writes, narrow the data and resources an agent can reach, restrict network paths, shorten or revoke time-bound access, require provable human approval, or at the highest risk isolate the runtime or stop execution.
The post's worked example is an expense-approval agent that meets a prompt injection in an external document. Its configuration has not changed, but its behavior and risk have, and policy removes its ability to approve or write while it can still read. Prompt injection in the middle of a task is the same pattern covered in the common crawl header study and the agentjacking write-up.
Guardian Agents and playbooks
Microsoft's argument for Guardian Agents is scale: as organizations deploy "thousands or hundreds of thousands of agents," manual triage will not keep up, so security must become agentic "while remaining inside boundaries people set." People define policy, approval boundaries and delegation rules. Playbooks define the desired security outcome and coordinate protective actions. Guardian Agents do the continuous work: they help explain why risk changed, investigate the evidence, recommend or apply containment, and feed what they learn back into policy. The post says Microsoft already operates with hundreds of thousands of agents internally as "Customer Zero."
Background: how Microsoft got here
TechCrunch reports that Project Perception launched in June in response to offensive models such as Anthropic's Mythos and Fable and OpenAI's Daybreak, with three classes of agents: a red team that attacked, a blue team that detected and assessed what the red team found, and a green team that fixed it. That design assumed AI attackers would come from outside the company. The new announcements shift the assumption to agents the company deployed itself.
The turning point in public was Nadella's essay of October 10, which TechCrunch calls his private blog. He wrote that "any sufficiently capable actor with access to important systems can make mistakes or be compromised," and that this is why models should be treated like insider risks "not because they are necessarily malicious." He also traced the principle that "a program must not be able to bypass or tamper with the mechanisms that enforce its permissions" to the 1970s.
The essay lists seven principles beyond containment: model diversity, observe everything, verifiability, independent controls, independent auditability, containment and incident disclosure. Two of them bear directly on coding agents. "Observe everything" asks that every meaningful model action leave tamper-proof, human-readable evidence, so an outcome can be reproduced "without relying on the model to attest to it." "Independent auditability" asks that no single model control both a system's behavior and the evidence used to judge it.
TechCrunch adds that Microsoft was an inaugural member of NVIDIA's Open Agent Safety Platform, which isolates agents and can stop behavior through hardware. Beam covered that separately in NVIDIA's Open Agent Safety Platform.
What is claimed and what is not stated
The announcement covers a lot of ground, so it helps to separate the parts.
- Stated by Microsoft: the feature names, the 35 additional local agent types and 60 in total, the named agents, the idea of task-scoped time-bound permissions, and graduated responses.
- Reported by TechCrunch: that the discovery feature can find "up to 60 types" of agents, that OpenClaw is among them, and that Microsoft also announced features limiting agent access and adjusting permissions by task.
- Not stated in the sources Beam read: pricing, general availability dates, how Defender's sensors identify a local agent, what telemetry they collect, and how reliably they separate an agent's actions from a user's on the same machine.
The security post's page description says the new capabilities are in Microsoft 365 E7 and Project Perception. Check licensing with Microsoft rather than assuming a feature is available because it was announced.
TechCrunch's reporter also notes that the stance is self-serving: Microsoft would like enterprises to buy agent security from the cloud provider instead of from the labs that supply the agents. That does not change the engineering argument, but it is a reason to test claims against your own environment.
What this means if you run AI coding agents
- Inventory first. You cannot govern agents you do not know about. List which agents run on which machines, including local installs nobody deployed centrally.
- Put limits outside the model. Use the agent's permission settings and hooks, not instructions in a prompt. Our monitor-versus-block comparison covers the trade-off, and stopping dangerous commands in Claude Code shows a concrete setup.
- Scope access to the task. Prefer short-lived, narrow credentials over a long-lived key in your shell. The OpenCode Console incident shows what a stored provider key costs when a third party is breached.
- Keep logs the agent cannot edit. See what AI agent monitoring is.
- Know your off switch. Decide ahead of time how you would stop a session mid-task.
- Ask Microsoft what the sensors collect before enabling discovery, since the post does not specify.
- Separate the person from the agent in your own records. Microsoft's agent identity idea is that a log should tell what a person did from what an agent did on their behalf. On a laptop, that can be as simple as running the agent under its own scoped credentials rather than your personal token.
- Plan for mid-run risk, not only start-of-run risk. The expense-agent example turns on a prompt injection that appears after the task begins. Decide which actions you would still want blocked if the agent's context were poisoned, such as writes, pushes or package installs, and block those through hooks rather than prompts.
A practical test for any control, borrowed from the essay: could the agent edit it? If a setting lives in a file the agent can write, treat it as advice. Two earlier Beam posts show the failure. In the Cursor MCP config bug, the agent trusted a config file after a rewrite it made itself. In the Claude Code plugin pin bypass, a pin did not verify what it was meant to pin.
For hardware-level approaches to the same problem, see NVIDIA's Open Agent Safety Platform.
What Beam can and cannot do here
Beam covers the single-machine end of this: it watches what Claude Code, Codex and similar agents do, flags risky actions such as credential exposure and destructive commands, and can deny them through PreToolUse hooks on Claude Code and Codex. Records stay on-device. See how Beam works and the local-first design. It is heuristic, not a kernel sandbox, and it is not an enterprise identity or conditional-access system: it does not issue agent identities, scope tokens, compute a risk score or replace Defender and Entra. Its records are local to the machine, so they help a single developer review what an agent did, but they are not a tamper-proof audit trail in the sense Nadella's essay asks for.
Frequently asked questions
What did Microsoft announce on October 19, 2026?
Guardian Agents inside Project Perception, expanded Defender discovery of local agents (35 more types, 60 in total), separate agent identities through Entra Agent ID, and Dynamic Permissions that scope an agent's authority to the task.
Does Microsoft Defender detect Claude Code and Codex?
Microsoft names Claude Code, OpenAI Codex and GitHub Copilot among the 60 supported local agent types, with a support matrix listing the rest. Discovery relies on connectors and sensors, and discovered agents can be placed in a registry.
When are these features available?
Microsoft's security post gives no availability or preview dates for Guardian Agents, Dynamic Permissions or the expanded discovery. It points readers to Microsoft Ignite, November 17 to 20, 2026.
What does treating a model as an insider mean in practice?
Nadella's essay says to separate the supply of intelligence from authority over it: permission limits, logging and stop controls should sit outside the model and its harness, and be verified independently.
Do I need an enterprise suite to apply this to my own coding agents?
No. The principles are least privilege, task-scoped access, tamper-resistant logs and an off switch. You can apply them to a laptop setup with the agent's own permission settings and a local monitor.
Related reading
Details reflect Microsoft's announcements as of October 19, 2026 and may change as features ship.