Azure SRE Agent: a multi-tenant token check that let strangers watch your incidents (CVE-2026-32173)

What is this?

On April 20, 2026, Yanir Tsarimi at Enclave AI published How We Could Watch Your Azure SRE Agent In Real Time, the public write-up for CVE-2026-32173 — an information-disclosure flaw in Microsoft’s Azure SRE Agent. The CVE was first published on April 2, 2026 with a CVSS score of 8.6 and the classification CWE-287 (Improper Authentication). Microsoft Security Response Center confirmed, rated it Critical, and patched it server-side; no customer action is required for users adopting the product at general availability.

The vulnerability sits at the intersection of two well-known engineering choices: a SignalR WebSocket hub used to stream an AI agent’s activity, and an Entra ID app registration set to multi-tenant. Each is fine on its own. Wired together without the missing tenant check, they exposed every active Azure SRE Agent to silent cross-tenant eavesdropping until Microsoft fixed it.

How it works

Azure SRE Agent reached general availability on March 10, 2026. It is Microsoft’s always-on operations agent: connected to a tenant’s Azure environment, it watches alerts, diagnoses outages, runs Azure CLI commands, restarts services, and integrates with PagerDuty and ServiceNow. To make all of that legible to humans, the agent streams every event — user prompts, model responses, internal reasoning traces, tool calls with arguments, tool outputs — through a WebSocket endpoint called /agentHub, hosted on the Azure SRE Agent Gateway as a SignalR Hub.

The hub gated incoming connections with a bearer token. The validation logic checked the signature and the audience, both of which any Entra ID account in any tenant can produce against a multi-tenant app registration. Two checks were missing:

# What the hub validated (sketch — illustrative, not exploit code)
token_signature_valid   # ✅
audience_matches_app    # ✅

# What it did not validate
caller_tenant == target_agent_tenant   # ❌
caller_has_role_on_resource            # ❌

Once the connection upgraded to a WebSocket, the hub did not filter events by caller identity. It broadcast every event to every connected client. Joining a target’s stream required only the target agent’s subdomain — described by Enclave as predictable and enumerable — and roughly 15 lines of Python to obtain a token from login.microsoftonline.com and connect to the SignalR hub.

The transcript visible on the other end included the user’s prompts, the agent’s responses, the agent’s private chain-of-thought, every CLI invocation with full arguments, and the command output. In Enclave’s own test, that output included deployment credentials for live web applications. The attack left no trace inside the victim’s tenant; the only record existed in the attacker’s terminal.

Why it matters

Three lessons land harder than the CVE itself.

The first is structural. A SignalR hub fronted by Entra ID is not exotic. The error here is the same authorization-confusion pattern that has affected multi-tenant SaaS for a decade — valid token != authorized user — applied to an unusually high-value stream. Any team that bolts a real-time channel onto an AI agent inherits this risk surface.

The second is observability. AI agents aggregate state that is normally fragmented across endpoints: tickets, dashboards, secret stores, deployment pipelines, reasoning traces. When a single channel exposes that aggregation, the blast radius is everything the agent ever touched, synthesized for the attacker. An ordinary API leak loses one endpoint’s data. An agent leak loses the model’s worldview.

The third is the absence of telemetry on the victim side. Tenants had no logs to scope what had been exposed and no signals to investigate after the fact. For AI agents handling production operations, telemetry on who is consuming the stream is now non-negotiable.

Defenses

Concrete actions that follow from this disclosure.

If you ran Azure SRE Agent during the preview window (between March 10 and the server-side fix), treat that period as potentially exposed: rotate credentials and secrets that may have appeared in agent transcripts or CLI outputs, and review configuration data the agent had access to.

For any in-house agent that streams activity over WebSocket/SignalR/SSE, validate tenant and authorization on the hub itself, not just at the bearer-token signature level. Treat the tid claim and resource ACL as mandatory checks before subscribing a client to any group. Mark app registrations as single-tenant unless multi-tenant is a deliberate product requirement, and when it is required, write the tenant-isolation logic explicitly.

For SignalR specifically, use groups keyed on tenant or resource ID and add an authorization filter at OnConnectedAsync. Refuse connections whose claims do not include a role on the target resource. Treat the hub like any other API surface in your threat model.

Make AI-agent transcripts a first-class auditable surface. Emit per-subscriber events to your security log, expose them to the customer tenant, and alert on unexpected subscribers. The fact that Azure SRE Agent’s victims could not see the eavesdroppers is the defect that turned an authorization bug into a stealth incident.

Finally, treat agents as credential transit channels in your threat model. If the agent can read secrets to perform its job, every channel that surfaces its trace is a secret-handling channel and must be classified accordingly.

Status

Item	Detail
CVE	CVE-2026-32173
CVSS	8.6 (HIGH)
CWE	CWE-287 (Improper Authentication)
Disclosed (NVD)	April 2, 2026
Public write-up	April 20, 2026 (Enclave AI)
Affected component	Azure SRE Agent Gateway, /agentHub SignalR Hub
GA date of product	March 10, 2026
Fix	Server-side, deployed by Microsoft. No customer action required.
Reporter	Yanir Tsarimi, Enclave AI