Microsoft just published its AI Agent Shared Responsibility Model, and if you're hoping for a get-out-of-jail-free card when your autonomous agent inevitably does something unexpected, you're going to be disappointed. The document, available on Microsoft Learn, lays out in granular detail who owns what across the entire agent lifecycle—from orchestration brains to tool invocations to memory poisoning defenses. And spoiler: Microsoft isn't volunteering for much.

Why Agents Break the AI Security Mold

Traditional LLMs follow a simple request/response pattern. You prompt, it answers, you decide what to do with the output. AI agents don't give you that luxury. According to Microsoft's framework, an agent acts autonomously, invoking tools and triggering workflows without human approval at each step. It plans and loops, decomposing goals and repropmting itself multiple times before returning results. It holds state across sessions—short-term context plus persistent memory that influences future behavior. It authenticates with its own identity using managed identities or on-behalf-of tokens. And it can compose with other agents, where one agent's output becomes another's instruction, introducing entirely new trust boundaries. Each of these capabilities introduces responsibilities that flat-out don't exist in the standard request/response AI model.

Three Tiers of Accountability

The framework defines three deployment models with sharply different responsibility splits. SaaS agents like Microsoft 365 Copilot agents or Security Copilot have Microsoft operating the orchestrator, model, safety systems, and most tool connectors—you handle configuration, data scoping, identity, and usage. PaaS agents built on Microsoft Foundry Agent Service or custom Copilot Studio agents put you on the hook for instructions, tool selection, permissions, orchestration logic, memory design, and agent identity. IaaS agents—where you're building everything from scratch on VMs or containers—are essentially your problem end-to-end except physical infrastructure and base model weights. The principle is straightforward: responsibility shifts left as you move toward more customization. More control means more accountability, period.

The New Attack Surface Nobody Warned You About

Here's where things get interesting for the security crowd. Microsoft's framework identifies three new architectural layers unique to agentic systems that introduce fresh risk categories. The orchestration layer—your agent's brain loop of planning, reasoning, and tool selection—is where excessive agency and prompt-injection-to-action risks live. The tools and actions layer contains connectors, plugins, APIs, and MCP servers the agent can invoke to manipulate real-world state. This is described as 'the biggest difference from the LLM model.' The memory and state layer covers both short-term conversation context and persistent stores that influence future behavior—and can be poisoned. Each layer demands specific controls: least privilege per tool, authorization checks on every action not just session start, human-in-the-loop gates for high-impact operations like writes or payments, sandboxing for code-execution tools, memory isolation to prevent cross-tenant bleed, and audit logging with inputs, outputs, identity used, and decision rationale for every invocation.

Top Agent-Specific Risks to Design Against

Microsoft's framework maps these risks to OWASP Top 10 for LLM Applications, the new OWASP Top 10 for Agentic AI, MITRE ATLAS, and MSRC vulnerability severity classifications. Prompt injection to action leads the list—untrusted content like a webpage or email hijacking your agent into malicious tool invocations. Excessive agency follows: agents with more tools, permissions, or autonomy than tasks require. Then there's confused deputy risk where an agent uses privileged identity for actions the requesting user can't perform themselves. Memory poisoning lets injected content persist and retrigger later or across sessions. Unbounded loops can cause runaway planning that exhausts resources and budgets. Multi-agent trust failures mean a compromised or hallucinating agent contaminates collaborators downstream. Rogue agents—unauthorized agents acting in your environment or spoofed identities—round out the list.

Key Takeaways

  • Autonomy never reduces accountability, per Microsoft. Granting an AI agent more freedom means taking on more responsibility regardless of deployment tier.
  • Treat all tool outputs, retrieval results, and inter-agent messages as untrusted input—not trusted instructions requiring validation at every boundary.
  • Authorization isn't a one-time session check—reauthenticate permissions for each action on each resource to mitigate confused-deputy risks.
  • Human-in-the-loop gates are non-negotiable for writes, deletes, payments, production changes, and external communications.
  • Memory is sensitive data: encrypt stores, enforce access controls, classify contents, track provenance, and apply retention policies.

The Bottom Line

Microsoft just drew the map of accountability for AI agents—and it's a minefield for anyone who thought autonomous systems meant less work. The framework makes one thing brutally clear: if you're deploying agentic AI without understanding these responsibility boundaries, you're not ahead of the curve—you're exposed. Start with SaaS, move to PaaS only when necessary, and treat IaaS agent builds as a serious commitment that requires dedicated expertise in AI security, identity management, and autonomous-systems risk. The agents are coming whether enterprises are ready or not.