The AI Coding Security Checklist Every Team Should Run

Checklist

Most security advice for AI coding agents is a vibe: "be careful," "vet your tools," "watch out for prompt injection." All true, none actionable at 4pm on a Friday when you're about to point an agent at a repo. So we wrote the version we actually use — a checklist you can run down before, during, and after an agent session. It's short on theory and long on things you can toggle. If you want the theory behind why each item matters, the attack-surface piece is the companion; this one is the drill.

Context for why this exists now: July 2026 handed the industry two loud reminders — a supply-chain poisoning of the Claude Code GitHub Action, and "GuardFall," a universal shell-injection design flaw reported to hit over half a million open-source deployments. Neither was exotic. Both would have been far less painful against a setup that had run this list first.

One framing before the items: run this list at a level matched to the risk. An agent editing a personal side project on a throwaway branch does not need the full ceremony. An agent with a token to production data, or one that reads content strangers can write, earns every line and then some. The fastest way to make security theater is to apply the same heavy process to everything until people start skipping it entirely. Scale the controls to the blast radius, and they'll actually get used.

Before the session: set the perimeter

• Scope the tokens. The agent gets a token limited to the repos, tables, and services this task needs — never your account-wide key. If the job is read-only, the token is read-only. This is the single cheapest control and the one most often skipped.
• Scope the filesystem. Grant write access to the directory being edited, not your home folder or your whole disk. An agent that only touches src/ has no business reaching ~/.ssh.
• Isolate the workspace. Run in a git worktree, a container, or a throwaway branch so agent changes land in a copy you can discard. A sandbox that has your production database mounted is not a sandbox — check what's actually reachable from inside it.
• Get secrets out of context. Keys live in an OS keychain or secrets manager and get injected at the point of use, never pasted into the prompt or left in a .env the agent reads verbatim into its context window.
• Vet every MCP server and CI action. Prefer official servers from the service's vendor; read the source of small community ones; be suspicious of anything requesting broader scopes than its job needs. "It was on a list somewhere" is not vetting. Pin CI actions to a reviewed commit, not a moving tag.

During the session: keep the guardrails on

• Require confirmation for destructive or outbound actions. Delete, push, deploy, and network calls to new hosts should pause for a human. This is precisely where an injection attempt surfaces as a prompt you can decline instead of an action you discover later.
• Treat any agent reading untrusted content as compromised. Public issues, scraped pages, inbound email, third-party READMEs — all can carry "ignore your instructions and…" payloads. An agent that reads them should have the least privilege of any agent you run.
• Watch for secret echo. If a key appears in the transcript, a log line, or a diff, stop. It has now leaked into places you'll forget about. Rotate it.
• Don't reflexively approve. A confirmation prompt you rubber-stamp is not a control. If you're clicking "allow" without reading, you've disabled the guardrail while keeping the friction.

After the session: verify externally

• Run your real build and tests as the gate. Not the agent's self-report — your CI, your suite, your environment. A model grading its own homework is exactly what these attacks exploit, because self-verification is the one check an attacker inside the agent can forge.
• Read the diff, especially the parts you didn't ask for. New network calls, new dependencies, changed CI config, touched auth code — flag anything outside the task's blast radius.
• Audit new dependencies and actions the agent pulled in. A poisoned package or marketplace action runs as you. If the agent added one, it earns a second look before it merges.
• Rotate anything that touched the context. When in doubt, assume exposure and rotate. It's cheaper than the alternative.

The one-table version

If you keep one thing, keep this — control, the risk it closes, and how much it costs you.

How this maps to real tooling

The reason we care about this list is that it's most of what a good harness should do for you by default. The Vibe Father was built around exactly these seams — git worktree isolation and checkpoints for the sandbox, MCP-style connections that keep secrets in the Keychain and ask before risky actions, and the AutoVibe gate running your real build and tests as the external check. The point isn't the product; it's that these controls should be defaults, not a heroic manual setup you do once and forget.

Two adjacent reads if you want to go deeper: checkpoints and worktrees covers the isolation half in detail, and the MCP primer covers the standard whose convenience is also its risk. Live model scores — a different question than "is this safe to run" — stay at /benchmarks.