Least privilege is not enough when an AI agent can change course

Microsoft’s agent security architecture separates identity from authority, but availability, coverage…

The short version

Microsoft’s architecture gives each enterprise AI agent a separate identity instead of inheriting a sponsoring employee’s standing credentials.
Dynamic Permissions and Dynamic Agent Risk can narrow temporary access or stop execution as task context changes.
Buyers should verify discovery coverage, preview status, availability, licensing, and independent effectiveness evidence before adopting Microsoft’s implementation.

If an AI agent borrows your employee badge, your audit log is lying. Microsoft finally has the right principle: every enterprise agent needs a disposable identity whose authority can shrink mid-task.

In Microsoft’s October 19 announcement, Satya Nadella put it bluntly:

The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.

That is an extraordinary line from the CEO of a company selling models, Copilots, cloud infrastructure and, conveniently, their security system. Nadella is right: an expense agent using my permissions makes alignment assurances sound like a waiter saying the kitchen probably remembered my allergy.

Microsoft’s expanded Project Perception combines Guardian Agents, Dynamic Permissions, Dynamic Agent Risk and Dynamic Conditional Access. The names could fill a Gartner buffet, but the architecture is solid: give each agent an identity, limit its authority to the current job, recalculate risk while it acts and keep enforcement outside the model’s control.

I would redesign around those principles today. I would wait to buy Microsoft’s implementation because availability, coverage and final licensing remain fuzzy.

first, give the machine its own name

Imagine a coding agent modifying a repository under my account. The audit log says Luca changed the file but cannot distinguish whether I clicked a button, Claude Code called a tool or a poisoned document persuaded the agent to improvise. Congratulations: accountability theater, now with timestamps.

Microsoft says Defender is expanding discovery from 25 supported local-agent types to 60, adding Claude Code, OpenAI Codex and GitHub Copilot. That is meaningful coverage over the previous baseline. Security teams must still ask which agents are actually visible on managed devices.

Discovery starts with endpoint signals and other Microsoft security systems. When a supported local agent runs on a Defender-managed machine, its activity can be linked to the user, device and agent type. Security teams can inspect the record, assign ownership and see which resources the associated account can reach. In supported cases, they can also see configured MCP servers. Microsoft Entra Agent ID should then make the observed agent a durable policy target with its own permissions and lifecycle. Discovery finds the actor; identity gives the control plane something stable to restrict.

The limits appear once you leave the architecture diagram. Microsoft’s Defender documentation describes an observed-activity inventory, so installation does not guarantee visibility. A dormant agent can remain invisible until someone runs it. An unmanaged laptop escapes the endpoint view entirely, exactly where a developer’s “temporary test” celebrates its second birthday in production.

Identity can also be coarse. Microsoft defines a local agent by its user, device and agent type. Claude Code operating across several project folders for one person on one laptop may appear as one entry, even when those jobs cross very different trust boundaries.

Microsoft says Entra Agent ID will extend to local agents and previously unknown agents discovered by security sensors. I like that direction: an agent should leave a trail under its own name. I do not want to explain at two in the morning why “Luca” downloaded payroll data while Luca slept. Microsoft has not provided general-availability dates for every identity pattern, and an architecture diagram cannot revoke a production token.

permanent permissions are a bug wearing a necktie

I treat an agent like a disposable contractor whose badge rewrites itself every few seconds. It gets access for one job, then the badge expires. Giving autonomous software a full employee token is like leaving the restaurant’s master key by the delivery entrance because the courier seemed friendly.

Dynamic Permissions starts the agent with zero authority or the smallest available grant. When an approved task arrives, policy identifies the necessary tools and resources, then issues temporary access under the agent’s identity. Organization-wide rules set a ceiling based on the sponsor’s authority. The sponsor keeps their normal access; the agent gets less. If the task changes, its grant can shrink. When work ends, access can disappear. Higher-impact actions can pause for approval from a verified person.

An expense agent may need to read submissions and compare them with policy. Depending on company rules, it might approve routine reimbursements. “Please process this receipt” does not authorize payroll exports or customer records, however confidently the model asks.

The sponsor ceiling closes one ugly escalation path but leaves plenty of trouble. A finance director may already have broad access, making the maximum grant enormous. Microsoft has published no independent measurement of how accurately Dynamic Permissions chooses correct task-level access within that ceiling.

Permissions also need a physical boundary. Microsoft documents local agents running with endpoint user privileges, letting them read files, execute commands and call tools. Identity policy controls what the agent may reach. A sandbox such as Microsoft Execution Container limits where the harness can operate, while monitoring remains outside so compromised software cannot switch off its own camera.

I understand the temptation because I have made this mistake in my stack. I run accounting automation, a personal assistant and a bot that remotely manages my servers. Broad credentials make integrations dramatically easier, especially at midnight when I want to ship and future Luca can apparently handle security. “I know what this token does” remains founder optimism in sweatpants.

Stainless-steel colander standing upright against a saturated coral background, its perforated bowl filling the frame.

The model proposes an action. The external control plane decides whether it happens.

permissions must change while the agent is working

Startup permissions describe an agent before fresh context arrives. An expense workflow can begin safely, read a poisoned invoice and attempt an unrelated write five minutes later while retaining its original grant. Static least privilege goes stale fast.

