Vibe coding security: the risks, and a checklist that doesn't slow you down

Two kinds of risk

Most writing about vibe coding security is about the first kind: vulnerabilities in the generated app. The second kind gets less attention and hurts sooner: what the agent does on your computer while it builds.

Risks in the code you ship

• Secrets in the wrong place. API keys hardcoded in source, committed to git, or put in front-end code where every visitor can read them.
• Missing access control. Endpoints that check you're signed in but not that the record is yours. Database rules, such as row-level security, left off because the demo worked without them.
• Unvalidated input. SQL built from strings, HTML rendered from user content, file paths taken from requests.
• Dependencies nobody chose. Outdated packages, and sometimes packages that don't exist: a model invents a plausible name, and an attacker registers it.
• Debug settings in production: open CORS, verbose errors, admin routes without a password.

Risks on your machine

• Deleted work. An agent tidying up runs rm -rf on the wrong folder, or git reset --hard over an afternoon of uncommitted changes.
• The wrong database. The connection string in .env pointed at production when the agent ran the migration.
• Leaked credentials. The agent reads .env or prints the environment while debugging. The values go to the model provider and into a transcript file on your disk.
• Prompt injection. A web page, an issue or a package README contains instructions aimed at the agent, and the agent follows them.
• Auto-approve. All of the above with no prompt in between.

A checklist for secure vibe coding

Before you start

1. Use test keys and a local or staging database. Production credentials don't belong on the machine the agent runs on.
2. Commit. A clean starting point makes every later step easier.
3. Tell the agent your rules in its instructions file: never read .env, never push, never touch the production config.
4. Turn on the guardrails your agent has: deny rules, a sandbox, hooks.

While the agent works

1. Read the commands that delete, reset, push or migrate, even if you skim everything else.
2. Keep network access narrow when the agent is reading content from the internet.
3. Commit at each working state.

Before you ship

1. Search the repository for keys, and run a secret scanner on the git history.
2. Ask a second model, in a fresh session, to review the code for access control and input handling. A reviewer that didn't write the code finds more.
3. Check that every package the agent added exists, is the one you meant and is maintained.
4. Test as a second user: can they read or change the first user's data?
5. Rotate any key that appeared in a conversation.

A safety net for the machine side

Rollcage is a Mac app built for the second kind of risk. It needs no setup per project and stays out of the way:

• Snapshots copy your project the moment an agent starts, so deleted or overwritten work can be put back.
• The Guard keeps agents out of .env files and stops the most destructive commands, in Claude Code, Codex, Cursor and Gemini CLI.
• The network guard refuses uploads to paste and file-drop sites.
• The secrets leak scan finds keys that ended up in agent transcripts.

Rollcage protects your machine and your files. It doesn't review the code your agent writes. For that you still need the last section of the checklist.

Questions