Clawdbot gateway attacks expose weak assumptions in agent access

At a glance

What this is: This is a Clawdbot gateway attack analysis showing that exposed AI agent control planes are being probed with source-aware exploits, protocol downgrades, and credential-harvesting traffic.

Why it matters: It matters because AI agent gateways can expose secrets, chat history, and connected infrastructure, which forces IAM teams to treat agent control planes as high-value identity surfaces, not ordinary app endpoints.

👉 Read Pillar Security's analysis of real attack traffic targeting exposed Clawdbot gateways

Context

An exposed AI agent gateway is an identity and access problem, not just an application hardening problem. In this case, the control plane sat behind a WebSocket API that attackers could reach directly, then used authentication bypass attempts, proxy trust assumptions, and protocol downgrades to move toward credentials and data access. For teams governing AI agents, the primary issue is whether the gateway actually enforces identity before any tool, config, or session data can be reached.

The article is also a reminder that AI agent security starts with the control plane, not the prompt layer. The attackers targeted the gateway protocol itself, which means conventional application firewalls and LLM-focused defenses do not cover the whole exposure. For practitioners building NHI governance around agentic systems, the same pattern appears in the OWASP NHI Top 10 and related guidance on exposed interfaces, weak auth defaults, and overbroad trust in runtime connections.

Key questions

Q: What breaks when an AI agent gateway trusts reverse-proxy traffic as local?

A: The boundary between internal and external access collapses. Requests can inherit localhost trust even when they originated outside the environment, which lets attackers bypass authentication and reach privileged RPC methods. The practical failure is not the proxy itself, but the assumption that network path equals identity assurance. When that assumption breaks, the gateway becomes an exposed control plane rather than a protected one.

Q: Why do exposed agent gateways increase NHI risk across connected services?

A: Because the gateway often stores or brokers the credentials needed to reach those services. If an attacker reaches config data, session history, or channel tokens, they can pivot from the gateway into downstream systems without needing to defeat each service separately. That makes the gateway a high-value non-human identity surface, especially when integrations are numerous and secrets are returned in plaintext.

Q: How do security teams know whether an agent gateway is overexposed?

A: Look for methods that reveal configuration, session content, or connected infrastructure from the same control plane that processes user commands. If a single unauthenticated or weakly authenticated route can expose keys, history, or node maps, the gateway is overexposed. Logging should also show whether clients can probe version boundaries, impersonate roles, or enumerate methods without being blocked.

Q: Who is accountable when an exposed AI agent gateway leaks secrets and chat history?

A: Accountability sits with the team that owns the gateway, the proxy configuration, and the secret handling model together. The control plane is part of identity governance, so ownership cannot stop at application operations. If the same component stores credentials, returns session state, and brokers tool access, it needs clear control owners, reviewable access policy, and explicit incident escalation paths.

Technical breakdown

WebSocket gateway exposure and unauthenticated control paths

Clawdbot’s gateway exposes a WebSocket API that acts as the entry point for agent control, session access, and downstream tool execution. If authentication is disabled by default or bypassed through proxy handling, the gateway becomes a high-trust identity surface with no meaningful gate at the edge. The attack traffic in the article shows that adversaries do not need to coerce the model when the control plane itself accepts RPC-style commands. That is a protocol problem, not a prompt problem.

Practical implication: validate that the gateway enforces authentication before any RPC method is reachable.

Protocol downgrades and reverse proxy trust collapse

Attackers tested minProtocol and other version boundaries to find instances still running older, weaker releases. They also exploited reverse proxy logic that treated proxied traffic as localhost, which erased the difference between external and internal requests. In identity terms, the system trusted network placement instead of authenticated identity. That is a classic boundary failure: the proxy became an implicit trust amplifier instead of a control point.

Practical implication: explicitly configure trusted proxies and reject any design that infers trust from localhost routing alone.

Credential and session extraction from the agent control plane

The most damaging RPC paths in the article were config.get and chat.history. One exposes API keys, bot tokens, and gateway credentials stored in plaintext; the other exposes everything users have discussed with the AI assistant. For an attacker, that combination converts a gateway foothold into credential reuse, conversation theft, and infrastructure mapping across connected nodes. In NHI governance terms, the control plane is not just managing access. It is storing the assets that access protects.

Practical implication: separate secret retrieval, session storage, and runtime control paths so a single gateway breach cannot disclose all three.

Threat narrative

Attacker objective: The attacker aims to turn a reachable agent gateway into a source of secrets, session content, and mapped infrastructure for further compromise.

1. Entry occurred through exposed Clawdbot gateway endpoints that accepted direct WebSocket probing, protocol fingerprinting, and version-downgrade attempts.
2. Credential access followed when attackers targeted unauthenticated or weakly trusted control paths such as config.get, chat.history, and impersonated client sessions to harvest tokens and session data.
3. Impact came from gaining plaintext credentials, conversation history, and multi-node topology details that could support lateral movement and broader environment compromise.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Clawdbot gateway exposure is really an identity boundary failure, not an AI problem. The article shows attackers skipping prompt injection and going straight for the WebSocket control plane, which means the first control that failed was authentication at the protocol edge. That matters because AI agent gateways concentrate access to tools, sessions, and secrets in one place, so the gateway becomes the NHI choke point. Practitioners should treat the control plane as a privileged identity surface, not an app convenience layer.

