The AI Agent Has Its Own Identity. And It Just Got a 9.9.

Microsoft's Patch Tuesday on August 11 shipped 421 CVEs. Two of them sit inside the vendor's own AI agents and share the same class of flaw. The higher-severity one is CVE-2026-62830 in Azure SRE Agent, Microsoft's autonomous site-reliability agent — the one that reads incidents, executes runbooks, and modifies live infrastructure without a human in the loop. CVSS 9.9. Scope Changed. Blast radius extends past the agent itself to every resource its identity can touch.

That last sentence is the story. The rest is the mechanism.

What CVE-2026-62830 actually is

Azure SRE Agent runs as its own identity in a customer's Azure environment. When a task requires a permission the agent does not hold, it uses the on-behalf-of (OBO) elevation flow — the standard OAuth 2.0 pattern in which a service, holding a delegated token, acts as the calling user against a downstream API. OBO is meant to enforce the identity boundary in both directions: the agent gets the user's permissions for the specific downstream call, no more, no less.

CVE-2026-62830 is a CWE-862 missing-authorization flaw in that flow. Per CryptoRank's breakdown of the disclosure, an authenticated attacker with low privileges can trigger the flow such that the agent's own managed-identity permissions are inherited instead of being scoped down to the user's. The attacker gets the agent, and the agent gets the environment. Runbooks, telemetry feeds, incident tools, every Azure resource on the agent's allowlist. Microsoft's own vector string is Scope Changed — a formal acknowledgement, in the CVSS grammar, that the vulnerable component and the impacted component are not the same thing. The bug is in the agent; the damage is downstream.

Microsoft says the vulnerability was fully mitigated at the cloud service level with no user action required. Good. The architectural point survives the patch.

And it happened twice

The same Aug 11 load includes CVE-2026-59118, an elevation-of-privilege flaw in Microsoft Copilot Cowork, another Microsoft AI-powered agent product, CVSS 9.3. Different product, different codebase, same class of failure: the agent's identity boundary got confused for the caller's identity boundary. Two agents, one vendor, one patch cycle, one shape of bug.

That is what makes this a category story rather than a product story. Cross-referenced against the Zero Day Initiative's Patch Tuesday review and Talos's coverage, these two are the standouts of the 421-CVE load — not because of the raw scores (there were others), but because both target the same architectural surface: the AI agent's managed identity and the on-behalf-of flow that plugs it into everything else.

Why the identity, not the model, is the boundary that matters

If a security team is reasoning about AI agent risk, most of the public conversation is about the model. Prompt injection, jailbreaks, refusal circumvention. That is a real surface, and one this blog covers often. But when a coding agent or an SRE agent actually causes damage in a real environment, the damage flows through the agent's own identity — the OAuth token, the managed identity, the OBO principal — and the resources that identity is allowed to touch.

An AI agent product on a cloud platform is, at its core, a program with permissions. The model is what decides what the program tries to do next. The identity is what determines whether it can. Every agent-side security control that lives at the model layer only — content filters, refusal training, safety monitors — is talking about the first half of that sentence. The second half, the identity boundary, has to be a separate engineering discipline, with its own tests, its own threat model, its own failure modes.

CVE-2026-62830 says the same thing in a different voice: the boundary can break independently of anything the model does. In the OBO flow, the model never had to be manipulated at all. A low-privileged attacker triggered an authenticated call and inherited the wrong identity. The agent, doing exactly what the agent is supposed to do, then acted on that identity's permissions against every downstream resource it was allowed to reach.

The pattern

This is not the first time an AI-agent identity boundary has come up in this digest. The Tenable "Agentic AI Threat Cluster" synthesis — covering seven confirmed intrusions across three threat actors — named identity and authentication exposure as the common entry point across all cluster activity. The Taiwan / Hermes+OpenClaw campaign ran for four days on the strength of federation endpoints, weak credentials, and misconfigured SSO the autonomous agents could probe at machine speed. Those were attacker-side stories. CVE-2026-62830 is the vendor-side story: same boundary, same failure mode, disclosed at the source.

The Scope Changed vector is the specific thing to sit with. When Microsoft's own CVSS string says the vulnerable component and the impacted component are different, the vendor is telling everyone downstream that the agent's identity is a distinct trust boundary from the surface Microsoft is actually able to patch. Even after the mitigation ships, every environment that has ever granted an AI agent a managed identity inherits the shape of the problem: the identity boundary is where the next disclosure will hit too, whether it comes from the same vendor or a different one, whether it's in an SRE agent or a coding agent or a browsing agent.

The runtime observation isn't in the API call itself. It's in the moment the agent's action reaches a resource its user's identity would not have reached. That is the sequence the behavioral layer has to catch — and it has to catch it whether the model was manipulated, was patched, or was doing exactly what a helpful agent is supposed to do.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.