The interesting security question about AI agents in 2026 has stopped being what the model will say and started being what the software around it will let you do. Agent runtime security is where the exploitable surface now sits, and Microsoft’s August 2026 Patch Tuesday makes the case better than any argument could. This piece covers the two critical ratings, what each flaw actually allows, why the distinction between them matters operationally, the pattern the last month has established, what to check on your own deployments, and one thing we could not settle.
Two critical ratings on agent services in one release
Microsoft’s August release was enormous: roughly 398 new vulnerabilities, 62 of them rated Critical, according to the Zero Day Initiative’s review.
Two of those 62 are agent services rather than the operating system, a browser, or a database.
| CVE | Product | CVSS | Class |
|---|---|---|---|
| CVE-2026-62830 | Azure SRE Agent | 9.9 | Elevation of privilege |
| CVE-2026-59118 | Copilot Cowork | 9.3 | Elevation of privilege |
Neither is a model failure. Neither involves a prompt, a jailbreak, or anything a red team would recognize as an alignment problem. Both are ordinary authorization bugs in the plumbing that runs agents, which is precisely why they matter.
What CVE-2026-62830 actually allows
The 9.9 is the one to read carefully, because 9.9 is close to the ceiling and the vector explains why.
CrowdStrike’s analysis describes it as a missing authorization flaw, CWE-862, in which "a low-privileged remote attacker to elevate privileges over a network with no user interaction, low attack complexity, and a changed scope impact across confidentiality, integrity, and availability."
Take that apart. Low privileges required, so the attacker needs some foothold but not much. Remote over a network. No user interaction, so nobody has to click anything. Low attack complexity, meaning no unusual conditions. And a changed scope, which is the term of art that matters most here: the impact does not stay inside the vulnerable component.
Changed scope is what separates a bad bug from a very bad one. It means compromising the agent service gets you somewhere the agent service could reach, which for a site reliability agent is a deliberately large surface. You do not give an SRE agent narrow permissions, because narrow permissions would make it useless. That tension is inherent to the product category rather than a mistake in this particular service, and it means the blast radius of any authorization failure in an operations agent will always be large.
The Copilot Cowork flaw, and why the difference matters
The 9.3 is an improper authorization flaw, CWE-285, described as allowing an unauthenticated attacker to elevate privileges over a network with low attack complexity, requiring user interaction. Talos records the title as "Copilot Cowork Elevation of Privilege Vulnerability."
Two differences from the first one are worth pulling out.
It requires user interaction, which is a genuine mitigating factor and part of why it scores lower. But it needs no authentication at all, which the SRE Agent flaw does. Neither is strictly worse than the other; they trade different preconditions.
The operational point is that both are cloud-service-side. CrowdStrike’s analysis indicates the Copilot Cowork issue required no customer action. That sounds like good news and is worth reading twice: if the fix arrived without you doing anything, so did the vulnerable version, and you had no window in which to make a risk decision about either.
Agent runtime security is not model security
This is the reframe the industry keeps resisting because the model is the interesting part.
Almost all published AI security work concerns model behavior: what it can be talked into, what it refuses, how it behaves under adversarial prompting. That work is real. It is also not where these two CVEs live. Both are authorization bugs of a kind that has existed since networked software existed, sitting in the service layer that grants an agent its permissions.
We made a version of this argument in our piece on local AI agent security, where the vulnerability was in the self-hosting stack rather than the model being hosted. The same shape showed up in agentic browser security, where a boundary turned out to be a judgment call, and again in the package registry piece, where a medium-severity flaw in ordinary infrastructure was the doorway.
Three different components, one recurring structure: the model was not the weak part. The thing standing between the agent and the rest of your estate was.
The pattern across August
Put the month together and it reads consistently.
An SRE agent with a missing authorization check and changed scope. A collaboration agent with improper authorization and no authentication requirement. A package registry proxy whose 6.8 medium was enough to reach 41 production servers. And, from the independent investigation we covered in the METR and Redwood findings, a shared package cache doubling as a covert coordination channel between sandboxes that were supposed to be isolated.
None of those is a model doing something clever. All of them are agents having more reach than the surrounding controls accounted for, which is a permissions and architecture problem rather than an AI problem.
That should be mildly reassuring, because it means existing security practice applies. It should also be uncomfortable, because existing security practice is not currently being applied to these components with much rigor.
There is a structural reason for the gap. Agent features are arriving inside products organizations already own, which means they frequently bypass the review that a new vendor would trigger. Nobody runs a security assessment when a checkbox appears in a product already in production. So the agent runtime security posture of most organizations is the sum of defaults set by several vendors independently, none of whom knows what the others granted.
What to check on your own agent deployments
Five things, in the order that reduces the most exposure per hour spent.
Inventory which agent services you actually run. Most organizations have more than they think, because agent features arrive inside products already purchased rather than as separate procurement decisions.
Establish what each one’s identity can reach. An SRE agent’s credentials are the interesting target, not the agent. Ask what an attacker holding that identity could do next.
Find out which are cloud-side and which you patch. For the cloud-side ones you have no patch window and no decision to make, so the control you have is scope, not timing.
Check scope-changed findings differently. A changed-scope elevation of privilege in a component with broad permissions is worse than its number alone suggests, and better than its number suggests in a component that is properly boxed in.
Write down what would make you turn an agent off. Deciding that during an incident is how the June 27 call in the Hugging Face timeline got made, and reasonable people make poor decisions under time pressure without criteria written in advance.
None of these five require new tooling, and none of them are specific to AI. They are asset inventory, identity scoping, patch ownership, severity triage in context, and an incident criterion. Agent runtime security is, at this stage, mostly the unglamorous work that was already on the list, applied to a category of component that arrived faster than the process around it. The Microsoft Security Update Guide is the authoritative record for anything in this post.
What we could not settle
One sourcing note, because it affects how much weight to put on the second CVE.
The Zero Day Initiative’s table lists CVE-2026-59118 as Microsoft Power Apps rather than Copilot Cowork. Talos and CrowdStrike both attribute it to Copilot Cowork, and Talos quotes the advisory title directly, so we have gone with Copilot Cowork on a two-to-one basis with the more specific citation on the majority side.
It is a discrepancy worth knowing about rather than papering over. The CVSS score, the class of flaw and the conclusion about where agent runtime security risk sits are unaffected either way, because Power Apps would be the same argument in a different product. But if you are patching against a specific inventory, verify the product against Microsoft’s own advisory rather than trusting any secondary source, including this one.
Frequently Asked Questions
What is CVE-2026-62830?
A missing authorization flaw (CWE-862) in Azure SRE Agent rated CVSS 9.9. It allows a low-privileged remote attacker to elevate privileges over a network with no user interaction, low attack complexity, and changed scope across confidentiality, integrity and availability.
What does “changed scope” mean and why does it matter?
It means the impact is not confined to the vulnerable component. Compromising the service gets an attacker into things the service could reach. For an agent with broad operational permissions, that reach is the whole point of the product, which is what pushes the score to 9.9.
Do I need to patch these myself?
It depends which one. The Azure SRE Agent issue requires patching. The Copilot Cowork issue is reported as requiring no customer action, which means it was fixed service-side. Verify both against Microsoft’s own advisory for your specific inventory.
Is this an AI safety problem?
No, and that is the point. Both are ordinary authorization bugs in service code. No prompt, jailbreak or model behavior is involved. They are the kind of flaw that has existed for as long as networked software has.
How big was the August 2026 release overall?
Roughly 398 new vulnerabilities, of which 62 were rated Critical, per the Zero Day Initiative. The two agent-service CVEs are a small fraction of that, which is part of why they were easy to miss.
Why are agent services showing up in Patch Tuesday now?
Because they are now shipping products with real permissions rather than previews. Neither vendor commentary we reviewed offers an explanation for the trend, so treat the pattern as an observation about August rather than a stated position from Microsoft.
What should we prioritize if we only do one thing?
Inventory. Most organizations underestimate how many agent services they run, because agent capabilities increasingly arrive inside products already bought rather than through a separate purchase. You cannot scope permissions on something you have not listed.
Is the Copilot Cowork attribution reliable?
Two first-tier sources say Copilot Cowork and one says Power Apps. We went with the majority, and with the source that quotes the advisory title directly, but flagged it rather than hiding it. Check Microsoft’s advisory before acting on the product name.
