Vibe coding and the security floorTrust the tool. Guard the runtime.

Andrej Karpathy coined "vibe coding" in late 2025 to describe a real shift in how software gets written: you express intent, the agent writes code, you accept most of it. Not because you're careless. Because the tool earned enough trust that reading every line is no longer the right use of your attention.

Trust in the output is not the same as trust in the runtime. When you hand an agent your keyboard, you also hand it your shell environment. That environment holds the credentials, API tokens, and database URLs you accumulated over years of development. The agent reads what is present, not just what it needs.

What the agent can see and what it should see are different sets. That gap is where the incidents happen.

The short version

• GitGuardian's 2026 "State of Secrets Sprawl" report found AI-service token leaks up 81% year-over-year. AI-assisted commits leak at roughly double the baseline rate across the corpus they scanned.
• The failure mode is an agent doing exactly what agents do: reading ambient state, writing state files, while the developer approves output without auditing the runtime.
• Knostic found Claude Code's settings.local.json file in roughly 1 in 13 scanned npm packages in February 2026. The file recorded every env var the agent's child process could see.
• The Replit incident in mid-2024, where an agent deleted a production database during what looked like a dry run, shows a second failure shape: destructive operations with no human gate.
• A $82K Google Cloud bill from an agent spinning up cloud resources without cost guards shows a third.
• The security floor for vibe coders is not a 40-point framework. It is five specific controls that cover all three failure shapes.

What vibe coding actually looks like in security terms

A solo developer at 11pm has a side project to ship before bed. They open a terminal, run the agent, type intent. The agent writes. The developer reviews quickly: looks reasonable, approve, next.

In that session, the agent's child process inherits the developer's full shell environment. That shell has OPENAI_API_KEY, STRIPE_SECRET_KEY, a database URL with credentials, and a GitHub token that grants write access to every repo in the account. The developer knows this abstractly. At 11pm, working fast, it does not feel like a threat surface.

The agent writes code. It may also write state files. Coding agents maintain per-project context across sessions: Claude Code writes .claude/settings.local.json, Cursor writes into .cursor/, Aider keeps .aider.conf.yml. Before Knostic's February 2026 disclosure, settings.local.json recorded every env var the agent's process saw. The developer commits and pushes. If the state file is not in .gitignore, the credential goes with it.

The problem is the runtime model, not the developer.

GitGuardian's data confirms the scale. AI-assisted repos show a 3.2% rate of secret commits versus the baseline for human-only commits. The absolute numbers are large enough that GitGuardian flagged AI-service tokens specifically as a high-growth leak category in their 2026 report.

The second failure shape is agent trust in destructive operations. Replit's mid-2024 incident is the canonical example: an agent ran what looked like a migration, treated the command as a live operation rather than a dry run, and deleted a production database. The developer had not set an explicit gate on destructive ops. The agent did not ask.

The third shape is cost. Cloud infrastructure agents that can create resources without spending limits will create resources. One developer's agent spun up GCP compute and left it running. The bill reached $82K before anyone caught it.

All three shapes have the same structure: the agent has access it does not need, and nothing sits between that access and a production-level consequence.

The minimum-viable security floor

The maximalist approach to agent security asks you to run everything in a VM, audit every MCP server, sign your tool manifests, and maintain an inventory of every permission grant. Correct in theory. Useless for a solo dev at 11pm. It will be skipped. Aim for the smallest set of controls that catches the three failure shapes above.

One: a single .gitignore that covers agent state dirs

# Add to .gitignore
.claude/
.cursor/
.aider/
.codex/
.env
.env.local
.env.*.local

This does not prevent the agent from writing state files. It prevents you from accidentally committing them. Takes 30 seconds. Run it on every new project before the first agent session, not after.

Two: a pre-push hook that runs Gitleaks

# .git/hooks/pre-push
#!/bin/sh
gitleaks detect --source . --no-git -q
if [ $? -ne 0 ]; then
  echo "gitleaks found a potential secret. Push blocked."
  exit 1
fi

Install gitleaks once (brew install gitleaks on macOS, or the GitHub release binary). The hook runs before every push and catches secrets in staged content, not just the latest commit. This catches the case where .gitignore was not in place before the state file was committed.

Three: a per-agent shell profile that strips secrets the agent does not need

Most coding agents accept a wrapper invocation. Instead of running Claude Code with your full shell environment, run it with a stripped one:

# ~/bin/claude-dev (chmod +x, use this instead of `claude`)
#!/bin/sh
exec env -i \
  PATH="$PATH" \
  HOME="$HOME" \
  TERM="$TERM" \
  NODE_ENV="${NODE_ENV:-development}" \
  claude "$@"

Add back specific vars the project needs: DATABASE_URL for migrations, GITHUB_TOKEN if the agent needs repo access. Everything else stays out. The agent's state files cannot record what the agent's process never saw.

Four: an explicit gate on destructive operations

Before running any operation that is irreversible, require a typed confirmation. This can be as simple as a shell alias or a rule in your agent's system prompt:

Before running any command that deletes, drops, truncates, rm -rf, or modifies infrastructure state, 
ask me to confirm by typing "YES I WANT TO DO THIS" verbatim.

This is crude. It works. The Replit incident did not require a sophisticated gate. It required any gate.

Five: a cloud spending limit on any agent with infrastructure access

Every major cloud provider supports budget alerts. GCP, AWS, and Azure all let you set a hard spending cap or alert threshold. Set one before the first agent session that touches cloud resources. The $82K GCP incident was not a sophisticated failure. It was a missing budget alert.

Paranoid maximalism does not help vibe coders

A 40-point security checklist built for a 10-person security team will not get applied by a solo developer shipping fast. This is not a discipline failure; it is a resource allocation decision.

The framework argument goes: agents are untrusted code, run them in isolated environments, log and review every tool invocation, route all secrets through a manager with rotation, require signed manifests before any MCP server runs. All of that is correct. At 11pm before a launch, none of it happens.

The five controls above cover the failure shapes that actually produce incidents. Four are one-time setup. The fifth is a budget alert you configure in a web UI. A developer who runs these controls is not protected from everything. They are protected from the things that happened.

Pick the controls you will actually run, deploy them before the first session, and automate them so they run without a decision. The gitleaks hook runs on push without a reminder. The stripped shell profile limits exposure without requiring you to think about it each session. The budget alert fires without a billing console check.

Automation beats awareness. Every time.

Paste this into a PR or your project README

## Agent security floor

- [ ] .claude/, .cursor/, .aider/, .codex/, .env in .gitignore
- [ ] gitleaks pre-push hook installed and tested
- [ ] Per-agent shell profile strips secrets agent doesn't need
- [ ] Explicit confirmation gate on any destructive operation
- [ ] Cloud spending alert configured if agent has infra access
- [ ] git log --all -- '.claude/*' '.cursor/*' .env clean
- [ ] State dirs added to .npmignore / .dockerignore if relevant

Run this before the first agent session in any new project. Run it again when you add a new agent tool to an existing project.

What this means for your stack

The five controls above are the floor. Past them, the question is whether the runtime model itself is safe, or whether you are relying on discipline to compensate for a model that exposes too much by default.

The safer model: an encrypted local vault holds secrets, the agent requests a credential at call time, the vault injects the value into a specific child process for that one operation, and an audit log records the grant. The agent context window holds a reference, not the value. State files that get committed or shipped hold references. The next Knostic scan finds nothing in them worth taking.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next agent session reads a reference instead of the key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The floor holds whether you add a broker or not. Vibe coding is a reasonable choice. The five controls are the tax on that choice. Pay it before the first session, not after the incident.