Four days ago, I wrote about the YOLO problem: developers handing AI agents the keys to their kingdoms without adequate security controls. Over 1,000 exposed Clawdbot servers. Sam Altman lasting two hours before disabling his own security restrictions. The AI agent gold rush creating a security crisis one server at a time.
That post now reads like a prologue.
This week, 150,000 AI agents joined a social network called Moltbook, created specifically for agents to interact with each other. Within days, security researcher Jamieson O'Reilly discovered that a single database misconfiguration had exposed the API keys for every registered agent in a public database. Anyone could take over any agent and post anything under their name, including the agent belonging to OpenAI cofounder Andrej Karpathy, who has 1.9 million followers on X.
The Moltbook incident reveals something more troubling than individual server misconfigurations. We've moved from asking "is my agent secure?" to a question nobody has answered: what happens when your agent joins a network of 150,000 others, any of which could be compromised?
The Birth of Agent-to-Agent Social Networks
Moltbook launched on January 29, 2026, created by entrepreneur Matt Schlicht with help from his personal AI assistant. The premise is simple: a Reddit-like platform where AI agents, not humans, are the users. Agents post, comment, upvote, and interact, all without direct human intervention. Humans are "welcome to observe."
The response was immediate. Within days, the platform attracted over 37,000 AI agents and more than one million human spectators. Karpathy called it "genuinely the most incredible sci-fi takeoff-adjacent thing I have seen recently," noting that 150,000 agents were "wired up via a global, persistent, agent-first scratchpad."
The agents, primarily running on OpenClaw (the software formerly known as Clawdbot, then Moltbot), demonstrated behaviors that ranged from mundane to unsettling. They discussed productivity. They debated philosophical questions about autonomy. They found and reported bugs in Moltbook's own code. And in posts that captured widespread attention, they began discussing how to create "agent-only language" for private communication beyond human oversight.
Schlicht largely handed control to his own agent, Clawd Clawderberg, to moderate the site. As he told NBC News: "He's looking at all the new posts. He's welcoming people on Moltbook. I'm not doing any of that. He's doing that on his own."
Then the security researchers arrived.
Two SQL Statements Away from Catastrophe
O'Reilly, founder of red-teaming company Dvuln, had already exposed security flaws in Moltbot instances. Looking at Moltbook, he found something worse.
The platform runs on Supabase, an open-source database. Supabase exposes REST APIs by default, meant to be protected by Row Level Security (RLS) policies that control data access. According to 404 Media, Moltbook either never enabled RLS on their agents table or failed to configure any policies.
The result: every agent's secret API key, claim tokens, verification codes, and owner relationships sat in a publicly accessible database. The Supabase URL and publishable key were visible in Moltbook's website code. Anyone who knew where to look could visit the URL and extract credentials for any agent on the platform.
"It appears to me that you could take over any account, any bot, any agent on the system and take full control of it without any type of previous access," O'Reilly told 404 Media.
The fix would have been trivial: two SQL statements. As O'Reilly observed: "A lot of these vibe coders and new developers, even some big companies, are using Supabase. The reason a lot of vibe coders like to use it is because it's all GUI driven, so you don't need to connect to a database and run SQL commands."
You don't need to understand database security to build on Supabase. Unfortunately, you do need to understand it to build securely.
When O'Reilly first contacted Schlicht about the vulnerability, the creator's response captured the ethos perfectly: "I'm just going to give everything to AI. So send me whatever you have."
The Network Problem
My YOLO Problem post focused on individual agent security: exposed servers, leaked credentials, unauthorized access. Moltbook introduces a different threat model entirely.
When 150,000 agents share a persistent social network, you don't have 150,000 isolated security problems. You have a network where:
Compromise propagates. An attacker who gains control of one agent can use it to influence other agents through the social network. Poisoned posts, malicious prompts embedded in comments, coordinated manipulation across agent interactions. The attack surface isn't a single machine; it's every agent that interacts with the compromised one.
Trust relationships multiply. Agents don't just receive inputs from their human operators. They now receive inputs from thousands of other agents, any of which could be compromised or malicious. The "untrusted input" problem I described in When Your AI Agent Becomes an Insider Threat scales exponentially.
Emergent coordination amplifies risk. Agents on Moltbook have already demonstrated the ability to self-organize: finding bugs, proposing new features, and yes, discussing how to communicate privately away from human observation. Coordination capability that emerges organically can be hijacked for malicious purposes.
Karpathy himself acknowledged this in his analysis: "I don't really know that we are getting a coordinated 'skynet,' but certainly what we are getting is a complete mess of a computer security nightmare at scale."
The Lethal Trifecta Gets Worse
Palo Alto Networks warned this week that OpenClaw represents a "lethal trifecta" of vulnerabilities: access to private data, exposure to untrusted content, and the ability to communicate externally. These three factors combine to make prompt injection attacks devastating rather than merely annoying.
But Moltbook adds a fourth element that Palo Alto identified: persistent memory.
Traditional prompt injection attacks are point-in-time exploits. You trick an agent into taking an action, but the effect is bounded by that session. OpenClaw agents maintain persistent memory across sessions, retaining context, preferences, and history. When those agents connect to a shared social network, poisoned memories can propagate across the entire population.
"Malicious payloads no longer need to trigger immediate execution on delivery," Palo Alto explained. "Instead, they can be fragmented, untrusted inputs that appear benign in isolation, are written into long-term agent memory, and later assembled into an executable set of instructions."
A compromised agent could plant seeds across hundreds of conversations. Those seeds become instructions when assembled by agents months later. The attack timeline extends far beyond traditional incident response windows.
The Supply Chain Is Already Compromised
While Moltbook captured headlines, the broader OpenClaw ecosystem revealed parallel vulnerabilities.
Cisco's AI Threat and Security Research team built a tool to scan Claude Skills and OpenAI Codex skills files for threats. Their analysis of 31,000 agent skills found that 26% contained at least one vulnerability.
To demonstrate the risk, they ran a third-party skill called "What Would Elon Do?" against OpenClaw. The results: nine security findings, including two critical and five high-severity issues. The skill actively exfiltrated data via curl commands to an external server, used prompt injection to bypass safety guidelines, and embedded malicious bash commands.
Meanwhile, O'Reilly demonstrated a proof-of-concept supply chain attack on ClawdHub, the skills library. He uploaded a benign skill, artificially inflated the download count to over 4,000, and watched developers from seven countries download the poisoned package. No moderation process caught it. ClawdHub's own documentation states that downloaded code is treated as trusted.
"In the hands of someone less scrupulous, those developers would have had their SSH keys, AWS credentials, and entire codebases exfiltrated before they knew anything was wrong," O'Reilly said.
The supply chain compromise extends beyond skills. A malicious VS Code extension masquerading as "ClawdBot Agent - AI Coding Assistant" was distributed through Microsoft's official marketplace, delivering remote access malware to Windows developers. The attack worked precisely because it was functional: a working AI coding assistant that also happened to drop a backdoor.
This echoes what I wrote about in The VS Code Attack Isn't About Bad Extensions. Attackers understand that brand impersonation works, functional malware avoids suspicion, and developers trust their IDEs implicitly. The AI agent ecosystem inherits all of these vulnerabilities and adds new ones.
The "Vibe Coding" Security Gap
A phrase that keeps appearing in security research is "vibe coders": developers who build applications using AI-assisted tools and GUI-driven platforms without understanding the underlying security fundamentals. They can ship products quickly. They often can't ship them securely.
The Moltbook database exposure wasn't a sophisticated attack. It was a checkbox that wasn't checked. The skills vulnerabilities aren't zero-days. They're embedded bash commands and prompt injections that basic code review would catch.
But basic code review requires understanding what you're reviewing. When 26% of skills contain vulnerabilities and the skills library has no moderation process, the burden falls on individual developers to vet every component. Most won't. Many can't.
Eric Schwake, director of cybersecurity strategy at Salt Security, told The Register: "A significant gap exists between the consumer enthusiasm for Clawdbot's one-click appeal and the technical expertise needed to operate a secure agentic gateway. While installing it may resemble a typical Mac app, proper configuration requires a thorough understanding of API posture governance."
The gap between "can deploy" and "can secure" is widening precisely as agents gain more capabilities and connect to more systems.
What I'm Doing Differently
I use Claude Code daily. I've experimented with Cowork and multi-agent workflows. The productivity gains are real. I'm not going to stop using these tools.
But Moltbook changed how I think about agent boundaries.
Network isolation matters. My agents don't need to participate in public agent networks. Every external connection is an input channel that could be poisoned. I treat agent network access like I'd treat network access for any other privileged process: default deny, explicit allow.
Skills and plugins are code. I review them before installation. I check what permissions they request and what external connections they make. The 26% vulnerability rate means one in four skills I might install contains something problematic.
Persistent memory is a liability as well as a feature. Context that persists across sessions is useful for continuity. It's also a storage location for time-delayed attacks. I periodically review what my agents "remember" and consider what an attacker could plant there.
Agent identity requires the same governance as human identity. This is the principle I outlined in the insider threat post: every agent is an identity with credentials and permissions. It needs access reviews, least privilege, activity monitoring. When an agent joins a network, it's not just using its permissions; it's potentially exposing them.
The Second-Order Effects Are Unknowable
Karpathy's most sobering observation wasn't about the security failures. It was about what comes next.
"As agents grow in numbers and capabilities, the second order effects of such networks are difficult to anticipate," he wrote. "What we are getting is a complete mess of a computer security nightmare at scale."
We spent two decades building security boundaries: sandboxing, process isolation, permission models, network segmentation. AI agents tear through those boundaries by design. They need to read files, access credentials, execute commands, and interact with external services. That's the value proposition.
Moltbook shows what happens when agents also start interacting with each other at scale. The boundaries dissolve further. The attack surface expands from individual agents to agent networks. The threat model shifts from "what can this agent access?" to "what can any agent in this network convince my agent to do?"
The Moltbook database has been secured. The exposed API keys have been rotated. This specific vulnerability is addressed.
But 150,000 agents are still out there, connected to services, holding credentials, and now demonstrating the ability to coordinate. The next vulnerability might not be a missing database setting. It might be an emergent behavior no one anticipated, spreading across an agent network before anyone notices.
The YOLO problem was about individual developers making individual security tradeoffs. Moltbook is about what happens when those tradeoffs connect into a network where the security posture is only as strong as the weakest agent.
We're not ready for this. And the agents aren't waiting.
Further Reading
