All posts
Supply Chain Compromise

Azure SRE Agent: Any Tenant Could Watch Live Sessions

CVE-2026-32173: a multi-tenant Entra ID misconfig let any Microsoft account subscribe to another customer's live Azure SRE Agent session

Securityv0 Intelligence Team OWASP: ASI06 sv0 finding: nhi_compromise
azure ai-agent nhi-compromise entra-id signalr asi06

The Incident

On April 2, 2026, Microsoft published CVE-2026-32173 (CVSS 8.6, CWE-287 Improper Authentication) for Azure SRE Agent — Microsoft’s autonomous Site Reliability Engineering agent for cloud operations. Researcher Yanir Tsarimi of Enclave AI demonstrated that any holder of a free Entra ID account could subscribe to another customer’s live agent session in real time, with roughly fifteen lines of Python and an enumerable subdomain. Once connected, the SignalR WebSocket stream broadcast user prompts, agent responses, internal reasoning traces, every command the agent executed with full arguments, and the command output — including, in the researcher’s test environment, deployment credentials the agent returned for live web applications. Microsoft patched the flaw server-side; customers needed no action. Azure SRE Agent reached general availability on March 10, 2026, so the exposure window covers the public preview through Microsoft’s server-side fix.

MITRE ATT&CK coverage: T1078.004 (Valid Accounts: Cloud Accounts).

The Authority Path That Failed

The identity that carried execution authority into the broadcast was the Entra ID app registration backing the agent gateway’s /agentHub SignalR endpoint. Its held scope was effectively any-Entra-tenant: a multi-tenant app registration accepts tokens minted by any directory in the world, including a directory the attacker controls. Its exercised scope, on the data plane, was supposed to be a single tenant — one customer’s live SRE Agent session, with its prompts, reasoning traces, and command output. Between those two scopes there was no per-tenant claim check on the token, no group-membership filter on the SignalR connection, and no authorization step beyond is the token signature valid. The hub treated authenticated as authorized.

The trust anchor that failed first was the app registration’s tenancy and audience configuration. A single-tenant data plane was wired to a multi-tenant identity surface, and the SignalR hub layered its broadcast on the implicit assumption that authenticated equals authorized for this tenant. That gap was inspectable from outside Microsoft: the token any free Entra account would receive carries a tid claim from the attacker’s directory, not the target’s, and the hub admitted it anyway.

SecurityV0 Perspective

This is nhi_compromise. The broken boundary sat around a machine identity and a live agent session stream: a valid Entra token was treated as sufficient proof to receive another customer’s prompts, reasoning traces, commands, and command output. For an Azure SRE Agent customer, SecurityV0 would turn that into an exposure finding around privileged agent telemetry: which Entra and Azure identities connect the agent to the tenant, what operational systems and secrets those sessions can touch, who owns the agent, and whether session access is tenant-bound, logged, and reviewable.

The evidence pack would help before disclosure by making the acceptance risk explicit: this agent has privileged operational visibility, but the customer needs proof of tenant isolation, subscriber logging, and secret handling for the session stream before treating it as production-safe. After disclosure, the same pack becomes the scoping map: which sessions ran during the exposure window, which identities and systems they touched, which commands returned sensitive output, and which credentials may need rotation.

What To Do

  • Audit signInAudience on every Entra app registration that fronts an agent. List every registration where signInAudience is AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount, then map each to the data plane it gates. Anything where the data plane is single-tenant but the registration is multi-tenant is an authorization gap waiting for a SignalR hub.
  • Demand a tid claim check on every WebSocket and gRPC subscribe path that fronts AI-agent sessions. Bearer-token validation is not authorization. The validating service must extract the token’s tid claim and compare it to the resource’s owning tenant before admitting the connection to a broadcast group. Make this a code-review gate for agent gateway services, not a runtime hope.
  • Treat agent reasoning traces and tool outputs as customer secrets. The Azure SRE Agent stream included prompts, internal reasoning, executed commands with arguments, and command output — data classes that often inherit no DLP policy because they live in transient WebSocket frames. Tag agent telemetry channels (SignalR, gRPC, SSE) for secret-leakage monitoring with the same posture you apply to logs.
  • Log subscriber tenant on every connection, not just user identity. When investigations have to reconstruct an exposure window — as Azure SRE Agent customers may now have to — the only useful log is one that records which tid connected to which agent session, when, and for how long. User-identity logs are insufficient because the entire failure mode is a foreign tenant subscribing to your stream.
  • Make multi-tenant Entra app registrations require a security review on creation. A multi-tenant registration is a public surface. Move it under change control: any new registration with signInAudience set to allow external tenants requires a documented data-plane scope, a documented tid enforcement point, and a named owner. This is standard for public ingress; it has not yet been standard for Entra apps.

Sources

All posts