On October 19, 2026, Microsoft published a security post arguing that AI agents should be treated as "agentic insiders": actors inside your systems that hold real permissions and can be wrong, manipulated or compromised. For anyone working on AI agent security, the product names matter less than the design principle behind them. Microsoft is saying publicly that even agents your own team builds should not be trusted by default, and that changes what "production-ready" means for an agent.

What Microsoft announced on October 19

The announcement extends Project Perception, the agentic security effort Microsoft unveiled in July 2026 to defend against AI-driven external attacks, so that it also governs the agents organisations run themselves. The main pieces:

  • Entra Agent ID, extended. Microsoft says every agent should have its own first-class identity, separate from the person using or sponsoring it. New identity types cover more agent patterns, including local agents and previously unknown agents found by security sensors, so they can become policy targets even if nobody integrated them with Microsoft Security.
  • Wider discovery. According to SecurityWeek, discovery now covers 35 more types of local agents, 60 in total, including Claude Code, OpenAI Codex and GitHub Copilot.
  • Dynamic Permissions. Agents start with no authority. Organisation-wide policy sets the outer boundary, including that an agent can't obtain authority its user doesn't have. Permissions are then scoped to the task, time-bound, and shrunk or removed as the task changes or ends. Higher-impact actions can require verified human approval.
  • Dynamic Agent Risk. A risk assessment that combines the agent's own activity with identity, data, endpoint, cloud, network and runtime signals, weighing what the agent can reach, how much damage a failure could cause, and drift from the user's or organisation's intent. Microsoft also plans to feed chain-of-thought and other model-level signals into it, while keeping enforcement independent of the model.
  • Dynamic Conditional Access. An extension of Entra Conditional Access in which a change in risk triggers a graduated response: fewer permissions, reads allowed but writes blocked, narrower data and network reach, shorter or revoked access, or required human approval. At the highest risk levels, the runtime is isolated or execution stops.
  • Guardian Agents and Playbooks. People define policy, approval boundaries and delegation rules, Playbooks describe the desired security outcome, and Guardian Agents carry out protective actions at machine speed.

Microsoft also stresses sandboxing: the model and its harness should run in a controlled environment, such as Microsoft Execution Container (MXC), rather than inherit full access to the device. As SiliconANGLE notes, because monitoring sits outside the container, a compromised agent can't turn it off.

Why the agentic insider framing matters

The core idea traces back to Satya Nadella's October 10 essay: separate the supply of intelligence from the authority over it, and don't ask a model to act as its own security authority. Microsoft's blog turns that into an engineering rule. Wrap non-deterministic models in deterministic controls, assume the agent can fail or be compromised, observe it continuously, and cut its authority to the minimum before it acts.

As quoted by SecurityWeek, Hayete Gallot, Microsoft's EVP of Security, wrote that agents are frequently overprivileged while having access to data, tools and systems and making decisions in critical processes. A common way this happens: a prototype agent gets the developer's token or a broad service principal because it's the fastest path, and that shortcut quietly ships to production.

Microsoft's worked example deserves a close read. An expense-approval agent starts a task with the right access, then reads an external document containing a prompt injection. Its configuration hasn't changed, but its behaviour and risk have. Static permissions granted at deploy time can't catch that. Only controls that watch behaviour and can tighten access mid-task can.

The scale argument lands too. Terrell Cox, Microsoft's deputy CISO, is quoted in Microsoft's post as saying the company already operates in a world of hundreds of thousands of agents. Smaller companies run far fewer, but coding agents on developer laptops multiply that number quickly, and few teams know exactly which ones are running.

What you can use today, and what's still unclear

Be careful with timelines. Microsoft's own documentation describes Project Perception as a limited public preview open to a small, invitation-only set of customers, and Microsoft is pointing customers to Ignite, which runs November 17–20, for more detail. Microsoft hasn't given firm availability dates or per-feature pricing, and The Next Web points out it hasn't said whether the features will cost extra on top of an E7 licence.

