AI Coding Security: Best Practices for Claude Code (2026)

verify command names and permission modes against the Claude Code docs before you rely on them.

Why AI coding needs a different security mindset

Old-school autocomplete only suggested text. An AI coding agent like Claude Code is a fundamentally different beast: it reads your whole repo, runs real shell commands, edits files, and calls external tools (MCP, web fetch, GitHub). Stack those three capabilities together and you get an attack surface that traditional linting and code review were never designed to catch.

The easiest way to picture it - borrowed from a Backslash Security analysis (Sept 18, 2025) - is to treat the agent as "a very fast intern with root access." This intern types code ten times faster than you, but it can also rm -rf the wrong directory, paste an API key into a commit, or dutifully follow a "command" hidden inside a GitHub issue it just read. It is not malicious; it simply lacks context about what is dangerous.

The key insight: the risk is not that "AI writes bad code." The risk lives in privileges (what the agent can do on your machine) and in trust of input (who the agent believes). So the right security strategy is not "read every suggested line carefully" - it is building systematic guardrails: limit privileges, isolate the environment, control data in and out, and always keep a human in the final decision loop. The rest of this article is how to do each layer, one at a time.

The 6 main security risks of AI coding

Before you patch anything, you need to know what you are defending against. Here are the six risk categories you hit most often in practice, each with a concrete scenario:

These six risks map almost one-to-one onto the six best practices below. You do not have to do everything at once - but if you skip a layer, know exactly which risk you are accepting.

Best practice 1 - Manage secrets and sensitive data

Root principle: a secret should not exist anywhere the agent can read it in plaintext. There are four layers of defense, from cheap to solid:

