Agent Permission Matrix
Build tool allowlist and denylist configs for coding agents — safe defaults included.
.claude/settings.json permissions block
{
"permissions": {
"allow": [
"Read(*)",
"Write(*)",
"Edit(*)"
],
"ask": [
"Bash(*)",
"WebFetch(*)",
"Bash(curl:*)",
"Bash(git push:*)",
"Bash(npm install:*)",
"Bash(pip install:*)"
],
"deny": [
"Read(.env*)",
"Read(**/secrets/**)",
"Bash(security:*)"
]
}
}Plain-language policy summary
# Agent permission policy - **File read** — ALLOW: The agent may read any file in the workspace without asking. - **File write / edit** — ALLOW: The agent may create and edit workspace files freely. - **Shell execution** — ASK: Each shell command is shown to a human before it runs. - **Network access** — ASK: Each outbound network request requires approval. - **Git push** — ASK: Pushes require explicit human approval each time. - **Package install** — ASK: New dependencies require human review before install. - **Secrets access** — DENY: The agent never sees secret values. Deny rules take precedence over ask, which takes precedence over allow.
How it works
Work through seven capability categories — file reads, file writes, shell execution, network access, git push, package installs and secrets access — and assign each one allow, ask or deny. The tool generates a Claude Code settings.json permissions block plus a plain-language policy summary you can drop into your team docs, both ready to copy.
The three-level model matches how agent harnesses actually enforce policy. Allow is for operations whose worst case is cheap to undo: reading files, writing inside the workspace. Ask inserts a human at exactly the moments where judgment matters — before code leaves the machine, before the dependency tree changes, before a shell command touches anything outside the repo. Deny is for capabilities whose legitimate use is rare enough that blocking them outright costs less than reviewing requests. Most incidents trace back to a capability that was allowed when it should have been asked.
The presets encode three honest postures rather than a fake spectrum. Strict assumes the agent may be compromised by prompt injection at any time and bounds the damage accordingly — right for production-adjacent machines and regulated codebases. Balanced assumes a normal development workstation: frictionless edits, human checkpoints on external effects. Yolo is labeled what it is; it only makes sense inside a disposable sandbox with no credentials, where the worst case is throwing the container away. All three deny secrets, because no preset should normalize an agent reading credentials.
Treat the exported policy as a starting point, not a finished security program. Permission rules bound what the agent can do; they say nothing about what it should do, which belongs in your CLAUDE.md, or whether its inputs are trustworthy, which is the prompt-injection scanner's territory. Review the matrix whenever you add MCP servers or new tools — every new capability ships with a default of "nobody decided yet", and undecided is the most dangerous setting of all.
Frequently asked questions
What do allow, ask and deny actually mean?
Allow means the agent performs the action without stopping — appropriate for low-blast-radius operations like reading files. Ask pauses the agent and requests human approval for each invocation, the right default for anything with external effect like pushing commits or installing packages. Deny blocks the action entirely; the agent is told the tool is unavailable. The art is putting each capability in the cheapest bucket that still bounds your worst-case outcome.
Which preset should I start with?
Balanced, for most teams: it allows reads and workspace writes, asks on shell commands with side effects, git pushes and package installs, and denies secrets access. Strict is for regulated environments or agents running on production-adjacent machines — it asks for nearly everything and denies network and secrets outright. Yolo allows everything except secrets and is only defensible in a disposable sandbox like a container with no credentials mounted.
Why is secrets access denied in every preset?
Because it combines maximum blast radius with minimum legitimate need. An agent that can read .env files or keychain entries can leak credentials into logs, commit them, or — under prompt injection — exfiltrate them deliberately. Almost no coding task genuinely requires the agent to see secret values; tasks that touch configuration can use placeholder values and let a human fill in the real ones. If you must grant it, scope it to specific files and use ask mode.
How does the exported settings.json work in Claude Code?
Claude Code reads permission rules from settings.json under the permissions key, with allow, ask and deny arrays of tool-pattern strings — for example Bash(git push:*) matches any git push command. Deny takes precedence over ask, which takes precedence over allow. Place the file at .claude/settings.json for a project-scoped policy your whole team inherits via version control, or ~/.claude/settings.json for a personal global default.
Does a permission matrix protect against prompt injection?
It is the single most effective mitigation, but it limits damage rather than preventing injection. If a malicious instruction smuggled through a web page or tool output convinces the agent to act, the permission layer is what stands between 'the model wanted to' and 'it happened' — a denied network capability cannot exfiltrate, an ask-gated push cannot silently ship code. Combine it with input scanning and least-privilege credentials for defense in depth.
Turn this analysis into a live rule with the FORG rule engine — route models and enforce limits automatically.
Explore the rule engine