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

Contents

Why Agents Fail 3 Vibe Coding Security Bugs I’ve Seen Recently 1. Leaked API Keys 2. Public Access to Databases 3. XSS Vulnerabilities How to Vibe Code Correctly 1. Better prompts 2. Better Reviews 3. Automated Guardrails Conclusion References

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

Then, security firm Wiz released a report showing a massive leak in the Moltbook ecosystem [1]. A misconfigured Supabase database had exposed 1.5 million API keys and 35,000 user email addresses directly to the public internet.

How did this happen? The root cause wasn’t a sophisticated hack. It was vibe coding. The developers built this through vibe coding, and in the process of building fast and taking shortcuts, missed these vulnerabilities that coding agents added.

This is the reality of vibe coding: Coding agents optimize for making code run, not making code safe.

Why Agents Fail

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

1. Speed over safety: LLMs are optimized for acceptance. The simplest way to get a user to accept a code block is often to make the error message go away. Unfortunately, the constraint causing the error is sometimes a safety 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 side effects: AI is often unaware of the full codebase context, especially when working with large complex architectures. We saw this constantly with refactoring, where an agent fixes a bug in one file but causes breaking changes or security leaks in files referencing it, simply 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 just predict the tokens they believe will come next, based on their training data. They don’t know why a security check exists, or that removing it creates risk. They just know it matches the syntax pattern that fixes the bug. To an AI, a security wall is just a bug preventing the code from running.

These failure patterns aren’t theoretical — They show up constantly in day-to-day development. Here are a few simple examples I’ve personally run 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) from a React frontend. To fix this, the agent just puts the API key at the top 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 key visible to anyone, since with JS you can do “Inspect Element” and view the code.

2. Public Access to Databases

This happens constantly with Supabase or Firebase. The issue is I was 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 as it makes the code run. But it just made the entire database public to the internet.

3. XSS Vulnerabilities

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

// What the agent writes
<div dangerouslySetInnerHTML={{ __html: aiResponse }} />

The AI rarely suggests a sanitizer library (like dompurify). It just gives you the raw prop. This is an issue because it leaves your app wide open to Cross-Site Scripting (XSS) attacks where malicious scripts can run on 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:

Sources [3], [4], [5]

How to Vibe Code Correctly

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

1. Better prompts

We can’t just ask the agent to “make this secure.” It won’t work because “secure” is too vague for an LLM. We should instead use spec-driven development, where we can have pre-defined security policies and requirements that the agent must satisfy before writing any code. This can include but is not limited to: no public database access, writing unit tests for each added feature, sanitize user input, and no hardcoded API keys. A good starting point is grounding these policies in the OWASP Top 10, the industry-standard list of 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. Instead of just asking for a fix, we can ask: “What are the security risks of this approach, and how will you avoid them?”.

2. Better Reviews

When vibe coding, it’s really tempting to just view the UI (and not look at code), and honestly, that’s the whole 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 pointed out that as we rely more on AI, our primary job shifts from writing code to reviewing it. It’s similar to how we work with interns: we don’t let interns push code to production without proper reviews, and we should 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 can’t ensure humans will be able to catch everything. We should automate security checks for agents to run beforehand. We can 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 automatically 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 far more reliably and safely when paired with deterministic checkers. The model generates code, the tools validate it, and any unsafe code changes get rejected automatically.

Conclusion

Coding agents enable us to build faster than ever before. They improve accessibility, allowing people of all programming backgrounds to build anything they envision. But this should not come at the expense of security and safety. By leveraging prompt engineering techniques, reviewing code diffs thoroughly, and providing clear guardrails, we can use AI agents safely and build better applications.