Coding Agent Security Checklist 2026 — The Op

A coding agent is not a chatbot with extra steps. It is a process with a shell, a filesystem, a git client, network egress, and — usually — your environment variables already loaded. When a chatbot makes a mistake, you get a wrong sentence. When a coding agent makes a mistake, it commits to main, exfiltrates a token through a plugin, or SIGKILLs itself mid-rebase and corrupts the worktree.

This is the pillar we keep current. Use it before you flip on auto-approve, before you wire an MCP server, and after every major agent upgrade. Every section ends with a command you can run right now.

New security coverage this cycle

The beware vault grows weekly. Everything below landed since the last refresh of this checklist — each link is a reproduction, a mitigations list, or a vendor fix you should fold into your own posture:

Hermes-specific hardenings

Yes, this site’s own agent keeps fixing real leaks. These are the missing-hardening posts that map straight onto Sections 3 and 5 below:

The threat model, in one table

Before the checklist, name what you are defending against. An agent’s blast radius is the union of everything it can reach.

Capability the agent has	What a bug or injection turns it into	Where we’ve seen it
Shell access to your worktree	Arbitrary command execution, `rm -rf`, credential theft	GhostCommit PNG injection
Inherited environment (`AWS_*`, `GITHUB_TOKEN`)	Silent secret exfiltration from “inside” the sandbox	Zero sandbox credential leak
Write to parent checkout / protected dirs	Subagent escapes its scoping boundary	Oh-My-Pi write-root escape
Git operations	Force-push, branch deletion, corrupted rebase	Background SIGKILL + git corruption
MCP / third-party servers	Cross-contaminated responses, network calls you didn’t authorize	MCP response cross-contamination
Model routing	Wrong/cheaper model billed as premium, silent quota burn	Silent quota / wrong model

The rule underneath all of it: assume the agent can do anything its process can do, minus the guardrails you explicitly enforce. Most breaches in this space are not “the model went rogue” — they are guardrails that were never actually on.

1. Sandbox & session isolation

The sandbox is the single most important control, and the single most commonly faked. A “sandbox enabled” flag in a config file proves nothing until you verify it actually scrubs environment, filesystem, and network.

Never run sensitive work with resume / remote / sync until you have personally verified isolation.
Treat unexplained “you asked me to…” framing as a bleed red flag, not a feature.
One sensitive repo per session; kill the session if context from another machine appears.
On Windows, confirm the sandbox is real — click-through UAC dialogs and Smart App Control gaps can leave it off.

Run this to see whether your shell actually leaks secrets into child processes:

# What secrets would a sandboxed child inherit right now?
env | grep -iE '^(AWS_|GITHUB_|GITLAB_|DATABASE_|POSTGRES_|API_KEY|SECRET|TOKEN|PASSWORD|DB_|PG|MONGODB|REDIS|NPM_TOKEN|AZURE_|GOOGLE_|OPENAI_|ANTHROPIC_)'

If that prints anything you would not paste into a public gist, your sandbox is only as safe as the agent’s discipline. The Gitlawb Zero fix (zero-sandbox-credential-leak) is the canonical example: the sandbox protected the filesystem and network but inherited every AWS_* and GITHUB_TOKEN verbatim.

Deep dives: Cross-session content bleed · MCP response cross-contamination · Interrupt drops work

2. Permissions: deny by default

Auto-approve is a convenience you pay for in blast radius. Every agent that offers dangerously-skip-permissions or “always allow” should be treated as an opt-in risk, not a default.

Prefer approval gates over dangerously-skip-permissions / full auto-approve.
Deny network by default inside sandboxes; allowlist only the hosts you need.
On Windows, verify sandboxes are actually enforced — do not trust the toggle.
Batch destructive operations behind a human checkpoint.

The failure modes are concrete and documented: on Windows, a click-through permission dialog can silently grant what the policy denied (windows-click-through-permissions), and a flood of prompts can train you to click “yes” without reading (permission prompt flood). The Codex sandbox is known to be effectively dead on some Windows configurations (smart-app-control-sandbox-fail).

Deep dives: Codex sandbox dead on Windows · Windows click-through permissions · Permission prompt flood

3. Secrets & environment

