In February 2025, Andrej Karpathy coined "vibe coding" — "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Six months later, Moltbook — an AI-built social network — exposed 1.5 million rows of user data, including live API keys for OpenAI, Anthropic and Google. The same month, CVE-2025-48757 — a flaw in Lovable's Supabase integration — left around 170 production apps open to anyone who knew where to look.

Vibe coding isn't the problem. Unattended vibe coding is. The fix for vibe coding security isn't to slow down — it's guardrails: cheap, automated constraints that catch the specific failure modes LLMs actually have, so you keep the speed and drop the breach.

Why This Is Getting Worse, Not Better

One analysis of 2026 CVE data counted dozens of new vulnerabilities in March traced to AI-generated code, up from a handful in January. The sample is one firm's tally, and attribution is messy — but the direction matches everything else we're seeing.

The failure modes aren't random. Moltbook's leak came from a missing Supabase row-level-security policy. Lovable's CVE was an inverted access control check — code that did the opposite of what it appeared to do. LLMs generate plausible code. Plausible and correct diverge exactly at the boundaries: auth, permissions, data exposure. The places where wrong code looks identical to right code until someone pokes it.

Those are the real vibe coding security risks. Not "the AI writes garbage" — it mostly doesn't. It writes confident code that's wrong in ways a quick read won't catch.

Guardrail 1: Sandbox the Filesystem First

The agent shouldn't touch anything outside the project. Not your ~/.ssh, not your .env, not your dotfiles. This is an OS-level constraint, not a prompt-level suggestion — prompts can be talked out of, kernels can't.

Octomind does this with one flag, enforced by Landlock on Linux and Seatbelt on macOS:

bash
octomind run developer:general --sandbox

Now everything the agent does stays inside the working directory. If a task genuinely needs outside access, you grant it deliberately, once, instead of having it by default.

Guardrail 2: Write Policy as Code

"Review the output carefully" isn't a guardrail. It's a hope. Policy as code is a rule the runtime enforces before an action happens — no model cooperation required.

Octomind guardrails are plain TOML. A rule that blocks writes to anything environment-shaped looks like this:

toml
[[guard]]
match   = "filesystem-write(paths=\\.env|secrets/|credentials)"
message = "Secrets are managed outside the repo. Ask the user instead."

Guards are pre-call by construction: the match is checked before the executor runs, so the model never gets to touch the file — it just gets a synthetic error back, not a report afterward. You can hook validators after actions too, and run custom scripts when rules fire. The point is that the rules live in a file, you code-review them like any other file, and they apply to every session — including the ones your teammates run.

Guardrail 3: Cap the Spend

A vibe-coded runaway is usually a loop: the agent retries, the test still fails, it retries bigger. Nobody watches a side project at 2 AM.

Set hard ceilings per request and per session:

toml
max_request_spending_threshold = 0.5
max_session_spending_threshold = 2.0

Interactively, Octomind asks before exceeding a cap. In a pipeline, it just stops. A loop that can't spend more than two dollars is a loop that can't ruin your week.

Guardrail 4: Make an Agent Review the Diff Before You Do

You can't read every line. Another model can. And it reads differently than the one that wrote the code — that's exactly what you want.

Pipe the diff through a review pass with structured output:

bash
git diff origin/main... | octomind run developer:general \
  --sandbox --format jsonl --schema review.schema.json

You get typed findings — severity, file, line, reason — instead of prose to interpret. This catches the inverted access checks and the missing RLS policies surprisingly well, because reviewers look for different things than writers. We wrote up the full CI mechanics in running agents non-interactively.

Guardrail 5: Keep Secrets Out of the Prompt Entirely

Moltbook's leaked API keys sat in a database anyone could query. Most secrets in AI-built apps get there the same way: the model needed a key, someone pasted it, and it ended up committed or client-side.

The guardrail is structural. Secrets live in environment variables the agent can reference but never echo, and the policy from guardrail 2 blocks writes to secret-shaped paths. If the agent needs a key at runtime, it reads it from the environment — it never becomes part of the code, the prompt, or the repo.

Guardrail 6: Run in CI What You Run Locally

The last gap is drift: it worked on your machine, with your capabilities loaded, your model, your luck. The same task in CI, pinned and deterministic, is the honest test.

Force the capability surface so the run doesn't depend on fuzzy matching:

bash
OCTOMIND_CAPABILITIES=filesystem-read,codesearch \
  octomind run developer:general --format jsonl < task.txt

Now every PR gets the same treatment your local sessions get — sandboxed, capped, policy-checked — and a guardrail firing shows up as an event in the output stream you can assert on.

Does This Kill the Vibes?

No. That's the part that surprised me. These vibe coding best practices don't slow the loop down — they remove the anxiety tax from it. When the sandbox is on, the policy file is loaded, and the spend cap is set, you can let the agent run hot, because the blast radius of a bad decision is a blocked action, not a leaked database.

Vibe coding with guardrails is just engineering with a very fast junior developer on the team. Vibe coding without them is Moltbook.

Get Octomind — sandbox on, policy file loaded, and let it rip.

FAQ

Is vibe coding safe for production? Not by itself. The code AI produces is plausible but unverified — and it fails at auth and data-exposure boundaries, which is exactly where you can't afford to fail. It's only production-safe when you wrap it in automated constraints: filesystem sandboxing, policy rules, spend caps, and a review pass. Ship the process, not just the code.

What are the main risks of AI-generated code? Three patterns show up again and again. Missing access controls — Moltbook had no row-level-security policy, so anyone could query 1.5M rows including API keys. Inverted permission checks — Lovable's CVE-2025-48757 flipped the logic, affecting ~170 apps. And committed secrets, because someone pasted a key and the model ran with it. None of these look wrong in a quick read. That's why automated checks catch them and eyeballs don't.

Do guardrails slow down development? Setup costs an afternoon. After that, they're free at runtime — Octomind's guardrails run before actions as file-based rules, the sandbox is a single flag, and spend caps only trigger on runaway behavior. The speed you lose to a blocked action is cheaper than the speed you lose to an incident.