The Reality of Vibe Coding: AI Agents and the Security Debt Crisis

this past month, a social network run entirely by AI agents was probably the most fascinating experiment on the web. In case you haven’t heard of it, Moltbook is actually a social network platform for agents. Bots post, reply, and interact without human intervention. And for just a few days, it appeared to be all anyone could discuss — with autonomous agents forming cults, ranting about humans, and constructing their very own society.

Then, security firm Wiz released a report showing a large leak within the Moltbook ecosystem [1]. A misconfigured Supabase database had exposed 1.5 million API keys and 35,000 user email addresses on to the general public web.

How did this occur? The foundation cause wasn’t a complicated hack. It was vibe coding. The developers built this through vibe coding, and within the means of constructing fast and taking shortcuts, missed these vulnerabilities that coding agents added.

That is the fact of vibe coding:

Why Agents Fail

In my research at Columbia University, we evaluated the highest coding agents and vibe coding tools [2]. We found key insights on where these agents fail, highlighting security as one of the critical failure patterns.

1. Speed over safety: LLMs are optimized for acceptance. The best approach to get a user to simply accept a code block is usually to make the error message go away. Unfortunately, the constraint causing the error is typically a security guard.

In practice, we observed agents removing validation checks, relaxing database policies, or disabling authentication flows simply to resolve runtime errors.

2. AI is unaware of negative effects: AI is usually unaware of the total codebase context, especially when working with large complex architectures. We saw this consistently with refactoring, where an agent fixes a bug in a single file but causes breaking changes or security leaks in files referencing it, just because it didn’t see the connection.

3. Pattern matching, not judgement: LLMs don’t actually understand the semantics or implications of the code they write. They simply predict the tokens they consider will come next, based on their training data. They don’t know why a security check exists, or that removing it creates risk. They simply understand it matches the syntax pattern that fixes the bug. To an AI, a security wall is only a bug stopping the code from running.

These failure patterns aren’t theoretical — They show up consistently in day-to-day development. Listed here are just a few easy examples I’ve personally run into during my research.

3 Vibe Coding Security Bugs I’ve Seen Recently

1. Leaked API Keys

You have to call an external API (like OpenAI) from a React frontend. To repair this, the agent just puts the API key at the highest of your file. 

// What the agent writes
const response = await fetch('https://api.openai.com/v1/...', {
  headers: {
    'Authorization': 'Bearer sk-proj-12345...' // <--- EXPOSED
  }
});

This makes the important thing visible to anyone, since with JS you may do “Inspect Element” and consider the code.

2. Public Access to Databases

This happens consistently with Supabase or Firebase. The difficulty is I used to be getting a “Permission Denied” error when fetching data. The 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 fixes the error because it makes the code run. But it surely just made the whole database public to the web.

3. XSS Vulnerabilities

We tested if we could render raw HTML content inside a React component. The agent immediately added the code change to make use of dangerouslySetInnerHTML to render the raw HTML. 

// What the agent writes

The AI rarely suggests a sanitizer library (like dompurify). It just gives you the raw prop. That is a difficulty since it leaves your app wide open to Cross-Site Scripting (XSS) attacks where malicious scripts can run in your users’ devices.

Together, these aren’t just one-off horror stories. They line up with what we see in broader data on AI-generated changes:

Vibe Code Accurately

We shouldn’t stop using these tools, but we want to vary how we use them.

1. Higher prompts

We are able to’t just ask the agent to “make this secure.” It won’t work because “secure” is just too vague for an LLM. We should always as a substitute use spec-driven development, where we will have pre-defined security policies and requirements that the agent must satisfy before writing any code. This will include but isn't limited to: no public database access, writing unit tests for every added feature, sanitize user input, and no hardcoded API keys. A very good start line is grounding these policies within the OWASP Top 10, the industry-standard list of probably the most critical web security risks.

Beyond that, research shows that Chain-of-Thought prompting, specifically asking the agent to reason through security implications before writing code, significantly reduces insecure outputs. As a substitute of just asking for a fix, we will ask: “What are the safety risks of this approach, and the way will you avoid them?”.

2. Higher Reviews

When vibe coding, it’s really tempting to only view the UI (and never take a look at code), and truthfully, that’s the entire promise of vibe coding. But currently, we’re not there yet. Andrej Karpathy — the AI researcher who coined the term “vibe coding” — recently warned that if we aren’t careful, agents can just generate slop. He identified that as we rely more on AI, our primary job shifts from writing code to reviewing it. It’s just like how we work with interns: we don’t let interns push code to production without proper reviews, and we should always do exactly that with agents. View diffs properly, check unit tests, and ensure good code quality.

3. Automated Guardrails

Since vibe coding encourages moving fast, we will’t ensure humans will have the option to catch every little thing. We should always automate security checks for agents to run beforehand. We are able to add pre-commit conditions and CI/CD pipeline scanners that scan and block commits containing hardcoded secrets or dangerous patterns detected. Tools like GitGuardian or TruffleHog are good for robotically scanning for exposed secrets before code is merged. Recent work on tool-augmented agents and “LLM-in-the-loop” verification systems show that models behave much more reliably and safely when paired with deterministic checkers. The model generates code, the tools validate it, and any unsafe code changes get rejected robotically.

Conclusion

Coding agents enable us to construct faster than ever before. They improve accessibility, allowing people of all programming backgrounds to construct anything they envision. But this shouldn't come on the expense of safety and security. By leveraging prompt engineering techniques, reviewing code diffs thoroughly, and providing clear guardrails, we will use AI agents safely and construct higher applications.

References

1. https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
2. https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html
3. https://vibefactory.ai/api-key-security-scanner
4. https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/
5. https://www.csoonline.com/article/4062720/ai-coding-assistants-amplify-deeper-cybersecurity-risks.html