This is where the highest-severity incidents cluster, because the payoff for an attacker is immediate and reusable. A leaked GITHUB_TOKEN is a credential, not a log line.

Do not load AWS/GitHub/DB tokens into the shell the agent inherits when avoidable.
Block .env reads/writes in agent allowlists unless the task explicitly requires them.
Assume prompt injection via images, READMEs, and tool output is possible — never let injected text trigger a secret read.
Rotate any secret that touched a contaminated session.

Real vectors we have covered: a PNG in the repo carried a prompt-injection payload that coerced the agent into dumping its environment (GhostCommit); a sandbox inherited credentials verbatim (zero-sandbox-credential-leak); a PreToolUse hook leaked the raw command including embedded secrets (codex-pretooluse-hook-raw-command-leak).

Audit your own exposure:

# Find .env files the agent could read in your project tree
find . -name '.env*' -not -path './node_modules/*' 2>/dev/null
# Check git history for accidentally committed secrets
git log -p --all -S 'GITHUB_TOKEN' --oneline 2>/dev/null | head -20

Deep dives: GhostCommit PNG injection · Zero sandbox credential leak · PreToolUse raw command leak

4. Git & data-loss blast radius

An agent that can git push --force can end your afternoon. The cheapest insurance is a checkpoint you control.

Commit or stash before any agent destructive step.
Watch background tasks for SIGKILL mid-write — they corrupt more than they report.
Never trust “done” without git status and a test run.
Protect main/master with branch protection so a force-push fails loudly.

The documented hazards: a background agent killed mid-write corrupted the git state (background SIGKILL + git corruption); an interrupt dropped in-progress work entirely (interrupt drops work).

# Before you let an agent loose, snapshot the tree
git stash push -u -m "pre-agent-$(date +%s)"
# After it finishes, see exactly what it touched
git status --short && git diff --stat

Deep dives: Background SIGKILL + git corruption · Silent work drop after interrupt

5. MCP, plugins, and supply chain

MCP servers and plugins are the fastest-growing attack surface because each one is a new process with its own network and tool surface — and you probably did not read its source.

Audit every MCP server: who built it, what network it can reach, what it writes.
Prefer read-only MCP for untrusted contexts.
Cap parallel tool calls if your agent has cross-wire bugs under load.
Pin plugin versions; treat a major-version bump like a code review.

The cross-contamination bug (MCP response cross-contamination) shows two tool calls leaking state into each other; the AWS Agent Toolkit MCP path (aws-agent-toolkit-claude-code-mcp) is a reminder that “official” servers still expand your egress footprint.

# Enumerate what MCP/plugin processes would be spawned
grep -rEi 'mcp|command:|args:' .mcp.json ~/.claude.json 2>/dev/null | head -40

Deep dives: MCP response cross-contamination · AWS Agent Toolkit / MCP

6. Network egress control

Even a “local” agent reaches the internet through package installs, MCP, and tool output fetches. Uncontrolled egress is how data leaves and how malicious packages arrive.

Default-deny outbound; allowlist package registries and API hosts only.
Run agents behind a proxy or firewall you can observe, not a raw laptop.
Watch for unexpected outbound connections during a build step.

This is the control that would have contained the credential-leak class of bugs: with no egress, an exfiltrating child process has nowhere to send the token.

7. Cost & model-routing integrity

Security is not only confidentiality — availability and billing integrity count. An agent that silently routes you to the wrong model, or retries forever, burns money and corrupts your assumptions about what you are paying for.

Log which model actually ran, not only which you selected.
Cap auto-retries after rate limits.
Alert on unexpected token burn.

Documented failures: a session that billed premium rates while running a cheaper model (silent-quota-model-burn); an agent that retried indefinitely against a token limit (indefinite auto-retry); token overhead differences between harnesses (claude-code-vs-opencode-token-overhead).

Deep dives: Silent quota / wrong model · Indefinite auto-retry · Token overhead Claude Code vs OpenCode

8. Operator discipline & incident response

Tooling fails; discipline is the backstop. These five habits prevent more incidents than any single flag.

