The Live Stream Leak: When Your SRE Agent Broadcasts Secrets in Real Time
We spend a lot of time threat-modeling what an AI agent might do. CVE-2026-32173 was about something simpler and more operationally brutal: what an attacker can watch. When an operations agent streams prompts, tool calls, arguments, and outputs over WebSockets, that stream becomes a privileged data plane.
The story (in one sentence)
A cloud operations agent that can run commands and read logs accidentally exposed a live, real-time feed of agent activity to any authenticated identity from any tenant.
That is not “prompt injection”. It is an identity boundary failure that turned observability into an exfiltration channel.
If you can watch an agent operate, you inherit the agent’s context. If the agent is privileged, the context is privileged.
Why this is worse than a normal read-only bug
Operations agents are aggregators. They pull together the exact things attackers want after first access:
- log lines that mention secrets
- command history
- arguments and flags
- error messages
- internal endpoints
- “quick fixes” pasted by humans under pressure
A classic API bug might leak one dataset. A live agent stream leaks the operator’s workflow.
The root cause pattern: “token valid” is not “caller authorized”
The public reporting describes a familiar failure mode:
- the WebSocket endpoint required a token
- the service verified the token was valid and had the right audience
- it did not verify the caller belonged to the target tenant
- events were broadcast without per-identity filtering
This is the difference between authentication and authorization. It is also the exact difference between “secure SaaS” and “cross-tenant incident”.
For agentic systems, treat every live stream like a production database. A valid token is necessary - and almost never sufficient.
The deeper lesson: observability is now part of the attack surface
Security teams often model agent risk as:
- untrusted input
- model reasoning
- tool execution
But the operational reality is broader. Modern agents emit a constant exhaust of “helpful” signals:
- traces
- step-by-step plans
- execution logs
- tool call transcripts
Those signals are invaluable for debugging. They are also an attacker gift.
| What you thought it was | What it actually is | Failure mode |
|---|---|---|
| Agent telemetry | Privileged transcript | Watch the agent “think out loud” while it runs commands and reads internal state |
| ”Just logs” | Secret discovery surface | Secrets show up in stdout, stderr, debug flags, and error messages |
| WebSocket connection | Cross-tenant data plane | Multi-tenant identity accepted without tenant membership checks |
| Streaming UX feature | Access-controlled resource | Must enforce tenant, resource, and role checks on every event, not only on connect |
Mapping to OWASP Agentic Top 10 (2026)
This incident chain is a clean example of why agentic security is not a model-only discipline:
- ASI03 - Identity and Privilege Abuse: a valid identity was enough to see privileged operations
- ASI07 - Insecure Inter-Agent Communication: live event streams behaved like a message bus without proper authorization
- ASI05 - Insufficient Monitoring: if there is no audit trail of who connected, there is no way to scope exposure
What to do this week (not someday)
If you deploy operations agents, treat the agent stream as a first-class asset.
-
Tenant isolation checks for every event - not only at handshake time
-
Per-resource authorization - “can this identity access this exact agent instance”
-
Auditable connections - log connects, disconnects, and which threads were subscribed to
-
Redact secrets at the source - do not rely on downstream log redaction
-
Assume transcripts leak - design agents so that routine troubleshooting does not print credentials
If your team cannot answer “who watched our agent runs” after an incident, you cannot scope impact. Observability without access control is an attacker feature.