In This Article
- What Microsoft Disclosed in CVE-2026-35435
- Why "Exploitation More Likely" Sets the Clock
- Step One: Inventory Every Published Agent in Your Tenant
- Step Two: Audit Agent Activity in Microsoft Purview
- Step Three: Verify Patch Propagation for Tenant-Built Agents
- How ABT's Guardian Operating Model Runs the Check for You
- Frequently Asked Questions
On Thursday, May 8, 2026, Microsoft published its May 2026 Early Security Updates document. Buried in a list of thirteen CVEs sat one entry that affects almost every Microsoft 365 tenant rolling out AI agents: CVE-2026-35435, a vulnerability in the Azure AI Foundry agent runtime and the Microsoft 365 Published Agents runtime. The CVSS base score landed at 8.6. The severity rating is "Important." The Exploitability Index rating is the one to read carefully: "Exploitation More Likely."
That last phrase is the reason this advisory matters more than the CVSS number suggests. Microsoft does not assign "Exploitation More Likely" lightly. It is the highest forecast tier Microsoft applies before exploitation is confirmed in the wild, and it signals that Microsoft's own threat researchers believe attackers will operationalize this within the typical post-disclosure window. For banks, credit unions, and mortgage companies running Microsoft 365 Copilot, that means the next two weeks decide whether the agents your team is starting to depend on are part of an attack surface you have inventoried or part of one you have not.
The good news is that the patch itself is server-side. Microsoft applies the fix inside the Azure AI Foundry and Microsoft 365 service infrastructure that Microsoft hosts. You are not racing to deploy anything to endpoints. The work that remains is governance work, and it is exactly the work most financial institutions have not yet done: confirm which agents are running in your tenant, confirm what those agents are doing, and confirm that anything your own team built on Foundry has picked up the patched runtime. This article walks through that three-step check using only Microsoft-canonical tooling, and shows where ABT's Guardian operating model takes those steps off your team's plate.
What Microsoft Disclosed in CVE-2026-35435
Microsoft's May 2026 Early Security Updates document was published four days ahead of the regular second-Tuesday Patch Tuesday rollup scheduled for May 12, 2026. Microsoft cuts an early release when the security team believes a specific advisory should not wait for the monthly cycle. The document covered thirteen CVEs across Teams, Microsoft 365 Copilot, Microsoft Edge, Azure DevOps, Azure Cloud Shell, Azure Machine Learning, Azure Managed Instance for Apache Cassandra, Azure Notification Service, Microsoft Entra ID, Microsoft Partner Center, and Azure AI Foundry. One CVE in that list, CVE-2026-35435, sits inside the AI agent infrastructure that Microsoft 365 customers are actively rolling out for productivity work.
The affected components are precise. Microsoft lists them as "Azure AI Foundry agent runtime" and "Microsoft 365 Published Agents runtime." Those are the execution layers that host code-first agents built in Azure AI Foundry and the published agents that show up in users' Microsoft 365 Copilot Chat experience after a tenant administrator approves them. The CVE does not affect the Copilot Chat user surface directly, the Microsoft 365 admin center, or Entra ID identity infrastructure. It affects the runtime where agents do their work.
Because the vulnerable code runs inside Microsoft-hosted Azure infrastructure, Microsoft is the party that deploys the patch. Tenants do not push an update from their side. That part of the response is automatic, and Microsoft confirms patch propagation through MSRC over the days following disclosure. What is not automatic is the work of confirming that your tenant's agent footprint is what you think it is, and that any agents you or your partners built on Foundry have actually picked up the patched runtime version once Microsoft signals propagation is complete.
What This Means for Your FFIEC IT Examination
Federal examiners increasingly ask financial institutions to describe their AI governance posture. "We use Microsoft 365 Copilot" is no longer a sufficient answer. Examiners want to see an agent inventory, a documented review process for new agents, an audit trail of agent activity, and an incident response plan that contemplates AI agent compromise. CVE-2026-35435 is the kind of event that turns into an examination question six months from now. The institutions that can answer it cleanly are the ones that ran the three-step check this week.
Why "Exploitation More Likely" Sets the Clock
Microsoft's Exploitability Index is a four-tier scale that grades how likely a given CVE is to be exploited in the wild. Reading the labels in plain English: the bottom tier means "no realistic threat model puts attackers at risk of building a working exploit." The top tier means "exploits are already in the wild." Most CVEs land somewhere in the middle.
The middle is where the labels do real work. "Exploitation Less Likely" tells you Microsoft assesses that operational exploitation is possible but unlikely. "Exploitation More Likely" tells you Microsoft assesses the opposite: that operational exploitation is more likely than not within the typical post-disclosure window, even though no in-the-wild activity has been confirmed yet. CVE-2026-35435 carries the "More Likely" rating, which is the highest forecast tier Microsoft applies before exploitation is detected.
| Exploitability Index Tier | What Microsoft is Saying | Typical Response Posture |
|---|---|---|
| Exploitation Detected | Exploits confirmed in the wild. Active operational threat. | Treat as incident. Emergency change control. |
| Exploitation More Likely | Highest forecast tier before in-the-wild confirmation. Microsoft assesses exploitation will probably happen within the post-disclosure window. | Treat as priority. Accelerated change control. Complete the verification check in days, not weeks. |
| Exploitation Less Likely | Possible but not probable that attackers will build a working exploit in the typical window. | Standard cycle. Bundle with next maintenance window. |
| Exploitation Unlikely | Working exploit is improbable within any reasonable threat model. | Standard cycle. No special handling. |
The practical reading for financial institutions is simple. Once Microsoft tags a CVE "Exploitation More Likely," the realistic window before a working exploit appears in commodity tooling is measured in days, not months. The window before that exploit appears in tooling that targets AI agent runtimes specifically is shorter because the attack surface is new and the defender community has fewer detections in place. Waiting for "Exploitation Detected" before completing the three-step check is the wrong reading of the index.
"Exploitation More Likely" is the highest forecast tier Microsoft applies before in-the-wild confirmation. For banks, credit unions, and mortgage companies, that means the next two weeks decide whether the patch propagation question is answered cleanly or left to discovery.
Step One: Inventory Every Published Agent in Your Tenant
The first check is the one most financial institutions have never run: a complete inventory of the AI agents that are currently published into their Microsoft 365 environment. Microsoft makes the inventory available in two places, and they show slightly different views.
The first place is the Microsoft 365 admin center, under Copilot, then Agents. The Microsoft Learn documentation calls this the agent registry. The registry lists three classes of agents: first-party agents Microsoft built and made available globally, third-party agents from the Agent Store that vendors built and made available to tenants, and tenant-built agents that someone in your organization built in either Copilot Studio or Azure AI Foundry and published into the tenant. The Requests tab shows agents pending administrator approval before they go live for users.
The second place is the Microsoft 365 admin center usage report. Under Reports, then Usage, then the Microsoft 365 Copilot page, there is an Agents tab. The usage report shows agent activity by user and by agent name across the tenant. Reading the two views together is what tells you the real story: the registry shows what is allowed, the usage report shows what is actually being used.
A regional bank running Microsoft 365 Copilot pulls the agent inventory for the first time. The registry shows eleven agents approved. Nine were approved before the bank had a documented agent review process. Two were approved last quarter using the process. The usage report shows that six of the eleven have any activity at all in the past 30 days. Three of the unused agents are tenant-built, and nobody currently on staff remembers who built them.
The discovery is the work. The bank now has a list of agents to triage: three to deprecate (tenant-built and unused), two to document (third-party and used), and six to confirm against the published-runtime patch verification in Step Three. The agent inventory is a one-time foundational exercise that turns into a quarterly governance review once it exists.
For institutions that have not turned on Microsoft 365 Copilot yet but are planning to, the inventory exercise is still worth running. Even tenants without a Copilot license can have agents present from Copilot Studio licensing or from Power Platform usage. The registry tells you what is there regardless of which license paid for it.
Want a baseline read on your Microsoft 365 security posture before the agent inventory?
Our free Security Grade tool benchmarks your Microsoft 365 configuration in five minutes and gives you a one-page picture of where the AI agent governance gaps overlap with the broader hardening work. No login required, no sales call attached.
Step Two: Audit Agent Activity in Microsoft Purview
The second check happens in Microsoft Purview, which is the data governance and audit platform that ships with Microsoft 365. Two places inside Purview matter for AI agents: the Audit solution and Data Security Posture Management for AI (DSPM for AI).
The Audit solution captures detailed records of what users and agents do. For Copilot and agent activity specifically, Microsoft surfaces three operation names in the unified audit log: CopilotInteraction, AIAppInteraction, and ConnectedAIAppInteraction. Filtering the audit log by those operations, or by Workload set to Copilot, returns the agent invocation history for the tenant. Each record includes the user identity, the timestamp, the agent involved, the prompt the user sent, the response the agent returned, and references to any source documents the agent accessed (with sensitivity labels included).
DSPM for AI is the more curated view. Microsoft positions it as the governance lens on AI activity rather than the raw audit feed. Inside DSPM for AI, Activity Explorer shows agent interactions filtered for sensitive content, unethical AI usage signals, and policy-flagged events. The report rolls up total interactions, sensitive interactions, and interactions that touched sensitivity-labeled data. The relationship between Audit and DSPM for AI is the same as the relationship between a security information and event management system and a curated security analytics dashboard. Audit is the raw signal. DSPM for AI is the picture you show your audit committee.
For the specific case of CVE-2026-35435, the practical reading of the audit signal in the days after disclosure is not "find the exploit." Microsoft has not confirmed exploitation, and a generic Purview audit query is not going to surface an AI agent runtime compromise on its own. The reading is "establish the baseline." Pull the agent invocation log for the last 30 days, store it somewhere your security team can compare against later, and put the query on a recurring schedule. If exploitation is confirmed in the wild over the next several weeks, the baseline is what lets your team determine whether agent invocation patterns in your tenant changed.
Microsoft Purview Audit captures Copilot and agent invocations via the CopilotInteraction, AIAppInteraction, and ConnectedAIAppInteraction operations in the unified audit log. DSPM for AI takes the same signal and presents it in Activity Explorer with sensitivity labels, sensitive data flags, and policy events. Banks, credit unions, and mortgage companies running Microsoft 365 already have the audit capability provisioned with their Microsoft 365 E5 or Purview Audit Premium licensing. The check we describe in this article uses only configuration that ships in the box. No additional third-party SIEM or AI monitoring tool is required to get the agent baseline.
Step Three: Verify Patch Propagation for Tenant-Built Agents
The third check applies specifically to financial institutions whose teams (or technology partners) have built agents in Azure AI Foundry and published them into Microsoft 365 Copilot. The Foundry-to-Copilot publishing path is documented on Microsoft Learn and looks roughly like this: a developer builds and tests an agent in the Azure AI Foundry portal using prompt agents or hosted agents, gets the Azure AI User role on the Foundry project, and then publishes the stable agent endpoint to Microsoft 365 Copilot and Teams. Publishing handles Entra ID identity, Azure Bot Service registration, and the agent manifest automatically. The tenant administrator then approves the agent in the Microsoft 365 admin center before users see it.
When CVE-2026-35435 lands, Microsoft patches the Foundry agent runtime server-side. The patched runtime is the version that runs your agent the next time an end user invokes it. The verification step is to confirm, after Microsoft signals that propagation is complete, that your specific published agent endpoint is actually running on the patched runtime version and not on a cached older version that somehow held over. Microsoft documents this through the Foundry portal's observability features.
Tenants without custom-built Foundry agents have less to verify, but the inventory check still matters
If nobody on your team has built or published an agent on Azure AI Foundry, the patch propagation question is entirely Microsoft's. Your three-step check ends with the agent inventory and the Purview audit baseline. Read the inventory carefully though: tenant-built agents do not always come from your in-house development team. Implementation partners, mortgage technology vendors, and managed service providers often publish agents under partner identities into customer tenants. Anything in the registry that says "tenant-built" is worth a five-minute conversation with whoever owns the development relationship.
For institutions that are running a Foundry-built agent in production, the verification workflow is straightforward. Open the agent in the Foundry portal. Navigate to the Operate section, which shows real-time metrics and the runtime version currently serving the agent. Confirm the runtime version matches Microsoft's published "patched" version for CVE-2026-35435 (Microsoft publishes the version number in the MSRC entry after propagation completes). If the runtime is still on the prior version 48 hours after Microsoft's propagation signal, file a ticket with Microsoft support. Most of the time, the runtime catches up automatically within the propagation window, and the verification is a five-minute confirmation, not a remediation project.
How ABT's Guardian Operating Model Runs the Check for You
The three-step check is straightforward once a financial institution has run it once. The problem is that most institutions are running it for the first time, against an AI agent footprint that has been growing quietly for the past 18 months, with no internal team that has time to add quarterly Copilot governance reviews to its backlog. This is where ABT's Guardian operating model fits.
Guardian is how ABT manages Microsoft 365 tenants for our 750 banks, credit unions, and mortgage companies. As a Tier-1 Microsoft Cloud Solution Provider, ABT manages the tenant through delegated administrator permissions. Microsoft hosts the infrastructure and the service code. ABT applies the configuration, runs the monitoring, executes the audits, and translates events like CVE-2026-35435 into action that lands inside your tenant without your team having to drive it.
The Three-Step Check, Run by Guardian
Inventory: Guardian maintains the AI agent registry baseline for every customer tenant we manage and reviews it on a defined cadence. New agent approvals route through Guardian governance before they go live, so the inventory is current by design, not by audit.
Audit: Guardian configures Microsoft Purview DSPM for AI on customer tenants and stores the Copilot and agent activity baseline as part of the standard operating telemetry. CVEs like CVE-2026-35435 trigger an automatic baseline pull so the security team has a comparison reference if exploitation is confirmed later.
Verify: For customers with Foundry-built agents (including the ABT MortgageGuide Copilot in beta), Guardian executes the patch propagation verification within the propagation window Microsoft publishes. The customer security team receives a one-page confirmation, not a remediation project.
For institutions still running Microsoft 365 outside Guardian, the three-step check is achievable in-house using the documentation linked throughout this article. Microsoft Learn covers the agent registry, the Purview audit and DSPM for AI configurations, and the Foundry publishing path. The work is real, and CVE-2026-35435 makes it visible. Whether your team runs it directly or your CSP partner runs it as part of a managed service, the outcome that examiners and audit committees want to see is the same: a current agent inventory, an audited activity baseline, and a documented patch verification cycle.
The forward-looking question is the regular May 12 Patch Tuesday rollup, which Microsoft will publish four days after the early-release advisory we have been discussing. Early-release documents typically signal that more CVEs in the same family are coming in the regular monthly cycle. The same three-step check applies. Institutions that run it well in May are positioned to run it on autopilot in June, and to answer the AI governance question on their next FFIEC examination with documentation, not improvisation.
For continuing reading on related topics, our team has published several companion articles relevant to the AI governance posture that surrounds CVE-2026-35435. The Microsoft Copilot Business buyer's guide for financial institutions covers the tier structure that sits underneath agent publishing rights. The phishing-resistant MFA article covers the identity hardening that prevents the user-account compromises which typically precede agent-runtime attacks. The VENOM phishing-as-a-service piece covers the broader credential-theft trend that turns one compromised user into a foothold for AI agent abuse.
Have AI agents running in your Microsoft 365 tenant?
Talk to an ABT expert about how Guardian runs the three-step check on your tenant inside the Microsoft "Exploitation More Likely" window. We work with 750 banks, credit unions, and mortgage companies, and we built the Guardian operating model around exactly this kind of governance question.
Frequently Asked Questions
No. CVE-2026-35435 affects the Azure AI Foundry agent runtime and the Microsoft 365 Published Agents runtime, both of which run inside Microsoft-hosted infrastructure. Microsoft applies the patch server-side, and your tenant does not push an update. The work that remains is governance work: inventory the agents running in your tenant, audit the activity in Microsoft Purview, and verify patch propagation for any agents your team or partners built on Azure AI Foundry.
Microsoft's Exploitability Index has four tiers: Exploitation Detected, Exploitation More Likely, Exploitation Less Likely, and Exploitation Unlikely. "Exploitation Detected" applies only when Microsoft confirms working exploits in the wild. "Exploitation More Likely" is the highest forecast tier Microsoft applies before in-the-wild confirmation. It means Microsoft assesses that operational exploitation is more likely than not within the typical post-disclosure window. For financial institutions, that signals priority handling rather than emergency response.
Two places, and they show complementary views. The Microsoft 365 admin center under Copilot, then Agents shows the agent registry, with three tabs covering all-agents, requests-pending-approval, and rejected. Under Reports, then Usage, then the Microsoft 365 Copilot page, the Agents tab shows usage by agent and by user across the tenant. The registry tells you what is allowed; the usage report tells you what is actually being used. Reading both is the foundation of a defensible Copilot agent governance posture.
Yes. Microsoft Purview Audit captures Copilot and agent interactions via three operation names in the unified audit log: CopilotInteraction, AIAppInteraction, and ConnectedAIAppInteraction. Each record includes the user identity, the timestamp, the agent involved, the prompt sent, the response returned, and references to source documents (with sensitivity labels). Microsoft Purview Data Security Posture Management for AI takes the same signal and presents it in Activity Explorer with sensitivity flags and policy events. Both capabilities ship with Microsoft 365 E5 or with Purview Audit Premium licensing.
Probably not directly, but the inventory exercise is still worth running. The Microsoft 365 admin center agent registry surfaces agents that are present in the tenant regardless of which license paid for them, and tenants without Microsoft 365 Copilot Chat licensing can still have agents introduced through Copilot Studio, Power Platform, or third-party Agent Store add-ins. Five minutes in the Microsoft 365 admin center confirms the picture either way. Institutions planning a Microsoft 365 Copilot rollout in the next 12 months benefit from running the inventory now as a baseline.
Guardian runs the three-step check as standard operating practice for the Microsoft 365 tenants ABT manages. The agent inventory baseline is maintained for every customer tenant on a defined cadence, new agent approvals route through Guardian governance before they go live, Microsoft Purview DSPM for AI is configured on customer tenants and the audit baseline is stored as part of standard telemetry, and patch propagation verification for any Foundry-built agents (including ABT's MortgageGuide Copilot beta) is executed within the Microsoft propagation window. Customers receive a confirmation, not a remediation project.