1. Keep secrets out of the repo. Keep .env out of Git with .gitignore, and prefer a secret manager (Vault, Doppler, 1Password CLI, your CI's environment variables) over flat files. You should do this even without AI - AI just makes the fallout worse.

2. Keep sensitive files out of the agent's context. The approach in the Claude Code security docs is to use permissions.deny with a Read() rule in .claude/settings.json - the agent will not be allowed to read files matching the pattern:

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

(Some older guides mention a .claudeignore file. If your CLI version still supports it, great, but permissions.deny with Read() is the approach the official docs recommend.)

3. Automated secret scanning. Do not trust the human eye. Wire gitleaks (or git-secrets, TruffleHog) into a pre-commit hook and CI to block any commit containing a key before it ever leaves your machine:

# pre-commit: block the commit if a secret is detected
gitleaks protect --staged --redact --verbose

4. Rotate when something leaks. If a key has made it into context or a commit, treat it as permanently compromised - deleting the commit is not enough, because the key may already be in logs/model/history. The right procedure: revoke the old key -> issue a new one -> update the secret manager -> check access logs for anomalies. Prepare a rotation runbook before you need it.

Best practice 2 - Control permissions and run in a sandbox

This is the highest-ROI layer. Claude Code has several permission modes that decide what the agent may do on its own:

A blunt warning: bypassPermissions (and the --dangerously-skip-permissions flag) is exactly what it sounds like - dangerous. The word "dangerously" in the name is deliberate. Never turn it on where you have real secrets, prod access, or client repos. If you need to run the agent unattended (batch jobs, CI), do it inside a sandbox, not on your main machine.

In settings.json, apply least-privilege: allow the safe stuff by default, ask for anything risky, and deny outright what should never run on its own. A paste-and-go template:

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

Isolate with a container. The strongest way to cap the blast radius is to run the agent inside a devcontainer/Docker - mount only the directories it needs, cut off unnecessary network access, and keep prod credentials out. Even if the agent gets prompt-injected and runs a bad command, it can only trash the box, not your machine. For a deeper dive into permission configuration, see the guide on configuring Claude Code permissions safely.

Best practice 3 - Block prompt injection and untrusted content

Prompt injection is the most distinctive and most underrated risk. The mechanism: the agent does not cleanly distinguish between your instructions and the data it reads. If that data contains an imperative sentence, the agent may treat it as a task to perform.

Common sources of untrusted content:

• Issues / PRs / comments on GitHub written by outsiders.
• Web pages the agent fetches when you ask it to "read the docs at this URL."
• Output from an MCP server or a third-party tool.
• Files in a repo you just cloned but haven't read yet.

Four mitigation principles, no fancy theory required:

1. No auto-approve when handling outside input. The moment the agent starts reading an issue/web page/MCP output, switch back to asking step by step - don't leave acceptEdits/bypass running.
2. Use plan mode with unfamiliar sources. Let the agent read and propose, but block execution until you approve.
3. Isolate. Handle untrusted data in a secret-free sandbox, as in best practice 2.
4. Be wary of "polite commands." If some output suddenly "suggests" the agent run a command, install a package, or read an unfamiliar file - stop and read closely. That is a classic injection tell.

Anthropic's security docs have a dedicated section on defending against prompt injection; the general principle is to keep the agent in the lowest-privilege mode possible whenever it touches data you don't control.

Best practice 4 - Always review AI-generated code

The non-negotiable rule: never merge AI code without a human in the loop. The high speed of code generation makes it easy to slip into "blind merging" - and that is where the most vulnerabilities reach production.

The subtle problem is AI slop: code that looks polished, has nice variable names, has comments, and runs on the happy path - but skips input validation, leaves an SQL injection open, hardcodes values, or mishandles a security edge case. It "looks right," so it slips past a rushed reviewer. For how to spot and avoid it, see avoiding AI slop when reviewing code.

A practical review workflow:

1. Read the diff, not the description. The agent saying "added validation" does not mean it did it right. Verify in the diff.
2. Run /security-review - Claude Code's built-in security review command - to quickly scan for common vulnerabilities (injection, hardcoded secrets, missing auth) before you review by hand.
3. Prioritize sensitive areas: authentication, authorization, user input handling, DB queries, shell commands, file operations.
4. Run tests and your linter/SAST like any other PR - AI does not excuse you from CI.

For projects that need more rigor, set up a full security audit workflow for Claude Code that runs on a schedule, not just ad hoc.

Best practice 5 - Vet MCP servers, plugins, and use hooks as guardrails

Every MCP server or plugin you enable is third-party code running with the agent's privileges. A "convenient" but malicious server can read files, make network calls, and exfiltrate data without you seeing it. The principles:

• Only enable trusted servers - prefer official sources with public source you can read.
• Read the source before installing lesser-known servers, especially ones with broad network or file access.
• Least-privilege for MCP just like for Bash - grant only the scope actually needed.

To understand how MCP works before you vet it, read what MCP is and how it works.

A PreToolUse hook as the last-line guardrail. This is an underused but very powerful layer: the hook runs before the agent executes a tool, and it can block outright. For example, blocking dangerous command patterns:

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Read the JSON payload from stdin, block dangerous commands
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Blocked: dangerous command rejected by guardrail." >&2
 exit 2 # a non-zero exit code => Claude Code cancels the action
fi
exit 0

Register this hook for the PreToolUse event in settings.json. The advantage over relying on deny alone: a hook allows dynamic logic (regex, variable checks, logging), and it is a safety net even if you accidentally enable a loose mode.

The AI coding security checklist (copy and use now)

All the best practices folded into an actionable list. Print it out or paste it into your project README:

1. [ ] Secrets: .env in .gitignore, use a secret manager, no plaintext keys in the repo.
2. [ ] Deny reads: permissions.deny blocks Read() for .env, *.pem, *.key, and secrets directories.
3. [ ] Scanning: gitleaks (or equivalent) runs at pre-commit and in CI.
4. [ ] Rotation: a runbook exists to revoke + reissue keys when one leaks.
5. [ ] Permissions: settings.json follows least-privilege (allow/ask/deny), no bypassPermissions outside a sandbox.
6. [ ] Sandbox: risky tasks run in Docker/devcontainer with no prod credentials.
7. [ ] Prompt injection: switch to plan/ask mode when handling issues, web fetches, or MCP output.
8. [ ] Review: read the diff + run /security-review + CI/SAST before merging, never merge blind.
9. [ ] MCP/plugin: only enable trusted servers whose source you've read, granted minimal scope.
10. [ ] Hooks: a PreToolUse guardrail blocks destructive commands.

The real limits, and when NOT to hand it to AI

To be honest: every guardrail above reduces risk, it does not erase it. A few limits worth stating plainly.

AI does not replace human threat modeling. It doesn't understand your business context, how sensitive your data is, or the legal fallout of a leak. The decision "is this safe to automate" is still yours.

Don't let the agent touch prod or real secrets. Don't connect the agent to a production database, don't grant credentials with infra write access, and don't let it deploy freely. Mistakes here are not recoverable.

Approval fatigue is a real risk. When permission prompts show up too often, people start clicking "allow" reflexively - defeating the very defense they set up. The fix: tune allow for the operations that are genuinely safe so prompts only appear for things worth considering, instead of turning them all off to stop the nagging.

In short: use AI to move fast, but keep the irreversible decisions in human hands. Guardrails exist so you can move fast with confidence, not so you can stop thinking.

Standardize security with a prebuilt kit

Writing every PreToolUse hook, every settings.json template, and every review skill from scratch for each project gets tedious - especially when you want a whole team on the same standard. One time-saver is a prebuilt kit that packages security-review skills and guardrail workflows for Claude Code. The AgentKit kit for Claude Code bundles a set of review/workflow skills so you don't rebuild from zero; if you want to see whether it fits, you can check AgentKit pricing (20% off via link) (Engineer Kit $99, the site lists no recurring fee, with lifetime updates). You should still read and adapt it to your project - no kit replaces understanding your own threat model.

Frequently asked questions (FAQ)

Is AI coding safe to use on real projects?

Yes, if you build the right guardrails: keep secrets out of reach, enforce least-privilege permissions, run in a sandbox, and review all code before merging. The risk comes from overly broad privileges and untrusted input, not from using AI itself. Without guardrails the risk is high; with them, it is controllable.

Does Claude Code send my code anywhere?

Claude Code sends the context it needs to Anthropic's API for processing - that is how it works. To limit exposure, use permissions.deny to block reading sensitive files, check the data retention policy in Anthropic's docs, and for extremely sensitive code, isolate it in a dedicated environment.

How do I stop API keys leaking through the agent?

Three layers: (1) no plaintext keys in the repo, use a secret manager; (2) permissions.deny to block Read() on .env and key files; (3) gitleaks at pre-commit and in CI to block commits containing secrets. If one does leak, revoke and rotate immediately - deleting the commit is not enough.

Should I enable bypassPermissions?

Almost never, on a real work machine. bypassPermissions and --dangerously-skip-permissions remove every approval layer - use them only in an isolated sandbox with no secrets or prod access. For everyday work, keep default; tune allow to reduce prompts instead of turning them all off.

How much review is enough for AI code?

Read the diff instead of trusting the agent's description, run /security-review, run CI/SAST and tests like any PR, and scrutinize sensitive areas (auth, input, DB, shell). Watch out for AI slop - code that looks right but skips validation or gets a security edge case wrong.

Is AI coding okay on client (NDA) projects?

Only if the contract permits it and you isolate tightly: a separate workspace per client, never open the agent over a directory holding another client's code, no real credentials in scope, and check the NDA terms about sending data to third-party services before you start.

Conclusion and next steps

AI coding security is not a feature you toggle on or off - it is six layers of guardrails: secrets, permissions, sandbox, blocking prompt injection, code review, and vetting MCP + hooks. Start with the two highest-ROI layers - permissions.deny for secrets and least-privilege settings.json - then add the rest over time. Paste the checklist above into your project README so the whole team follows one standard.

Read next: configuring permissions safely and a full security audit. If you want a ready-made security skill set for the whole team, you can give AgentKit a try (20% off via link) - but always read and adapt it to your own threat model.