Here is the Project Perception control loop. Microsoft gathers signals from identity systems, data controls, endpoints, cloud services, network traffic and the agent runtime. Those signals identify the agent and connect it to its container, current policy and available permissions. Dynamic Agent Risk evaluates that context with the attempted action. When risk changes, policy recalculates what the agent may do. A moderate response can preserve safe reads while removing writes or narrowing resources. A consequential action can await provable human approval. Severe risk can isolate or stop the agent before completion.

Guardian Agents operate inside this loop. People define acceptable outcomes and approval limits through Playbooks; the Guardian investigates risk changes and performs only policy-allowed containment. One probabilistic system supervising another can accelerate investigation. Final authority still belongs in deterministic controls with a human owner, unless your security strategy is two models arguing in a trench coat.

At the endpoint, Defender’s preview runtime protection has two inspection methods. Agent-native inspection reads events exposed through vendor-supported interfaces. Network inspection watches covered agent-to-LLM traffic when native events are unavailable. At supported inspection points, Defender can detect a malicious prompt or high-risk action and return an audit or block outcome before a harmful tool call runs.

Coverage depends on the integration. Microsoft’s documentation says network inspection cannot handle certificate-pinned or HTTP/3 traffic, while native inspection depends on interfaces from each agent vendor. Defender sees available checkpoints, not every internal model state by magic.

Hayete Gallot, Microsoft’s executive vice president for Security, captured the company’s position in her October 19 post:

Unfortunately, frontier models, regardless of their origin, cannot be trusted.

That claim conveniently helps Microsoft sell the external control plane, but the Last Secure Code Benchmark supports it. The strongest tested coding agent produced functional, secure code on only 25% of tasks, while functionality alone passed on 74% to 91%. The benchmark tested code-generation agents, not Microsoft Defender or Anthropic’s managed review service, so it cannot prove Project Perception closes the gap. It does show why “the model seemed competent” is weak evidence for durable authority.

The unanswered questions are substantial. Microsoft has not published false-positive or false-negative rates for Dynamic Agent Risk. We do not know how it validates Guardian containment across models and workloads. No independent measurement shows these controls reducing successful prompt injection, data loss or harmful actions in enterprise deployments. The mechanism is credible; effectiveness remains an open measurement problem.

buy the deployment receipt, not the keynote

Microsoft operates several kitchens in this building and now wants to sell everyone the fire alarm. I concede that conflict because it complicates the pitch. The principle survives: intelligence and authority should remain separate, even if another vendor wins the control-plane market.

A serious evaluation starts with product status and the exact support matrix. Check discovery coverage separately from runtime protection because Microsoft documents different operating-system and integration requirements. Determine whether each agent exposes native events or needs network inspection. Put a small group of supported devices into audit mode and record detected attacks, flagged legitimate actions and added latency. Test failure behavior when the security service is unavailable. Assign an owner for human approvals before enabling blocking because “the control plane timed out” is a terrible authorization policy.

Microsoft’s deployment guide labels Defender runtime protection as preview software. It recommends starting a small group in audit mode before moving supported devices into block mode. That guidance covers documented prompt-injection protection, not production readiness for every Project Perception capability announced with it.

The shopping list is substantial. Microsoft documents Defender for Endpoint Plan 2 and broader bundles, including Microsoft 365 E5, as qualifying runtime-protection licenses. Devices must be supported and onboarded. Intune may require another qualifying subscription. Those requirements explain the existing endpoint feature; final packaging for Guardian Agents and the wider Entra governance expansion remains unknown.

Major pieces also lack general-availability dates. Microsoft has not disclosed complete pricing, regional rollout or production-scale performance. Understanding an agent’s intent may require model-level transparency, but nobody has explained what access Microsoft will receive or how customer privacy constraints will shape it.

So I am retiring “safe” from agent procurement. Safe is panna cotta: soft, wobbly and structurally useless. Ask which identity the agent uses, what temporary grant authorizes its task, which evidence can shrink that grant and which external system can stop execution.

My dated prediction is simple. By October 2027, giving an enterprise agent a human’s standing credentials will look as professionally indefensible as sharing an administrator password in Slack. Microsoft may lose the control-plane fight. The disposable badge will survive it.

Frequently asked questions

Why should an enterprise AI agent have its own identity?

An enterprise AI agent should use its own durable identity because activity performed under a human account makes the audit log unable to distinguish the employee from autonomous software. Microsoft Entra Agent ID is intended to make discovered agents stable policy targets with separate permissions, ownership, and lifecycle controls.

How do Microsoft Dynamic Permissions work for AI agents?

Microsoft Dynamic Permissions starts an agent with zero authority or the smallest grant, then issues temporary task-specific access under the agent’s identity. Organizational policy caps that access below the sponsor’s authority. Grants can shrink as risk or context changes, expire when work ends, or pause consequential actions for verified human approval.

Is Microsoft Project Perception generally available and fully priced?

Microsoft has not provided general-availability dates, complete pricing, regional rollout, or production-scale performance for major Project Perception capabilities. Defender runtime protection is documented as preview software, with qualifying licensing and device requirements. Buyers therefore need to verify the support matrix, product status, and final packaging before planning deployment.