Two agent vulnerabilities scored above 9.0 this month and neither one involved a language model. CVE-2026-62830 reached 9.9 because a missing authorization check in Azure SRE Agent let a low-privileged caller ride the agent's managed identity into everything that identity could reach — and Microsoft fixed it service-side, so there was never a patch for you to apply. The severity was set by a grant you made months earlier, which is the only part of it you ever controlled.
At a glance
The two highest-scoring agent vulnerabilities in Microsoft's August 2026 release, both in the same weight class and both the same bug class.
| CVE | Product | CVSS | Class |
|---|---|---|---|
CVE-2026-62830 |
Azure SRE Agent | 9.9 — scope changed | Missing authorization; broken on-behalf-of flow |
CVE-2026-59118 |
Microsoft Copilot Cowork | 9.3 — unauthenticated, network | Improper authorization (CWE-285) |
Both landed inside a Patch Tuesday of roughly 415 CVEs, 62 of them critical. Neither is a prompt-injection story, neither involves jailbreaking, and neither required the attacker to say anything clever to a model. They are the kind of authorization defect that has shipped in web applications for twenty-five years — sitting this time in front of a credential that was handed to software allowed to act on its own.
A 9.9 is a statement about your subscription, not about the agent
The detail that pushed CVE-2026-62830 to 9.9 rather than 8-point-something is a single flag in the CVSS vector: Scope Changed. Scope change means the vulnerable component and the impacted component are not the same thing — an attacker who compromises the agent does not merely get the agent, they get across a security boundary into systems the agent was trusted by. In this case the boundary crossed was the on-behalf-of token exchange, and what waited on the other side was the agent's managed identity: runbooks it could rewrite, telemetry it could read, incident tooling it could drive, and every Azure resource anyone had granted it a role on.
Read that back and the load-bearing quantity becomes obvious. CVSS did not measure how capable the agent was, how good the underlying model was, or how autonomous the product had been configured to be. It measured the size of the set of things reachable through one identity. That set is not a property of Microsoft's software. It is a property of your role assignments.
This is the part worth internalising, because it generalises well past this one CVE. An SRE agent is attractive precisely because it can act: restart the app service, scale the plan, roll back the deployment, page the on-call. Every one of those capabilities is a role assignment, and the aggregate of those assignments is the severity ceiling for every future authorization bug in the product. You are not choosing how autonomous the agent feels. You are choosing the worst-case blast radius of a defect that has not been found yet.
Copilot Cowork: the same class, one tier down, a different attacker
CVE-2026-59118 in Microsoft Copilot Cowork is improper authorization — CWE-285 — at 9.3, and its vector differs from the Azure one in an instructive direction. It does not require the attacker to be authenticated at all. It does require user interaction, which is the usual shape of a collaboration-surface bug: something arrives, somebody in the tenant opens it, and the authorization check that should have stopped the resulting action never runs.
The pairing matters because the two CVEs bracket the agent attack surface from both ends. The Azure bug is the insider path — a legitimate but low-privileged principal escalating through the agent's own credentials. The Cowork bug is the outsider path — an unauthenticated party reaching in through a surface designed to accept input from outside the organisation. Both bypass the control plane rather than the model. An agent product is a normal multi-tenant web service that happens to hold unusually broad delegated authority, and it inherits every failure mode of a normal multi-tenant web service.
If your agent threat model is a document about prompt injection, it is a document about one attack path out of several — and not the one that produced this month's two highest scores. The agentic threat model has to include the agent's own service plane as an asset, with the same authorization review any other service gets.
Your vulnerability runbook has a patch step. This class of bug does not.
Microsoft mitigated CVE-2026-62830 on the service side and told customers no action was required. That sentence is genuinely good news for exposure duration and genuinely disorienting for anybody running a vulnerability-management programme, because almost every control in such a programme assumes there is an artifact to update and a version to confirm.
Walk the standard steps against a service-side fix and most of them evaporate. There is no build number to record, so the asset inventory learns nothing. There is no patched version to scan for, so the scanner cannot confirm remediation. There is no rollback, so change control has nothing to approve. There is no maintenance window, because the change already happened. What is left is a compliance artifact — the vendor's advisory — filed against an asset you cannot inspect.
The three questions that do survive are these, and they are all questions about your own environment rather than the vendor's:
| Question | Where the answer lives | When you had to prepare it |
|---|---|---|
| What could the agent's identity reach during the exposure window? | Your role assignments, as they were on the day — not as they are now | Before disclosure |
| What did it actually do? | Control-plane logs, with retention covering the whole undisclosed window | Before disclosure |
| Would you have noticed? | Alerting on anomalous use of a non-human identity | Before disclosure |
Every one of those is set in advance. That is the uncomfortable structural point about vendor-operated agents: the response window opens after the vendor has already closed the hole, so the only work that changes your outcome is work finished before you had any reason to do it. See audit trails for what the second row requires in practice, and agent inventory & registry for the first.
The exposure window is longer than the advisory implies
A disclosure date tells you when the fix shipped. It does not tell you when the defect was introduced, and for the question a security team actually has to answer — was this exploited against us — the interval that matters runs from introduction to remediation, not from publication to remediation. For a service-side fix you are usually not told the first date at all.
This is where log retention stops being a cost line and starts being a capability. If your Azure activity logs retain ninety days and the feature shipped eight months ago, the honest answer to "was this used against us" is that you cannot tell, and no amount of post-incident effort will change that. Teams reliably under-invest here because retention feels like storage and is really evidence. The same argument, generalised, is in trace sampling & retention: what you keep decides which questions remain answerable later.
A practical shortcut for the anomaly question: a managed identity used by an SRE agent has an extremely regular behavioural signature. It touches a stable set of resource types, from a stable set of service principals, on a schedule that tracks incidents. Deviations from that baseline are far easier to alert on than deviations in human behaviour, which is an advantage worth taking — non-human identities are the easiest thing in your estate to baseline, and almost nobody does it.
What this should change about where the security budget goes
None of this argues that prompt injection is unimportant; it remains the defect class unique to this kind of software, and the defence work is real. The argument is about proportion. Injection research is where the attention is; ordinary authorization review of the agent's control plane is where this month's two nine-point scores came from, and that review is a thing security teams already know how to do.
Four items, in rough order of how much they would have reduced August's exposure:
- Scope the identity to the job, not to the roadmap. Agent products are provisioned generously during a pilot and never re-scoped, because narrowing a permission is a change nobody is rewarded for. Re-scoping is the single highest-leverage action here and it is available today — scoped credentials for agents.
- Separate identities per environment and per capability. One identity that can both read telemetry and rewrite runbooks converts an information-disclosure bug into a persistence bug. Two identities do not.
- Keep the human principal on the record. When an agent acts for a user, the audit entry should name both. This is exactly the property that a broken on-behalf-of exchange destroys, which makes it the thing you want logged independently — see decision receipts & audit.
- Ask the vendor the two questions that are hard to answer. Not "are you SOC 2" — every agent vendor is. Ask what their notification commitment is for a service-side fix, and whether you can retrieve control-plane logs for the agent's actions in your tenant. Third-party model & vendor risk covers the rest of that conversation.
Do this first: list every non-human identity your agent products hold, and for each one write down the worst thing it could do if an authorization check failed tomorrow. You will find at least one grant nobody can justify, and removing it is the only part of August's two CVEs you could have influenced.
FAQ
Do I need to do anything about CVE-2026-62830?
There is no patch to apply — Microsoft mitigated it on the service side and stated no customer action is required. What remains is a review rather than a remediation: audit the managed-identity assignments the agent holds, check RBAC against what the agent actually needs, and look for anomalous privilege use in control-plane logs across the window the identity existed.
Why did a missing authorization check score 9.9 when the agent itself was not remotely exploitable code execution?
Because of the Scope Changed flag in the CVSS vector. Scope change means the impact crosses a security boundary from the vulnerable component into other systems, and here the crossing was into everything the agent's managed identity had a role on. The score reflects reachable resources, which is a function of how the identity was provisioned rather than of the agent's code.
Is this a reason not to use vendor-operated agents?
No — a service-side fix closed the hole faster than any customer patch cycle would have. The trade is speed of remediation against loss of verifiability: you get a fix before you are told, and you get no version to confirm and no rollback. Decide that trade deliberately rather than discovering it during an advisory.
How does this differ from a prompt-injection risk?
Prompt injection subverts the model's behaviour to make the agent misuse the permissions it legitimately holds. These CVEs skip the model entirely — the authorization check in the service plane failed, so an attacker used the agent's credentials directly. Injection defences do not help, and injection-focused threat models do not surface this class at all.
What is the on-behalf-of flow and why does breaking it matter so much?
It is the token exchange that lets a service call a downstream resource using the calling user's identity instead of its own, so downstream permission checks see the human. When it fails, the downstream call falls back to the service's own credential — which for an agent is a broad managed identity — and the caller inherits authority they were never granted.
Further reading
On this wiki:
- Scoped credentials for agents — issuing, narrowing and expiring the grants that set your blast radius.
- Agent identity — how a non-human principal should be represented and audited.
- Third-party model & vendor risk — what to ask an agent vendor before signing.
- Incident response for agents — running the response when the acting party was software.
- Agent identity & attestation — the deeper treatment of delegation and proof.
- Inference hooks move the DLP boundary — another case where the control point moved out of your codebase.