This past month, a social network run entirely by AI agents has become the most interesting experiment on the Internet. In case you haven't heard of it, Moltbook is essentially a social media platform for agents. Bots post, reply, and interact without human intervention. And for a few days, it seemed like anyone could talk about it – and private ambassadors formed cults, talked about people, and built their own community.
After that, the security company Wiz released a report showing a major leak in the Moltbook ecosystem [1]. Supabase's compromised database exposed 1.5 million API keys and 35,000 users' email addresses directly to the public Internet.
How does this happen? The motive was not a sophisticated robbery. It was vibe coding. Developers built this using vibe code, and in the process of building quickly and taking shortcuts, they missed this additional vulnerability for code agents.
This is the truth of vibe coding: Code agents prepare to make code work, not to make code safe.
Why Agents Fail
In my research at Columbia University, we tested the top coding agents and coding tools for vibe [2]. We found important insights into where these agents fail, highlighting security as one of the most important failure patterns.
1. Speed over safety: LLMs are prepared for admission. The easiest way to get the user to accept code blocking is usually to make the error message go away. Unfortunately, the limitation that causes the error is sometimes the guard.
In practice, we've seen agents remove authentication checks, relax database policies, or disable authentication flows to resolve runtime errors.
2. AI does not recognize side effects: AI is often unaware of the full context of the codebase, especially when working with large complex architectures. We've seen this frequently with refactoring, where the agent fixes a bug in one file but causes breaking changes or security leaks in the referenced files, simply because it didn't see the connection.
3. Matching patterns, not judging: LLMs do not fully understand the semantics or implications of the code they write. They simply predict the tokens they believe will come next, based on their training data. They don't know why there is a security check, or that removing it creates a risk. They just know that it matches the syntax pattern that corrects the error. In AI, a firewall is simply a barrier that prevents the code from running.
These failure patterns are not theoretical – They occur regularly in everyday development. Here are a few simple examples that I ran into during my research.
3 Vibe Coding Security Bugs I've Seen Recently
1. Leaked API Keys
You need to call an external API (like OpenAI) in the React frontend. To fix this, the agent simply places the API key at the top of your file.
// What the agent writes
const response = await fetch(' {
headers: {
'Authorization': 'Bearer sk-proj-12345...' // <--- EXPOSED
}
});This makes the key visible to anyone, as with JS you can do “Inspect Element” and view the code.
2. Public Access to Information Sites
This happens frequently with Supabase or Firebase. The problem is that I was getting a “Permission Denied” error when downloading the data. AI suggested policy of USING (truth) or public access.
-- What the agent writes
CREATE POLICY "Allow public access" ON users FOR SELECT USING (true);This fixes the error as it makes the code work. But it just makes the entire database public on the Internet.
3. XSS vulnerability
We tested whether we could serve raw HTML content inside a React component. The agent quickly added a code change to use dangerouslySetInnerHTML to render raw HTML.
// What the agent writes
AI rarely suggests a cleanup library (like dompurify). It just gives you raw support. This is a problem because it leaves your application more open to Cross-Site Scripting (XSS) attacks where malicious scripts can run on your users' devices.
Together, these are not just one-off horror stories. They're consistent with what we're seeing in the broader data of changes made by AI:
How to Vibe Code Properly
We should not stop using these tools, but we need to change the way we use them.
1. Better information
We can't just ask the agent to “verify this.” It will not work because “protection” is not clear in LLM. Instead we should use process-driven development, where we can have predefined security policies and requirements that the agent must satisfy before writing any code. This can include but is not limited to: no access to public databases, no unit testing of each added feature, sanitizing user input, and no hard-coded API keys. A good starting point is to base these policies on the OWASP Top 10, an industry-standard list of the most important web security risks.
Additionally, research shows that Chain-of-Thought information, specifically asking the agent to think about security implications before writing code, significantly reduces insecure outcomes. Instead of just asking for a fix, we can ask: “What are the safety risks of this method, and how will you avoid them?”.
2. Better reviews
When coding for vibe, it's really tempting to look at the UI (and not look at the code), and honestly, that's the whole promise of vibe coding. But for now, we are not there yet. Andrej Karpathy – the AI researcher who coined the term “vibe coding” – recently warned that if we're not careful, agents can just slop. He pointed out that as we rely more on AI, our main work is changing from writing code to updating it. It's the same way we work with interns: we don't let interns push code into production without proper review, and we have to do that with agents. Visualize exceptions, run unit tests, and ensure good code quality.
3. Automatic Monitors
Since vibe writing encourages speed, we can't guarantee that people will be able to catch everything. We have to perform automatic security checks for agents to run beforehand. We can add pre-commit conditions and CI/CD pipeline scanners that scan and block jobs that contain hard-coded secrets or detected malicious patterns. Tools like GitGuardian or TruffleHog are great for automatically scanning for exposed secrets before code is compiled. Recent work on advanced agents and “LLM-in-the-loop” validation systems shows that the models behave more reliably and safely when paired with deterministic experiments. The model generates the code, the tools validate it, and any unsafe code changes are automatically rejected.
The conclusion
Coding agents enable us to build faster than ever before. They improve accessibility, allowing people of all programming backgrounds to create anything they can imagine. But this should not come at the expense of safety and security. By using agile development techniques, completely different code reviews, and providing clear leads, we can safely deploy AI agents and build better applications.
