Notifications
Clear all
Topic starter
23/06/2026 9:20 pm
TL;DR: Exposed Clawdbot gateway instances were probed by protocol-aware attackers within minutes, using direct WebSocket exploitation, protocol downgrades, and client impersonation to reach credentials, conversation history, and multi-node infrastructure maps, according to Pillar Security research.
NHIMG editorial — based on content published by Pillar Security: Caught in the Wild: Real Attack Traffic Targeting Exposed Clawdbot Gateways
Questions worth separating out
Q: What breaks when an AI agent gateway trusts reverse-proxy traffic as local?
A: The boundary between internal and external access collapses.
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.
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.
Practitioner guidance
- Enforce authentication on every gateway entry point Require explicit auth before any WebSocket method, session lookup, or config retrieval can execute.
- Harden reverse proxy handling for agent gateways Define trusted proxy boundaries, validate forwarded headers, and fail closed when proxy metadata is missing or inconsistent.
- Redact secrets from any config-returning method Treat config endpoints as disclosure risks and return only the minimum metadata needed for administration.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- Raw honeypot payloads and the exact WebSocket methods attackers tried against exposed gateways
- Commit-level analysis showing which code changes closed the auth bypasses and proxy trust failures
- Per-probe traffic breakdown that helps teams prioritise which gateway methods are being targeted most often
- A practical patch and isolation checklist for teams running Clawdbot in production or exposed test environments
👉 Read Pillar Security's analysis of real attack traffic targeting exposed Clawdbot gateways →
Clawdbot gateway probing shows where AI agent controls break down?
Explore further
25/06/2026 2:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Clawdbot gateway attacks expose weak assumptions in agent access
