Microsoft published the “AI agent shared responsibility model” document on Microsoft Learn, updated on August 26, 2026, and for the first time extended Azure's shared responsibility model to autonomous AI agents. Unlike standard LLMs, these agents invoke tools and APIs, write data, store persistent memory, and act under their own identity with delegated tokens, which required separate risk labeling. The document's key takeaway: in almost all deployment models, including ready-made SaaS agents, the customer is responsible for agent instructions, tool selection, per-tool permissions, memory isolation, and human confirmation of irreversible actions. The document is fully available online and serves as a checklist for any agentic stack, not just Azure.

image

What happened

The “AI agent shared responsibility model” document, dated August 26, 2026, was published on Microsoft Learn. It adds three agentic layers to the existing cloud model: the agent orchestration layer (the “brain loop” — planning, tool selection, inter-agent coordination), the tools and actions layer (connectors, plugins, MCP servers, APIs that change real-world state), and the agent memory and state layer, where knowledge can be stored across sessions. Security requirements are specified for each layer. Responsibility is mapped using a C/M/S matrix, where C — customer, M — Microsoft, S — shared responsibility; the matrix is expanded across three deployment models, including ready-made SaaS agents like Microsoft 365 Copilot and Security Copilot.

Context

The classic Azure shared responsibility model described AI through three layers: AI platform, application, and usage. It assumed that the trust boundary runs around model inference: the platform is responsible for the service, and the customer is responsible for how it is used. Autonomous agents break this assumption because their primary surface is not text but actions: tool invocations, data writes, persistent memory, and delegated tokens. The document maps characteristic agentic risks to these surfaces: prompt injection leading to real actions, excessive agency, memory poisoning, unbounded loops, and costs. Importantly, these risks are aligned with existing taxonomies — OWASP Top 10 for LLM, OWASP Top 10 for Agentic AI, MITRE ATLAS, and the MSRC classification — so the document speaks the language already familiar to security teams.

Why this matters for the industry

For the industry, this is not a product release but a working specification of responsibility zones: agentic specifics — actions through tools, persistent memory, delegated identity — are formally built into Microsoft's cloud security model for the first time. The C/M/S matrix fixes an uncomfortable fact: the customer is responsible for tool selection, per-tool permissions, memory isolation, and human confirmation of irreversible actions even in a SaaS model — the vendor explicitly removes the illusion that an “agent is safe out of the box.” In practice, the document gives companies a ready-made template for internal security policies, audit programs, and contractual allocation of responsibility zones when deploying enterprise agents on Azure, and for teams building agentic products, its layers become a map of product surfaces: from managing per-tool permissions to approval gates and memory isolation.

Why this matters for users

For those building or deploying agents, the document provides a specific checklist: least privilege for each tool instead of one broad, persistent agent identity; re-authorization for each action, not just at login; mandatory human confirmation for deletions, payments, and production changes; memory isolation by users and tenants against “memory poisoning”; and limits on steps, loops, and orchestration budget. These items can be applied to a current project as a review list today: re-audit agent identities, enable human confirmation for irreversible operations, and check who can read and modify agent memory. The principles are not tied to Azure and apply to any agentic stack, and the material itself is free and fully available on learn.microsoft.com.

What is still unknown / limitations

The document contains no methodology: it is a taxonomy and checklist, not a research paper. It has no benchmarks, metrics, or measurements of the resilience of the proposed measures to prompt injection or confused deputy attacks, so reproducibility is reduced to “applied or not applied” without quantitative validation. The alignment with OWASP Top 10, MITRE ATLAS, and MSRC consists of cross-references to existing taxonomies, meaning a risk vocabulary useful for procurement and audit terminology, not validation of the approach. Finally, scenarios for further spread of the labeling — copying by other vendors, embedding into frameworks, and tender requirements — remain interpretations, not facts from the source.

Sources

Author

Look at AI, editorial team