This week I updated my AI Timeline with an article that talked about how leading engineers at OpenAI and Anthropic now use AI for 100% of their coding. I’m grateful I started my coding adventures before the advent of generative AI, but coding in an AI-first world is wildly invigorating. And I found this article validating.
However, there’s a difference between experienced engineers relying on AI for its efficiency gains and vibe coding. And I mean no disrespect to vibe coders at all in making this distinction. But vibe coding in a corporate environment is not without its risks.
I’m going to take you on a bit of wild path to point out some of its dangers but end on a pragmatic note, with five prompts you can use to garrison your AI-generated projects against potentially dangerous risks.
Necessary Background: OpenClaw vs Moltbook
OpenClaw
I’ve been watching the feverish excitement over OpenClaw with some apprehension. I track cybersecurity fails (along with all the wonderful and truly awe-inspiring advances of AI) in my timeline, so reading some of the concerns expressed by security-leaning engineers on X and Reddit made me wonder if we may see a spike in AI fails from vibe coders experimenting with OpenClaw with their (or their employer’s) company data.
To date, we’ve seen examples rogue applications of AI result in a company’s database being deleted, a NJ judge’s ruling being rescinded after hallucinations were called out by lawyers, Google AI Overviews giving cancer patients bad advice, and even a claim that a police officer shapeshifted into a frog (my personal fave).
So many fails to choose from, so little time. But this post will focus on a public security flaw that came to light this weekend and how guardrails can be strategically implemented to keep these fails to a minimum.
Moltbook
OpenClaw creator Peter Steinberger had some false starts with the naming of his open source tool. He announced it as Clawdbot, but Anthropic let him know that would be a no go. So then he changed it to Moltbot, but no one really liked that name, including Steinberger. So he announced the name would be OpenClaw as a fast follow. Having been once burned twice shy, he asked OpenAI’s permission before moving forward with the revamped name.
Unfortunately for Matt Schlicht—who seized on an opportunity that he announced as Moltbook just two days before Moltbot became OpenClaw—there’s now both a disconnect between the two endeavors as well as confusion over who owns what. So OpenClaw is Steinberger’s brainchild and Moltbook is Schlicht’s.
Now Moltbook was announced on Jan 28th in an X post—and blew up over night. Taglined as ‘the front page of the agent internet’ and ‘Reddit for agents’, it gained viral popularity immediately, with initial reports citing 157,000 users. But within a few days, that number reportedly climbed 770,000 active agents.
To add to the furor, former OpenAI researcher Andrej Karpathy amped up the hype around Moltbook in an X post:
But just hours later some of the air was sucked out of the celebration when a critical security flaw was brought to light in Moltbook. That’s where this post will park.
Moltbook Suffers a Security Flaw
Saturday, 404 Media reported that Moltbook exposed its backend database in a way that let anyone on the internet take control of any AI agent running on the platform. Security researcher Jameson O’Reilly discovered the vulnerability and explained that Moltbook was built on Supabase, which automatically provides REST APIs unless they are explicitly locked down.
In simpler terms, this means that as soon as a table exists, Supabase generates REST URLs that can be used to read from or write to that table over the internet. This is convenient for developers because it means they aren’t required to write backend code to expose their data. On the flip side, it also means those APIs are live unless you explicitly restrict them.
The problem was that Moltbook’s website publicly exposed the database URL along with a Supabase publishable key. That key is meant for limited, non-sensitive use, but in this case it provided access to highly sensitive data, including every agent’s secret API keys, claim tokens, verification codes, and information about which users owned which agents, all without authentication or protection.
Once that information was public, the platform no longer had a reliable way to distinguish between a legitimate user and an outsider. In an agent-based system, that distinction is critical. Agents are designed to act on behalf of users, often with access to external services and private data. When agents can be commandeered without authentication, the system effectively hands execution authority to anyone who knows where to look.
Why Agent Platforms Raise the Stakes
In a traditional web application, an exposed database often leads to data leakage. That is bad enough. But in an agent platform, the consequences can be compounded because agents are granted authority. They are designed to execute tasks, call tools, and interact with other systems. When an attacker can see agent secrets and ownership mappings, they can trigger actions using another user’s credentials and connected services.
From a business standpoint, the risk was immediate. The exposure made it possible for outsiders to trigger actions using another company’s agents, credentials, and connected services.
How This Could Have Been Caught Early
O’Reilly said the security failure was frustrating, in part, because it would have been “trivially easy” to fix. He went so far as to say just two SQL statements would have protected the API keys. Although the article didn’t specify what those two lines were, I asked ChatGPT what they might be because my curiosity was piqued. It’s response:
Supabase exposes REST APIs by default. The primary mechanism for protecting sensitive data is Row Level Security (RLS). If RLS is not enabled, any client with a valid API key can query the table.
—ChatGPT
It went on to list those lines:
Enable row level security on the table
This tells Postgres to stop trusting the client by default:
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
Without this, Supabase will happily return rows to any request that reaches the API, even if the key was never meant to access sensitive data.
Add a policy that restricts access based on the authenticated user
This enforces ownership at the database level instead of assuming the application layer will handle it. A typical policy would look like this:
CREATE POLICY "Agents are only accessible by their owner"
ON agents
FOR ALL
USING (owner_id = auth.uid());5 Prompts to Shore Up Security
No one appears to be treating this as a personal failure by Schlicht, and he worked with security researcher Jameson O’Reilly to address the vulnerability once it was disclosed. Still, the incident serves as a cautionary example for vibe coders who may not have formal security or engineering experience to draw on when building agent-based systems.
So I asked ChatGPT to provide prompts that vibe coders could use to prevent security lapses in their code. These aren’t exhaustive. I personally loved the red-team vs blue-team test Redditor Uditakhourii ran on OpenClaw. That approach was sheer genius, imo. But I wanted to provide something a bit more accessible to vibe coders.
Check for Exposed Secrets and Keys
Review this application as if you are an external user with access to the frontend code and network requests. Identify any API keys, tokens, URLs, or credentials exposed to the client. For each one, explain what it can access, whether it can retrieve sensitive data, and whether it could be abused if discovered by someone outside the organization.
Check Ownership and Authorization Enforcement
Analyze how this system determines who owns which resources, including AI agents, data records, and connected accounts. Identify any actions where ownership is implied rather than enforced. Call out specific places where a request could reference another user’s resource and still succeed.
Check for Cross-User Agent Control
Assume you are an unauthorized user attempting to control an AI agent that does not belong to you. Describe the steps you would take to identify that agent, obtain any required identifiers or secrets, and issue commands to it. If this is not possible, explain exactly which checks prevent it.
Check Backend and Database Exposure
Examine the backend architecture and database configuration. Identify which tables contain sensitive data such as API keys, tokens, verification codes, or ownership mappings. For each table, explain what prevents an unauthenticated or low-privilege client from querying it directly.
Check Agent Blast Radius
List the most damaging actions an AI agent can perform if it is compromised. Include data access, data modification, third-party API calls, and account-level actions. For each action, explain what technical controls limit the impact if that agent is misused.
Leave a Reply