A high-severity authentication flaw in Microsoft’s Azure SRE Agent exposed sensitive agent data to unauthorized network access, according to a confirmed vulnerability disclosure.
The issue was identified by Enclave AI researcher Yanir Tsarimi, who detailed the findings in a blog post describing how agent interactions could be accessed without proper authentication controls. The vulnerability has been tracked as CVE-2026-32173 and rated critical with a CVSS score of 8.6.
In the blog, Tsarimi described scenarios where agent activity could be observed during execution, including interactions between users and the system. The exposure stemmed from an authentication gap in the service, allowing access to data streams without valid credentials.
Microsoft classified it as an improper authentication issue that allows an unauthorized attacker to disclose information over a network, the NVD entry said.
“Imagine you hired an assistant who has access to everything: your servers, your logs, your passwords, your source code. Now imagine a total stranger, from a completely unrelated company, could silently listen to every conversation that assistant has,” Enclave researcher Yanir Tsarimi wrote. “That’s what we found in Azure SRE Agent.”
Microsoft has since fixed the issue, the blog added. The fix was applied server-side, and Microsoft’s advisory states that no customer action is required. Azure SRE Agent reached general availability on March 10.
Multi-tenant by default
The agent streams all activity through a WebSocket endpoint called /agentHub, the blog said.
The endpoint required a token to connect, but the underlying Entra ID app registration was configured as multi-tenant, meaning any account from any Entra ID tenant could obtain a valid token that the hub would accept.
“The hub then checked: Is the token valid? Yes. Is the audience correct? Yes. It never asked: Does this caller belong to the target’s tenant? Are they authorized to use this agent? Do they have any role on this resource?” Tsarimi wrote.
Once connected, the hub broadcasts all events to all clients with no identity filtering, the blog said.
The exposed channel included user prompts, agent responses, internal reasoning traces, every command executed with full arguments, and the command output.
“In our own test environment, we watched the agent run a routine task and return deployment credentials for live web applications,” Tsarimi wrote. “An eavesdropper on a real target would have received the same. Silently. With nothing to indicate anyone else was on the line.”
Exploitation required only the target agent’s subdomain, which Enclave described as predictable and enumerable, and roughly 15 lines of Python. Third-party trackers identified the affected component as the Azure SRE Agent Gateway SignalR Hub.
Watching a privileged operator think out loud
The category of flaw should not be compared too closely to a conventional API bug, said Alexander Hagenah, cybersecurity researcher and executive director at Zurich-based financial infrastructure operator SIX Group.
“A normal API issue is usually bound by a specific endpoint, dataset, or permission check. With an AI operations agent, the agent itself becomes the aggregation point for infrastructure state, logs, source code, incident context, commands, outputs, and sometimes credentials that appear during troubleshooting,” Hagenah said.
“In practical terms, it can look like watching a privileged operator think out loud,” he added.
The exposure does not amount to automatic infrastructure compromise, Hagenah said, but it can be more valuable than many read-only bugs. Attackers typically have to work hard after initial access to understand an environment. An SRE agent may already have that context assembled for them.
The connection also left no trace on the victim’s side, the researcher wrote. “Victim organizations had no way to detect it, no way to investigate after the fact, and no way to scope what had been exposed.”
Considerations for enterprises
Enclave, as per the blog post, noted that organizations that ran Azure SRE Agent during the preview window must treat the period as potentially exposed and review any credentials, configuration data, or sensitive information that may have passed through agent conversations or CLI outputs.
Hagenah said agentic operations services need to be governed more like privileged automation platforms than ordinary SaaS tools.
“Before granting that level of access, I would want very clear answers on tenant isolation and resource-level authorization. It should not be enough that a token is valid. The service has to verify that the caller belongs to the right tenant, is authorized for that specific agent, and is allowed to access that specific stream, thread, tool output, or action,” he said.
The agent should run under a dedicated managed identity with minimal permissions, and integrations with command execution, log query, source repositories, and incident platforms should be reviewed like any other privileged system, Hagenah said. Enterprises also need to know who connected, what threads they accessed, what commands ran, and what output was returned, with logs exportable to the SIEM. Microsoft did not immediately respond to a request for comment.
No Responses