A widely shared warning on X is drawing attention to a growing risk in the fast-moving world of AI “agents”: powerful automation bots being deployed on the public internet with little or no protection.
In the post, tech writer and builder Shiven Ramji (posting as @thinkshiv) wrote, “Disaster is coming,” claiming “thousands of ClawdBots are live right now on VPSs… with open ports to the internet… and zero authentication.”
Ramji’s message argues that if an agent can browse the web, call tools, access files and secrets, or reach internal endpoints, then leaving its control interface exposed without authentication is effectively an invitation for takeover. He urged developers to “fix it today” by closing public access, adding authentication and encryption, rotating keys, and enabling rate limits and logging.
What is “Clawdbot,” and why does exposure matter?
Clawdbot is described in its documentation as an AI agent “gateway” — software that can connect a model to tools (such as browsers, files, and integrations) so the agent can perform tasks rather than just chat. Its own security documentation warns that public network exposure and missing authentication should be treated urgently, comparing remote browser/tool control to exposing a remote admin interface.
That distinction is central to the warning: an unprotected agent interface is not just a “website bug.” It can be a control panel for automation with access to credentials and actions.
Is Ramji’s claim true?
The exact number of exposed instances is difficult to independently verify from a single social media post, but the underlying risk is well-understood in security circles: internet-connected services with open ports and no authentication are routinely discovered by automated scanners and abused.
In Clawdbot’s case, at least one security vendor analysis said internet scanning can identify Clawdbot deployments and reported that over 1,000 gateways were visible on the public internet via Shodan searches at the time of their write-up — with some deployments lacking effective access controls.
Separately, Clawdbot’s own published guidance emphasizes that “public network exposure… [and] missing auth” should be fixed immediately and that browser control should be treated like a privileged remote admin API.
In other words: even if the “thousands” figure varies by day and measurement method, security specialists say the scenario described — exposed agent endpoints — is plausible and high-risk, especially during waves of rapid adoption and copy-paste deployments.
Plain-English definitions of the scary terms
VPS (Virtual Private Server): A rented internet server (like a small cloud computer). If you run your agent there, it can be reachable from anywhere unless you restrict it.
Open port: A network “door” your server listens on (example: :8080). Open ports can be found by scanners.
Authentication: A required login/token proving the caller is allowed. “Zero authentication” means anyone can connect.
Internal endpoints: Private URLs/services meant to be accessible only from your internal network (databases, admin panels, dashboards, internal APIs).
Rotate keys: Replace API keys/passwords after potential exposure, because you must assume they could have been copied.
TLS/HTTPS: Encryption so traffic isn’t readable in transit. It doesn’t replace authentication, but it prevents easy interception.
The “Top 10” hardening points circulating with the warning
Ramji also shared a “Clawdbot Security Hardening” checklist image describing common pitfalls and mitigation steps. The items include issues like:
- Exposing the gateway to the public internet (binding to 0.0.0.0 on a port)
- Direct messages or control policies that allow all users by default
- Running without sandboxing
- Storing credentials in readable plaintext files
- Prompt injection risks from untrusted web content
- Allowing dangerous system commands
- Lack of network isolation
- Overly broad tool permissions
- Missing audit logs
- Weak/default pairing codes
The paired “fixes” emphasize restricting exposure, tightening policies, enabling sandboxing and container isolation, storing secrets in environment variables with strict file permissions, blocking dangerous commands, limiting tool access, and enabling comprehensive logging and rate limits.
Some of those themes closely match Clawdbot’s own published security notes — including warnings about public exposure and advice to treat remote agent control like remote administration.
What Clawdbot’s project documentation recommends
Clawdbot’s GitHub security guidance includes container hardening suggestions such as running as a non-root user and dropping container capabilities where possible.
Its documentation similarly stresses avoiding unsafe exposure and limiting what the agent can access.
Why agents change the stakes
Security practitioners often note that a typical exposed web app might leak a page or a database table — serious, but bounded.
An agent can have a much larger “blast radius” because it may be able to:
- Read local files (including config files).
- Access environment variables (often where API keys live).
- Call external services on your behalf.
- Automate a browser session.
- Chain actions automatically.
That makes “unauthenticated public endpoint” more than a bug — it can become a remote control for whatever the agent can reach.
A practical checklist for intermediate builders
Ramji’s steps map to a set of standard, widely accepted defenses:
- Restrict network access.
- Firewall the port.
- Prefer VPN/Tailscale/WireGuard.
- Use IP allowlists whenever possible.
- Require authentication.
- At minimum: a strong secret token.
- Better: JWT or OAuth.
- Ensure it’s enforced even behind proxies.
- Use encryption (TLS/HTTPS).
- Still requires auth (TLS alone is not access control).
- Assume compromise; rotate secrets.
- Replace API keys/tokens if exposure is possible.
- Rate limit + log + alert.
- Rate limiting slows brute force and abuse.
- Logs help you detect and investigate incidents.
- Reduce permissions.
- Allowlist tools.
- Limit filesystem and command access.
- Use sandboxing/container network isolation where available.
Ramji’s warning post is resonating because it describes a familiar pattern: powerful new software spreads quickly, and “demo-grade” deployments end up exposed on the open internet.
Even as the exact number of exposed instances remains difficult to confirm precisely from social media alone, Clawdbot’s own documentation and third-party analyses support the underlying concern: publicly exposed agent control surfaces without strong security controls can be high-risk, and developers should lock them down promptly.