The controls are positioned as part of Project Perception and Microsoft 365 E7, the suite that bundles Agent 365 with Microsoft 365 Copilot. It's also unclear whether the controls will cover custom agents built directly on Azure, and regional availability in Türkiye and the UK hasn't been confirmed.

For most startups and mid-size firms, a premium enterprise bundle whose new controls are still in an invitation-only preview won't make next quarter's roadmap. The good news is that the pattern Microsoft describes doesn't depend on Microsoft's products.

AI agent security without E7: a practical blueprint

Here is a practical checklist. Each item maps to one of Microsoft's controls, but you can build it with your existing identity provider, API gateway and logging stack.

  1. One identity per agent. Don't reuse the user's token or share one service principal across agents. On Azure, a dedicated managed identity or app registration per agent is a sensible start. If your logs can't answer "which agent did this?", you don't have agent identity.
  2. Start at zero, grant per task, expire everything. Issue short-lived, narrowly scoped credentials for each task. Enforce the ceiling: the agent's effective permissions must never exceed those of the user it works for.
  3. Enforce outside the model. Put a policy layer or API gateway between the agent and every tool, run the agent in a sandboxed runtime, and keep an allowlist of tools and MCP servers. Anything off the list is unreachable, whatever the prompt says.
  4. Human sign-off for irreversible actions. Approving payments, writing to the ERP, deleting records, sending external email. The gateway should verify the approval; the agent claiming it was approved is not enough.
  5. Log plans and every tool call. Record what the agent intended, what it called, with which arguments and under which identity. Decide up front who reviews those logs and how often.
  6. Graduated response, not a kill switch. Define levels such as normal, read-only, restricted and stopped. A suspicious signal should first remove write access rather than take the whole workflow down.
  7. Inventory coding agents. Know which coding agents developers run locally, which repos and secrets they can reach, and which MCP servers they're configured to call.

A minimal gateway check might look like this:

type Mode = "normal" | "read_only" | "restricted" | "stopped";

function authorize(call: ToolCall, ctx: AgentContext): Decision {
  if (ctx.mode === "stopped") return deny("agent stopped");
  if (!ctx.allowedTools.has(call.tool)) return deny("tool not allowlisted");
  if (ctx.grant.expiresAt < Date.now()) return deny("grant expired");
  if (!ctx.user.permissions.includes(call.permission)) return deny("exceeds user authority");
  if (call.isWrite && ctx.mode !== "normal") return deny(`writes blocked in ${ctx.mode}`);
  if (call.irreversible && !ctx.hasVerifiedApproval(call.id)) return requireApproval(call);
  audit.log({ agentId: ctx.agentId, call, mode: ctx.mode });
  return allow();
}

None of these checks depend on the model behaving well. That's the whole point.

What this means for ERP, CRM and coding-agent projects

Microsoft's expense-approval example is close to many ERP workflows: an agent reads invoices, matches them to purchase orders and proposes payments. Treat every external document as untrusted input, keep the agent read-only by default, and route the posting step through an approval gate. In CRM, the risky actions are bulk updates, deletions and outbound messages, and the same rule applies.

For coding agents, the exposure is the developer's machine: source code, cloud credentials, SSH keys. Run them in containers or managed dev environments with scoped credentials rather than on a laptop with full access.

Our view at Loop: treat an agent project as an identity and authorisation project first and an AI project second. Get the identity model, permission boundaries and audit trail right, and swapping models or adopting Microsoft's controls once they're generally available becomes a configuration change rather than a rewrite.

Key takeaways

  • Microsoft now publicly frames AI agents as insiders that shouldn't be trusted by default, including the ones you build.
  • Dynamic Permissions, Dynamic Agent Risk, Dynamic Conditional Access and Guardian Agents are in preview, with no confirmed pricing or GA date.
  • The underlying pattern works today without E7: separate identity, zero standing access, enforcement outside the model, human approval and full logging.
  • Plan graduated responses (read-only, restricted, stopped) instead of a single on/off switch.
  • Inventory coding agents on developer machines; they're the agents most teams forget.