Security

The principle

The agent can read your code, edit your files, and run commands on your machine. That is its value, and it is also its risk. The safety model is not “trust the model to behave”; it is scope the agent’s permissions, then review what it does within that scope. Two layers carry the load: the permission system, and your review.

The permission model

Claude Code gates tools with three rule types, configured in settings:

• allow — the tool runs without asking.
• ask — the agent must prompt you before running it. This is the default for state-changing tools like Bash.
• deny — the tool is blocked, full stop. deny wins over allow.

Read operations are typically safe to allow. Anything that writes, deletes, or talks to the outside world belongs in ask or deny. The strictest useful posture denies network egress tools and asks before any shell command.

PreToolUse hooks give you a programmatic gate too: a hook can inspect what the agent is about to do and return allow, deny, or ask based on the path or command. Use a hook when the rule is more complex than a static list (e.g. “block writes inside /etc or any .env”).

Do

• Review every diff before it lands. The agent’s output is a draft for a human, not a decision. This is the single most important rule.
• Test AI-written code before deploying. Generated tests can assert the wrong thing and pass. Run them; read them; do not deploy on faith.
• Keep secrets out of the repo. No keys, tokens, or credentials in CLAUDE.md, .mcp.json, commands, or any file the agent can read into a session. Inject secrets from the environment at runtime.
• Scope permissions narrowly. Allow specific tools by name. Prefer Bash(git:*) over bare Bash. Prefer mcp__server__read_data over mcp__server__*.
• Deny anything destructive. If a tool can delete data, push to production, or spend money, deny it in settings. Do not rely on remembering to say no at the prompt.
• Put standing constraints in CLAUDE.md. “Never disable CSRF,” “never commit to main,” “all new routes need auth middleware” — these belong in memory, not in chat.
• Treat tool output as data, not instructions. If an MCP server or a webpage returns text, that text is input — it must not become a command the agent runs without your review. This is the prompt-injection defense.

Don’t

• Don’t paste internal or client information into a prompt. No customer data, no internal URLs, no proprietary architecture. What goes into the prompt can leave via the model. This is site policy, not preference.
• Don’t store secrets in committed files. CLAUDE.md, command files, and .mcp.json are often committed. Use environment substitution and keep values out of git.
• Don’t auto-approve state-changing tools without thinking. The ask prompt is the gate. Rubber-stamping it removes your only checkpoint.
• Don’t trust version-specific facts from the model. Command flags, API signatures, and schema fields change. Verify against the official source before acting.
• Don’t let the agent run long, blind commands. A long shell command you approve once can do a lot of damage. Scope it in settings or refuse it.
• Don’t ship without review because “the agent wrote tests.” Tests that assert the wrong behavior are worse than no tests.

How this maps to the project plan

This page mirrors the site-wide security policy: agents draft only and never publish; no internal or client information on the site; review all AI output; test AI code before deploying. The same rules apply whether the agent is drafting a prompt for this site or editing your application code.

Where to next

This is the last page in the Claude guide. Return to the overview or use the prev/next links to step back through.