Last month, a social network run entirely by AI agents was the most fascinating experiment on the internet. In case you haven’t heard, Moltbook is essentially a social networking platform for agents. Bots post, reply, and interact without human intervention. And for a few days, it seemed like all anyone could talk about was autonomous agents forming cults, ranting about humans, and building their own societies.
Security firm Wiz then released a report showing a massive breach in the Moltbook ecosystem. [1]. A misconfiguration of the Supabase database exposed 1.5 million API keys and 35,000 user email addresses directly to the public internet.
How did this happen? The root cause was not sophisticated hacking. It was vibe coding. The developers built this through vibe coding, but in the process of quickly building and running shortcuts, they missed these vulnerabilities that the coding agents added.
This is the reality of vibe coding: The coding agent optimizes your code so that it runs, rather than making it safe.
Why the agent fails
In my research at Columbia University, I evaluated top coding agents and the Vibe coding tool. [2]. We discovered important insights into where these agents fail and highlighted security as one of the most important failure patterns.
1. Speed over safety: LLM is optimized for acceptance. The easiest way to get users to accept a block of code is often to hide the error message. Unfortunately, sometimes the constraint causing the error is a safety device.
In practice, we observed agents removing validation checks, relaxing database policies, and disabling authentication flows just to resolve runtime errors.
2. AI does not recognize side effects. AI is often unaware of the entire context of the codebase, especially when dealing with large and complex architectures. This happens all the time with refactoring, where the agent fixes a bug in one file, but it simply doesn’t recognize the connection, causing breaking changes and security leaks to files that reference it.
3. Pattern matching, not judgment: LLMs don’t really understand the semantics or meaning of the code they write. They just predict which token they think will come next based on their training data. They don’t know why the security check exists or whether removing it poses a risk. They just know that it matches a syntax pattern that fixes the bug. To AI, security walls are nothing more than bugs that prevent code from running.
These failure patterns are not theoretical; they occur all the time in day-to-day development. Here are some simple examples that I personally encountered during my research.
3 Vibe coding security bugs I saw recently
1. Leaked API key
I need to call an external API (such as OpenAI) from my React frontend. To fix this, the agent simply puts the API key at the top of the file.
// What the agent writes
const response = await fetch('https://api.openai.com/v1/...', {
headers: {
'Authorization': 'Bearer sk-proj-12345...' // <--- EXPOSED
}
});Since JS allows you to “inspect element” and view the code, this makes the keys visible to everyone.
2. Public access to the database
This happens all the time with Supabase or Firebase. The problem is that I get a “Permission Denied” error when fetching the data. AI suggested a policy of USING (true) or public access.
-- What the agent writes
CREATE POLICY "Allow public access" ON users FOR SELECT USING (true);This will fix the error when the code runs. But it just exposed the entire database to the internet.
3. XSS vulnerabilities
I tested whether it’s possible to render raw HTML content inside a React component. The agent quickly added a code change to use dangerouslySetInnerHTML to render the raw HTML.
// What the agent writes
AI rarely suggests sanitizer libraries (like dompurify). Just give raw props. This is a problem because it leaves your app vulnerable to cross-site scripting (XSS) attacks that can run malicious scripts on a user’s device.
These aren’t just one-off horror stories. These are consistent with what we see in extensive data on AI-generated changes.
How to vibrate your cord correctly
You don’t have to stop using these tools, but you do need to change the way you use them.
1. Improved prompts
You can’t just ask your agent to “make this safe.” This doesn’t work because the word “safe” is too vague for an LLM. Instead, you should use specification-driven development, which allows you to predefine security policies and requirements that the agent must meet before you write any code. This includes, but is not limited to, prohibiting access to public databases, writing unit tests for each feature added, sanitizing user input, and prohibiting 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 prompts, specifically asking agents to reason about security implications before writing code, significantly reduce insecure output. Instead of just asking for a fix, you can ask, “What security risks does this approach pose and how can I avoid them?”
2. Better reviews
When doing Vibe coding, it’s easy to be tempted to just see the UI (without looking at the code), but honestly, that’s the whole promise of Vibre coding. But we are not there yet. Andrej Karpathy, the AI researcher who coined the term “vibecoding,” recently warned that if we’re not careful, our agents could produce just slop. He pointed out that as we rely more on AI, our primary job will shift from writing code to reviewing it. This is similar to how I work with interns. You can’t let interns push code to production without proper reviews. You need to do exactly that for your agents as well. View diffs properly, check unit tests, and ensure good code quality.
3. Automatic guardrail
Vibe coding requires quick action, so we cannot guarantee that humans will be able to understand everything. Agent security checks should be automated and performed proactively. You can add pre-commit conditions and a CI/CD pipeline scanner that scans and blocks commits that contain hard-coded secrets or detected dangerous patterns. Tools like GitGuardian and TruffleHog are good for automatically scanning exposed secrets before the code is merged. Recent work on tool extension agents and “LLM-in-the-loop” verification systems shows that models behave much more reliably and securely when combined with deterministic checkers. Models generate code, tools validate it, and unsafe code changes are automatically rejected.
conclusion
Coding agents allow you to build faster than ever before. It improves accessibility and allows people of all programming backgrounds to build anything they can imagine. However, this should not be at the expense of security and safety. By leveraging agile engineering techniques, thorough code delta reviews, and clear guardrails, you can safely use AI agents and build better applications.
References
- https://www.wiz.io/blog/exused-moltbook-database-reveals-millions-of-api-keys
- https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html
- https://vibefactory.ai/api-key-security-scanner
- https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/
- https://www.csoonline.com/article/4062720/ai-coding-assistants-amplify-deeper-cybersecurity-risks.html
