Most vulnerability processes are built around a single assumption: a disclosure arrives, and somewhere downstream a person applies a fix. On 6 August 2026 Microsoft published two critical vulnerabilities that break the assumption completely. Both sit in cloud AI agent services, both are authorisation failures, and both arrived with the work already done.
CVE-2026-62830 affects Azure SRE Agent and carries a CVSS base score of 9.9. The description is one sentence: missing authorisation in Azure SRE Agent allows an authorised attacker to elevate privileges over a network. CVE-2026-59118 affects Copilot Cowork and scores 9.3, described as improper authorisation allowing an unauthorised attacker to elevate privileges over a network. The first is classified as missing authorisation, the second as improper authorisation.
Then the line that changes what you can do about it. Both records state that the vulnerability has already been fully mitigated by Microsoft, and that there is no action for users of the service to take. Neither was recorded as publicly disclosed or exploited at release, and both vectors record the remediation level as an official fix with the report confidence confirmed.
So a critical authorisation failure existed in a service your organisation may be running agents on, was fixed without your involvement, and will never appear in a vulnerability scan, a patch backlog, or a compliance percentage. Nothing about your control environment changed. Nothing about your risk position was ever visible to you.
What is actually being disclosed here?
The severity is not the interesting part. The interesting part is where the impact lands.
Both vectors record the scope as changed. In CVSS 3.1 that field distinguishes a vulnerability whose impact is confined to the vulnerable component from one whose impact reaches beyond it, into resources governed by a different security authority. For an agent service, the component holding the flaw is the orchestration layer, while the resources sit behind whatever identity the agent carries. An authorisation failure in the first can express itself in the second.
That is a different shape from the vulnerabilities most AI security work has covered so far. When a real CVE landed in agent-building tooling, the component was one you host, the remedy was a version number, and the work was scheduling the upgrade. Here the component is operated by the vendor, the remedy is already deployed, and there is no version to move to. The two cases look alike in a feed and behave nothing alike in a control environment.
It is also worth being precise about what "no action for users of this service to take" does and does not mean. It means no remediation is available to the customer, because the fix has already been applied to the running service. It does not mean nobody was exposed while the defect existed, and it does not tell you whether your tenant was affected. Both records were published with the exploit code recorded as unproven and neither was flagged as publicly disclosed or exploited, which is genuinely reassuring on likelihood. None of that is the same as an assurance that nothing happened in your environment, and the disclosure is not designed to answer that question.
They also differ from the failure modes already well covered in agent security. Prompt injection through a poisoned tool description is an attack on what the model is told. A rogue agent created through a phishing link is an attack on the agent's own lifecycle. This is neither. It is an ordinary authorisation defect in ordinary cloud software that happens to sit under an agent, and it is a reminder that agent platforms carry all the failure modes of the platforms they are built on, plus their own.
Why does an unpatchable CVE break your process?
Vulnerability management is a measured discipline. It counts findings, ages them, and reports the percentage closed within a window. Every part of that machinery assumes a finding maps to an action.
Give it a critical CVE with no available action and it does one of two things. It closes the record as not applicable, which is technically accurate and buries the only signal you received. Or it leaves the record open forever against a remediation that will never happen, which corrupts the ageing metric that a board reads. Neither outcome preserves the information.
The information worth preserving is not "we are exposed". It is that a provider of a service you depend on shipped a critical authorisation defect, found it, fixed it and told you. Read as a single event, that is unremarkable and arguably reassuring. Read as a series, it is the closest thing to direct evidence you will get about how a provider builds and tests the thing you have connected to your data. That is exactly the kind of evidence an assurance function is supposed to collect, and exactly the kind that gets discarded when it arrives in the wrong queue.
The practical fix is small. Give the register a disposition that is neither open nor not applicable: recorded, no customer action available, routed to vendor assurance. The record then survives, accumulates, and can be produced.
Does your identity control actually reach the agent?
Most organisations, told that an agent platform had an elevation of privilege issue, will reach for the compensating control they already trust. In a Microsoft environment that is usually Conditional Access. It is worth reading Microsoft's own documentation before relying on it.
That documentation says, in terms, that policies targeting all users do not include agents' user accounts. It says that a Conditional Access policy targeting agent identities will not apply to the agent's user account. It lists scoping a policy to include or exclude an agent's user account by group membership as unsupported. And it says that Conditional Access only protects resources secured by Microsoft Entra ID, so an agent accessing resources with an API key bypasses the authentication and token issuance pipeline entirely, and the policies will not apply to it.
None of that is a defect. It is documented, deliberate design, and the distinction the documentation keeps drawing between an agent identity and an agent's user account is the whole point. The risk is the assurance statement written before anyone read it. "Our Conditional Access policy applies to all users" is true and, for agents, does not mean what the sentence appears to mean.
This is where the two stories join. You cannot patch the vendor's service. You can absolutely decide which identities your agents carry, which resources those identities can reach, and whether any of your agent paths authenticate in a way that routes around your policy engine. That work is fully within your control, and an unpatchable CVE is a good prompt to do it.
The same pattern shows up elsewhere in the agent stack. Microsoft documents Copilot Cowork's data protections separately from the rest of Microsoft 365 Copilot, on the basis that long-running multi-step work across apps can behave differently, and lists data classification, data loss prevention and Compliance Manager as not supported for it. Google's Gemini Enterprise release notes for 13 August 2026 describe administrators enabling a model in a region where it is not supported by confirming a warning that traffic is routed to the global endpoint, which does not support regional data residency. In each case the control gap is written down and the exception is accepted in a dialog box by whoever happened to be at the console.
What does the regulated version of this look like?
For an APRA-regulated entity, none of this needs a new framework. CPS 234 already contemplates controls operated by someone else, and it says what to do.
Paragraph 16 requires the entity to assess the information security capability of a related party or third party managing its information assets, commensurate with the potential consequences of an incident affecting those assets. Paragraph 22 requires it to evaluate the design of that party's controls that protect the entity's information assets. Paragraph 28 requires that, where the entity relies on that party's own testing of controls, it assesses whether the nature and frequency of that testing is commensurate with the standard's testing requirements.
Those three paragraphs describe precisely the situation an unpatchable CVE creates. You are relying on a third party's controls and a third party's testing. The disclosure is a data point about both. Filing it as evidence, rather than closing it as not applicable, is how the reliance becomes documented rather than assumed. The due diligence framework that CPS 234 implies for AI vendors has a natural home for this, and so does the incident-side thinking about what a vendor event starts on your side of the line.
There is a governance point underneath the compliance one. Deciding where an agent runs and what it can reach has always been the durable control. These CVEs make the reason concrete. The vendor owns the code. You own the blast radius.
Bottom line
A critical CVE that arrives pre-fixed is not good news or bad news. It is information arriving in a process that cannot hold it. Managed AI agent services will keep producing disclosures with no customer action, because that is what a managed service is, and the count will rise as more of the stack moves behind a vendor boundary. Treat those disclosures as assurance evidence about a provider, keep them where an assurance function can read the series rather than the incident, and spend the response effort on the part you actually control: which identity your agents carry, and what that identity can reach.
Do this Monday
- Add a disposition to the vulnerability register for a finding with no customer action available, so a pre-fixed CVE is recorded and routed rather than closed as not applicable
- Route managed AI service disclosures to vendor assurance by default, and review them as a series per provider at the next scheduled assessment rather than one at a time
- List every AI agent running in your environment and record which identity it uses to reach data, distinguishing an agent identity from the agent's own user account
- Test the assurance claim that your Conditional Access or equivalent policy covers agents, against the vendor's documented exclusions rather than against the policy's own description
- Find every agent path that authenticates with an API key or another credential that bypasses your policy engine, and decide deliberately whether it stays
- Check whether your data protection tooling covers each agent surface, since a vendor may document a surface separately and list classification or loss prevention as unsupported for it
- Ask your provider, at the next assurance touchpoint, how it notifies customers of vulnerabilities it has already remediated, because that channel is now part of your evidence chain
Primary sources
- Microsoft Security Response Center, CVE-2026-62830: Azure SRE Agent Elevation of Privilege Vulnerability, released 6 August 2026. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62830
- Microsoft Security Response Center, CVE-2026-59118: Copilot Cowork Elevation of Privilege Vulnerability, released 6 August 2026. https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-59118
- Microsoft Learn, Conditional Access for Agents in Microsoft Entra, updated 1 July 2026. https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
- Microsoft Learn, Microsoft Purview data security and compliance protections for Copilot Cowork, 22 June 2026. https://learn.microsoft.com/en-us/purview/ai-copilot-cowork
- Google Cloud, Gemini Enterprise release notes, entry dated 13 August 2026. https://docs.cloud.google.com/gemini/enterprise/docs/release-notes
- APRA, Prudential Standard CPS 234 Information Security, F2018L01745, paragraphs 16, 22 and 28. https://www.legislation.gov.au/F2018L01745/latest/text
TheAICommand. Intelligence, At Your Command.