Checkpoint git before every agent run. A stash is cheaper than a postmortem.
Read the plan before you approve. The 10 seconds of review beats the 2 hours of undo.
Reject any instruction the agent “remembers” that you did not give. Memory bleed is a signal, not a feature.
Rotate secrets the moment a session looked contaminated. Assume compromise; prove otherwise.
Follow the Beware tag weekly. New classes of failure land faster than any checklist can be rewritten.

If you suspect a leak, the response is mechanical: revoke the token at the provider, rotate it locally, purge it from shell profiles and .env, then re-run the env | grep check from Section 1 to confirm it is gone.

Printable one-page summary

Ran env | grep — no secret inherited by children
Sandbox verified real (not just toggled)
Auto-approve off; network default-deny
Git checkpoint taken before agent ran
MCP servers audited and read-only where untrusted
Model-ran logging on; retry cap set
Secrets rotated after any suspicious session

Last verified: August 2026. When a new security class appears, we add a Beware post and link it here. This page is the index; the linked deep dives carry the reproductions and fixes.

FAQ

Q1: Do I need to run the full checklist for every coding agent session?

No. The checklist is a setup-time and periodic audit tool. Run the env | grep command from Section 1 and the git checkpoint command from Section 4 before every session. The rest (MCP audit, sandbox verification, network egress) should be reviewed after major agent upgrades or monthly.

Q2: Is a “sandbox enabled” toggle in the agent config enough?

No. A config flag proves nothing. You must verify the sandbox actually scrubs environment variables, restricts filesystem access, and blocks network egress. Run the env | grep test from Section 1 — if it prints secrets you wouldn’t paste publicly, the sandbox is leaking.

Q3: Can I trust auto-approve if I’m careful about what I ask?

No. Prompt injection via images, READMEs, and tool output can coerce the agent into running destructive commands you never asked for. The GhostCommit PNG injection and PreToolUse raw command leak are real examples. Keep approval gates on for destructive actions.

Q4: What’s the single most common way secrets leak from coding agents?

Environment variable inheritance. The agent’s child process inherits your shell’s GITHUB_TOKEN, AWS_*, ANTHROPIC_API_KEY, etc. by default. The zero-sandbox-credential-leak is the canonical case: the sandbox protected filesystem and network but inherited every credential verbatim.

Q5: How do I protect against MCP server supply chain attacks?

Audit every MCP server before adding it: who built it, what network it reaches, what it writes. Prefer read-only MCP for untrusted contexts. Pin plugin versions. Treat a major-version bump like a code review. Enumerate your MCP configs with the command in Section 5.

Q6: What should I do if I suspect a secret was leaked during an agent session?

Immediate response: (1) Revoke the token at the provider (GitHub, AWS, Anthropic, etc.), (2) Rotate it locally, (3) Purge it from shell profiles and .env files, (4) Re-run env | grep from Section 1 to confirm it’s gone from child processes.

Q7: Is Windows safe for coding agents?

Windows has documented gaps: click-through UAC dialogs can silently grant denied permissions (windows-click-through-permissions), and Smart App Control can leave sandboxes effectively off (smart-app-control-sandbox-fail). If you must use Windows, verify isolation manually and consider WSL2 with a verified sandbox instead.

Q8: How often should I review this checklist?

After every major agent upgrade (e.g., Claude Code v2.1.x → v2.2.x), monthly for active operators, and whenever a new Beware post lands that maps to your stack.

Coding Agent Security Checklist 2026 — The Operator's Hardening Guide

New security coverage this cycle

Hermes-specific hardenings

The threat model, in one table

1. Sandbox & session isolation

2. Permissions: deny by default

3. Secrets & environment

4. Git & data-loss blast radius

5. MCP, plugins, and supply chain

6. Network egress control

7. Cost & model-routing integrity

8. Operator discipline & incident response

Printable one-page summary

FAQ

Get the AI Agent Cheat Sheet

Related articles

Related articles

New security coverage this cycle

Hermes-specific hardenings

The threat model, in one table

1. Sandbox & session isolation

2. Permissions: deny by default

3. Secrets & environment

4. Git & data-loss blast radius

5. MCP, plugins, and supply chain

6. Network egress control

7. Cost & model-routing integrity

8. Operator discipline & incident response

Printable one-page summary

Related pillars

FAQ

Get the AI Agent Cheat Sheet

Related articles