The auth boundary that was supposed to hold

Azure AI Foundry's M365 published agents are the productized version of one of the most consequential AI-deployment patterns of 2026: an organization wires an AI agent up to its Microsoft 365 environment (mailboxes, files, calendars, Teams data, third-party connectors), publishes that agent through Foundry, and lets employees interact with it through M365 surfaces. The agent runtime brokers each call: when a user asks the agent to "pull the Q1 financial deck," the runtime checks the user's privileges, decides what the agent is allowed to do on their behalf, and dispatches the action. The entire trust model rests on that brokering being correct.

CVE-2026-35435, published in Microsoft's May 7, 2026 update guide, is the disclosure that this brokering was not correct in M365 published agents. The flaw is classified as CWE-284 (improper access control) with a CVSS v3.1 score of 8.6. Microsoft confirmed exploitation in the wild in its advisory, which is the disclosure language that usually translates to "we saw this being used before we published the patch."

What the flaw lets an attacker do

Microsoft has not released full technical detail in the public advisory, which is standard practice for an actively exploited vulnerability. The public coverage from Windows News, RedPacket Security, OffSeq Threat Radar, and the syndicated MSRC summary on Vulnerability-Lookup describes the impact at the model level:

• The agent runtime's authorization checks for M365 published agents can be bypassed by a remote attacker without prior authentication at the targeted privilege level.
• The bypass allows escalation from a low-privileged role into a role with extensive control over the AI resources the agent governs.
• In the worst case, the escalation extends from agent-level control into the underlying M365 environment that the agent is wired to.
• Possible attack mechanisms include manipulation of agent configurations and abuse of authorization flow assumptions in the runtime, consistent with the CWE-284 classification.

In M365 terms, that progression is the difference between "the attacker can see what a basic Teams user can see" and "the attacker can read the org's documents through the agent's connectors, change agent behavior to send data outbound, and persist by reconfiguring the agent itself."

Why this is an AI-agent failure and not a generic platform CVE

Vibe Graveyard's content scope draws a line between AI failures and generic platform CVEs that happen to live inside AI-related products. The line matters here because Microsoft has had plenty of platform CVEs in 2026 that do not belong on this site - DNS server bugs, kernel driver issues, identity flaws in non-AI Azure services. CVE-2026-35435 is on the right side of that line for two reasons.

First, the vulnerable component is the agent runtime's authorization logic. The runtime exists specifically to mediate AI agent actions on behalf of users and to constrain what the agent can do across M365 resources. When that authorization logic fails, the result is not a generic privilege escalation in some service; it is a privilege escalation specifically inside the path where AI agent calls are authorized.

Second, the impact path runs through the agent's own configured tool access. An attacker who escalates inside the agent runtime does not get a raw shell on Microsoft's infrastructure; they get the ability to drive the agent. What the agent can reach depends on what it was wired up to reach. In an aggressive M365 Copilot-style deployment, that can include sensitive document repositories, calendar data across the org, third-party connectors to CRM or accounting systems, and the credentials the agent uses to call those connectors. The attacker rides those connections through the AI's identity, not through a stolen platform credential.

That blast-radius shape - "compromise the agent runtime, ride the agent's already-granted access" - is the recurring failure mode across the major M365 AI security disclosures of 2026. The EchoLeak zero-click in Microsoft Copilot, the Reprompt one-click exfiltration, the Copilot chat confidential email bug, and ServiceNow Now Assist's agent-to-agent prompt injection all rely on the same structural reality: AI agents accumulate access to make themselves useful, and that accumulated access becomes the prize when the agent runtime fails to police what it should.

Defensive guidance from the advisory

Microsoft's advisory directed customers to apply the available fix and to audit the permissions granted to agent service principals. The standard mitigation advice in the surrounding coverage matched what M365 security teams have been saying for the last year:

• Audit which M365 published agents exist in the tenant, who deployed them, and what scopes their service principals have. Many enterprise tenants accumulated published agents through individual user actions and never produced a central inventory.
• Apply the principle of least privilege to those service principals. An agent designed to read calendar invites does not need write access to SharePoint document libraries.
• Rotate any credentials or connectors that a compromised agent could have reached, especially in tenants where the exploitation window is uncertain.
• Treat Foundry's audit logs as the primary source of truth for which agents performed which actions during the vulnerable window, and review for unexpected reconfiguration events.

None of that guidance is unfamiliar to teams that have been running Copilot deployments through 2025 and 2026. The CVE underscores how exposed those teams are when the runtime they depend on for authorization decisions fails.

The graveyard lesson

The defining property of agent-mediated access is that the agent's permissions get aggregated up from the things it needs to do. By design, an M365 agent that is useful for an executive assistant role ends up with broad access across the executive's surface area. That aggregation is the point. The cost of that point is that any failure in the runtime's authorization checks - any path by which an unauthorized caller can claim the agent's privileges - becomes a high-impact incident, because the agent already has a lot of access on file.

CVE-2026-35435 is the May 2026 entry in this pattern, alongside the OpenClaw Claw Chain CVEs and the Microsoft Semantic Kernel RCE-via-tool-call disclosures from the same window. Each tells a different version of the same story: AI agent platforms collect access, mediate it through a runtime, and depend on that runtime being correct. When the runtime is wrong, the resulting blast radius is the union of everything the agent could already reach.

For operators, the practical lesson is that the audit you need is not "is this AI feature secure" in the abstract. It is "if this agent's auth checks failed today, what could an attacker reach through it." If the answer to that question makes you uncomfortable, the agent was over-privileged before the CVE. The CVE just made the discomfort visible.