Microsoft has introduced a security framework that treats AI agents as a form of insider risk, arguing that organizations must control their identities, permissions and runtime behavior independently of the models themselves.
The Microsoft Security guidance published on October 19, 2026 is not an incident or vulnerability disclosure. It addresses the operational risk created when agents receive access to corporate data, tools and infrastructure—and can then act at machine speed.
Microsoft does not characterize agents as inherently hostile. Its concern is that model output can vary, task context can shift and external content can manipulate an otherwise legitimate agent. A system that begins a task correctly may therefore deviate later because of an error, compromise or prompt injection.
The company calls this an “agentic insider”: software acting with delegated organizational authority but without fully deterministic behavior.
Controls must remain outside the model
Microsoft’s central principle is to “surround non-deterministic intelligence with deterministic controls, independent evidence, and containment boundaries.”
Under this model, an agent should not decide the limits of its own authority. Identity, access and enforcement mechanisms must operate outside the model, beyond its ability to bypass or modify them.
Microsoft Chairman and CEO Satya Nadella summarized the approach by arguing that the most trustworthy agentic architecture is designed to “trust the model least.” The practical distinction is between trusting a model to behave correctly and building a system that limits the damage when it does not.
Microsoft organizes the framework around four continuous responsibilities:
- Know: maintain an inventory of agents, their owners, intended purpose and observed activity.
- Contain: restrict data, systems and actions before an agent begins operating.
- Protect: secure every component in the agent’s path, including tools, runtime environments and corporate resources.
- Adapt: revise protections when behavior, context or assessed risk changes.
These are not presented as sequential implementation stages. Microsoft describes a feedback loop in which new evidence changes risk, risk changes policy and policy changes what an agent can do.
When risk increases, the framework can preserve read access while blocking writes, reduce the resources available to the agent, require verified human approval for consequential actions, or isolate and stop the agent.
Every agent gets a separate identity
One immediate consequence for security teams is that an agent should not operate simply as an extension of an employee account.
Microsoft says each agent needs its own first-class identity, distinct from the person sponsoring it. This allows audit and access systems to distinguish an employee’s direct actions from operations performed by an agent on that employee’s behalf.
The company says it is adding discovery support for 35 additional types of local agents, bringing the supported total to 60. Examples include Claude Code, OpenAI Codex and GitHub Copilot. Discovery is intended to cover Microsoft-built agents, partner platforms and SDKs, as well as agents introduced locally.
Microsoft also says it is extending Microsoft Entra Agent ID with identity types for additional agent patterns, including local agents and previously unknown agents detected by security sensors. Project Perception and Microsoft Agent 365, according to the company, share signals and use a unified registry.
For administrators, the proposed model turns agent discovery into an asset-management problem: an organization cannot apply meaningful access controls if it cannot identify which agents exist, who is responsible for them and what they are doing.
Sandboxing and mediated tool access
Microsoft recommends running models and their surrounding harnesses in controlled environments instead of allowing them to inherit the full privileges of a device.
It cites Microsoft Execution Container (MXC) as an example of a sandbox designed to enforce policy-controlled access to resources. The enforcement boundary is meant to sit outside the agent rather than depend on instructions within the model.
The framework also rejects unrestricted tool discovery. An agent should not automatically be able to invoke every API, MCP server, network resource, local tool or other agent it encounters. Local, network and data controls should mediate those connections.
Content inspection is another part of the design. Security systems should evaluate the sensitivity and origin of information entering or leaving an agent, including whether untrusted material could be influencing its decisions.
Microsoft illustrates the risk with an expense-approval agent. Such an agent may legitimately need to read claims, compare them with policy and authorize routine reimbursements. It does not need all the permissions held by its sponsor. If an external document contains a prompt injection, the agent’s configuration may remain unchanged even though its behavior—and therefore its risk—has shifted.
Permissions that expire with the task
Microsoft presents Dynamic Permissions as a way to give an agent no standing access by default. The agent would receive only the authority required for an approved task and only for the duration of that task.
Organization-wide policy would define the maximum boundary. In particular, an agent could not obtain authority unavailable to its sponsoring user. Permissions could be limited to a task, expire after a specified period, or be reduced as the task progresses. Higher-impact operations could require verified human approval.
The employee would retain their own access, while the agent would have a separate identity and its own task-specific permissions. This separation is designed to make attribution and revocation more precise than allowing an agent to reuse a person’s credentials and privileges.
Microsoft also describes Dynamic Agent Risk as a continuously updated score built from identity, endpoint, data, cloud, network, runtime and agent-activity signals. The assessment considers the agent’s security configuration, the resources it can reach, the likely impact of failure and signs that its actions are drifting from user or organizational intent.
A diagram accompanying the announcement shows Microsoft Sentinel, Entra, Intune, Purview, Global Secure Access and Defender supplying signals for context analysis and real-time risk scoring. Microsoft links that assessment to Dynamic Conditional Access, under which policy can change what an agent may read, alter, invoke or approve at a particular moment.
These are Microsoft’s descriptions of its capabilities and intended architecture, rather than evidence from an independently demonstrated deployment.
Automation will also monitor the agents
Microsoft argues that manual review will not scale when organizations deploy “thousands or hundreds of thousands” of agents. Its proposed answer includes Guardian Agents—AI systems used to help supervise other agents while remaining subject to human-defined boundaries.
A Security Affairs report published on October 20, 2026 says Guardian Agents can follow operator-created playbooks, investigate changes in risk, recommend or apply responses and use outcomes to refine policy. Humans would continue to set objectives and approve significant decisions.
That approach leaves a central design challenge: enforcement cannot depend solely on another model whose behavior may also vary. Microsoft’s stated answer is to keep decisive controls outside the models, where agents cannot alter them.
For organizations adopting agents now, the framework translates into concrete priorities: discover local and centrally deployed agents, assign each one a separate identity, remove inherited user privileges, constrain its runtime and tool paths, inspect untrusted inputs, and require human approval or isolation when changing risk makes an action unsafe.