Proxy trust is a governance assumption, not a harmless deployment detail. The reverse-proxy bypass worked because the system treated proxied requests as if they were local traffic. That assumption was designed for direct, trusted runtime paths. It fails when external traffic can be relayed through nginx, Caddy, or Traefik and still inherit localhost trust, which means the real failure is identity provenance, not transport. The implication is that trust must be asserted by authenticated context, not network adjacency.

Plaintext secrets inside an agent gateway create an identity blast radius that grows with every integration. The article’s config.get path exposed API keys, channel tokens, and gateway credentials in one response, while chat.history exposed user conversations. That is not just secret sprawl. It is a collapsed trust domain where one compromised gateway can reveal everything it is authorized to touch. The implication is that agent gateways must be designed as high-consequence identity brokers, because their exposure scope is already wider than most teams assume.

Source-aware attacker traffic is now targeting agent control protocols, not just LLM prompts. The probes used method names that mapped to real handlers and included client impersonation, version targeting, and role-scope testing. That is a specific NHI threat pattern for autonomous and semi-autonomous systems: attackers study the control protocol first, then use the model only if the protocol resists. Practitioners should assume the adversary will read the source code before attempting exploitation.

Identity governance for agentic systems must start with where the gateway stores and returns state. The article’s attack sequence moved from reconnaissance to enumeration to extraction in a single session, which is exactly what happens when runtime state, configuration state, and access state live together. OWASP NHI controls around exposed interfaces, secret handling, and privilege boundaries are directly relevant here. Teams should re-evaluate whether their agent platform can fail safely when the control plane is fully visible to an attacker.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a deeper governance lens, review OWASP NHI Top 10 and map agent gateway exposure to control gaps before deployment expands further.

What this signals

Identity blast radius: When an agent gateway can return secrets, sessions, and infrastructure topology from the same control plane, the blast radius is determined by what the gateway is allowed to disclose, not by where the gateway is hosted. Teams should watch for any design that merges administration, telemetry, and credential retrieval into one runtime boundary.

With 92% of organisations agreeing that governing AI agents is critical to enterprise security, but only 44% having implemented any policies, the gap is no longer awareness. Practitioners should expect more attacker traffic aimed at control protocols, especially where proxy trust and method discovery remain soft spots.

The next governance step is to align agent platforms with explicit identity controls rather than implicit network trust. For practitioners mapping this to standards, the control conversation belongs alongside OWASP Agentic AI Top 10 and zero trust thinking, not just LLM safety review.

For practitioners

• Enforce authentication on every gateway entry point Require explicit auth before any WebSocket method, session lookup, or config retrieval can execute. Do not rely on localhost defaults, proxy placement, or inherited network trust to protect the control plane.
• Harden reverse proxy handling for agent gateways Define trusted proxy boundaries, validate forwarded headers, and fail closed when proxy metadata is missing or inconsistent. The gateway should never interpret a relayed connection as local without authenticated proof.
• Redact secrets from any config-returning method Treat config endpoints as disclosure risks and return only the minimum metadata needed for administration. Store API keys, bot tokens, and channel credentials outside responses that can be reached from the same control surface.
• Separate session history from operational control Isolate chat logs, agent sessions, and command methods so compromise of one function does not expose the others. The same identity that can query operational state should not automatically be able to read prior user conversations.

Key takeaways

• The article shows that exposed AI agent gateways can be compromised at the protocol layer long before the model itself is involved.
• The evidence points to a high-impact control plane risk, with attackers targeting credentials, conversation history, and connected infrastructure in one path.
• Teams should treat agent gateways as privileged identity surfaces and verify that authentication, proxy trust, and secret handling all fail closed.

Key terms

• Agent Gateway: An agent gateway is the control-plane interface that brokers commands, sessions, and tool access for an AI agent. It is not the model itself. In practice, it becomes a privileged identity boundary because it often carries authentication, configuration, and runtime state in one place.
• Proxy Trust: Proxy trust is the assumption that traffic forwarded by a reverse proxy can be treated as internal or local. That assumption can fail when forwarded headers, client identity, and source address are not verified. In agent systems, bad proxy trust can turn external requests into privileged ones.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems that become exposed when one identity boundary fails. For non-human identities and agent gateways, it often includes secrets, sessions, and connected services. The larger the blast radius, the more one control-plane mistake can reveal.
• Session History Exposure: Session history exposure occurs when prior conversations, commands, or agent activity logs can be read by a party that should not see them. In agent environments, this is more than privacy leakage. It can reveal secrets, operating context, and pathways for follow-on access.

Deepen your knowledge

AI agent gateway security and identity boundary design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with exposed agent control planes or secret-bearing gateways, it is worth exploring.

This post draws on content published by Pillar Security: Caught in the Wild: Real Attack Traffic Targeting Exposed Clawdbot Gateways. Read the original.