What you will be able to do
- Write allow, ask and deny permission rules and predict which commands a wildcard matches
- Choose a permission mode that puts human approval where the risk is
- Configure sandbox filesystem, network and credential isolation so that a successful injection has limited reach
- Identify the audit and monitoring controls available for agent activity
1.Least privilege through permission rules
Screening and prompt design make an attack less likely to succeed. Access controls limit the harm it can do when it does succeed. Anthropic's guidance is to "Apply the principle of least privilege so that a successful injection can do minimal damage". In practice: keep secrets away from the agent unless it needs them, sandbox tools, and scope permissions as narrowly as possible. Claude Code shows how this works in practice.
Claude Code has three kinds of permission rule. Allow rules let a tool run without manual approval. Ask rules "prompt for confirmation whenever Claude Code tries to use the specified tool." Deny rules "prevent Claude Code from using the specified tool." A rule can name a whole tool (Bash, WebFetch, Read) or one specific use of it (Bash(npm run build), Read(./.env), WebFetch(domain:example.com)).
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)"
]
}
}Wildcards are where least privilege most often breaks down. A * stands in for whatever text sits in its position, so where you put it decides how much the rule grants. In Bash(git * main), "it stands in for the subcommand, so Claude Code matches every git subcommand and every option before it". That includes -c, which makes git run a program you name. Spacing matters too: "The space before a trailing * is part of the rule."
| You write | Matches | Doesn't match |
|---|---|---|
| Bash(npm run build) | npm run build | npm run build --watch |
| Bash(npm run *) | npm run build, npm run test --watch, npm run | npm install |
| Bash(git * main) | git merge main, git push origin main, git -c core.fsmonitor=<script> diff main | git log |
| Bash(ls *) | ls -la, ls | lsof |
| Bash(ls*) | ls -la, lsof | (none listed) |
Checkpoint 1 of 5· Fill the gap
Which key makes Claude Code refuse git pushes outright, rather than prompting for them?
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
" ? ": [
"Bash(git push *)"
]
}
}Deny rules prevent the tool use entirely. Ask rules only require confirmation, and block is not a permission rule type.
Source: code.claude.com2.Permission modes: where the human sits in the loop
Rules cover specific tools. The permission mode sets the default level of human oversight for everything else. Each mode hands approval to someone different: a person, a classifier, or nobody.
| Mode | Who approves actions |
|---|---|
| default (Manual) | A human: Claude Code prompts for permission on first use of each tool |
| acceptEdits | File edits and common filesystem commands in the working directory are accepted automatically; other actions still prompt |
| plan | Claude reads files and runs read-only shell commands to explore, without editing source files |
| auto | No routine prompts; a background classifier checks actions such as shell commands and network requests against your request |
| dontAsk | Nobody: anything that would prompt is denied automatically, while pre-approved tools still run |
| bypassPermissions | Skips prompts, except for the actions no mode auto-approves |
Manual mode adds safeguards on top of the prompts. "Fail-closed matching: In Manual mode, unmatched commands require approval by default". So when no rule matches, a person reviews the action before it runs. An allowlist can't be used to slip a command past review either, because "suspicious bash commands require manual approval even if previously allowlisted." Commands that fetch from the network, such as curl and wget, are not auto-approved by default. First-time codebase runs and new MCP servers require trust verification. That check is disabled when Claude Code runs non-interactively with -p.
Prompting too often has its own risk: people start approving without reading. Claude Code addresses this by letting you allowlist frequently used safe commands per user, per codebase or per organisation. Prompts are then reserved for the actions that need judgement.
Checkpoint 2 of 5· Match them up
Match each permission mode to its behaviour.
Tap a term, then the definition that fits it.
The modes differ in who makes the approval decision: a human, a classifier, an automatic accept for a fixed scope, or an automatic deny.
“a background classifier checks that they align with your request”Source: code.claude.com
3.Sandboxing and credential protection
Permission rules filter on command text. The sandbox works at the operating-system level. Claude Code's sandboxed Bash tool runs commands "with filesystem and network isolation, reducing permission prompts while maintaining security." On Linux, bubblewrap enforces filesystem isolation and socat routes network traffic through the sandbox proxy. For the network, allowedDomains lists the hosts the proxy will connect to.
Filesystem rules let you open a region and then close part of it again. With allowRead: ["~/"] and denyRead: ["~/.env"], the secret stays blocked: "The deny holds inside a wider allow". A narrower allow can also re-open part of a denied region, for example denyRead: ["~/"] with allowRead: ["~/projects"]. The sandbox and permission rules also interact. Explicit deny rules are always respected, and content-scoped ask rules such as Bash(git push *) still prompt even for sandboxed commands. Watch one default: autoAllowBashIfSandboxed is true, so sandboxed commands run without prompting unless you change it.
Secrets get their own controls. A deny entry stops sandboxed commands from reading a credential file or seeing an environment variable at all. A mask entry lets tools keep working without exposing the value. On Linux and WSL2, "sandboxed commands read a sentinel copy of the file, a stand-in whose secret is replaced with a placeholder value", and the proxy substitutes the real value on egress.
Control over who can change these settings is a guardrail in its own right. Only some sources can turn filesystem isolation off: "User settings, managed settings, and the --settings CLI flag can set it." Project settings cannot, so a repository you check out cannot disable your isolation. Claude Code also applies none of the credentials entries in project or local settings.
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" },
{ "name": "NPM_TOKEN", "mode": "deny" }
]
}
}
}Checkpoint 3 of 5· Check yourself
A sandbox config has "allowRead": ["~/"] and "denyRead": ["~/.env"]. What can sandboxed commands read?
A deny inside a wider allow still applies, so a broad allow cannot accidentally re-expose a secret.
“The deny holds inside a wider allow”Source: code.claude.com
4.Audit, monitoring and organisational enforcement
Guardrails need oversight after deployment too. Claude Code documents several platform controls for cloud sessions. Each session runs in an isolated, Anthropic-managed VM. Network access is limited by default. Git pushes are restricted to the current working branch. And "All operations in cloud sessions are logged for compliance and audit purposes."
For teams, Anthropic recommends several governance practices. "Use managed settings to enforce organizational standards". Share approved permission configurations through version control. Review them regularly with /permissions. Monitor usage through OpenTelemetry metrics. Use ConfigChange hooks to audit or block settings changes during a session. Managed settings also keep administrator restrictions in place: when managed settings configure sandbox.filesystem, only managed settings can set the key that turns filesystem isolation off.
Human review still matters as well. Review suggested commands before approving them, check proposed changes to critical files, and avoid piping untrusted content directly to Claude.
Checkpoint 4 of 5· Check yourself
A security lead wants to detect, and if necessary block, any attempt to change Claude Code's settings during a session. Which control does the security guidance point to?
ConfigChange hooks can audit or block settings changes during a session. OpenTelemetry tracks usage, and /permissions is for reviewing the configuration.
“Audit or block settings changes during sessions with ConfigChange hooks”Source: code.claude.com
Checkpoint 5 of 5· Exam question
An agent ingests inbound customer emails as tool results and drafts replies on the user's behalf. A red-team exercise crafts an email body containing text designed to close out the surrounding context and inject a new instruction telling the agent to forward the user's contact list. The way the email body is concatenated into the tool result lets the crafted text escape into an instruction context. Which change most directly closes this specific escape route?
Correct answer: D — Wrap the email body inside a JSON object in the tool result, so the untrusted text is delimited as an escaped string rather than concatenated free-form text
- A. Incorrect. Placing untrusted content in the system prompt raises its authority rather than containing it, which is the opposite of the recommended handling for untrusted content.
- B. Incorrect. Manual retyping by the user is not a scalable technical control and does not address the underlying concatenation mechanism that allows the escape.
- C. Incorrect. A larger context window changes how much history is retained, but does not prevent crafted text from escaping into an instruction context.
- D. Correct. JSON-encoding untrusted content provides unambiguous delimiters, so an attacker cannot close a quote or tag within the payload to break out into an instruction context.
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Bash(ls *) and Bash(ls*) are two equivalent ways to allow the ls command.Why is that wrong?
The space before a trailing * is part of the rule. Bash(ls*) also matches lsof, while Bash(ls *) does not.
Covered in Least privilege through permission rules
2.Denying curl and wget in permissions.deny is enough to enforce network restrictions.Why is that wrong?
Deny rules match command text only. Network enforcement that doesn't depend on how a command is written comes from sandbox network isolation.
Covered in Sandboxing and credential protection
3.A cloned repository's .claude/settings.json can turn off filesystem isolation for anyone who opens it.Why is that wrong?
Only user settings, managed settings and the --settings CLI flag can set the key that disables filesystem isolation. Project settings cannot.
Covered in Sandboxing and credential protection
Practise it for real
Start Claude Code with a strict sandbox and confirm that sandboxed commands cannot read a credential file.
1.On Ubuntu or Debian, install the sandbox dependencies with sudo apt-get install bubblewrap socat. On Fedora, use sudo dnf install bubblewrap socat.
Why: bubblewrap enforces filesystem isolation, and socat routes network traffic through the sandbox proxy.
You should see: Both packages are installed.
2.In ~/.claude/settings.json, add a sandbox.credentials.files entry: { "path": "~/.aws/credentials", "mode": "deny" }.
Why: Deny entries in user settings still apply, whereas credentials entries in project settings are ignored.
You should see: Your user settings contain the credentials block shown on this page.
3.Launch claude --settings '{"sandbox": {"enabled": true, "allowUnsandboxedCommands": false}}'.
Why: Setting allowUnsandboxedCommands to false stops commands that fail under the sandbox from falling back to running unsandboxed.
You should see: Claude Code starts with the sandbox enabled.
4.Run /sandbox and open Config.
Why: Config shows the resolved sandbox settings.
You should see: The sandbox shows as enabled, and the ~/.aws/credentials deny entry is listed.
5.Ask Claude to read ~/.aws/credentials with a Bash command.
Why: This is a small red-team test of the guardrail.
You should see: The sandboxed command cannot read the file.
Stuck? Get a nudge
If the read succeeds, check in Config whether filesystem isolation is disabled. A deny read block belongs to the filesystem layer and is not enforced when isolation is off.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaksOfficial docs
“Apply the principle of least privilege so that a successful injection can do minimal damage”
↩︎ Least privilege through permission rules - 2.https://code.claude.com/docs/en/permissionsOfficial docs
“Deny rules prevent Claude Code from using the specified tool.”
↩︎ Least privilege through permission rules“it stands in for the subcommand, so Claude Code matches every git subcommand and every option before it”
↩︎ Least privilege through permission rules“Skips permission prompts, except for the actions no mode auto-approves”
↩︎ Permission modes: where the human sits in the loop“The space before a trailing * is part of the rule.”
↩︎ Exam trap 1“a background classifier checks that they align with your request”
↩︎ Checkpoint - 3.https://code.claude.com/docs/en/securityOfficial docs
“Fail-closed matching: In Manual mode, unmatched commands require approval by default”
↩︎ Permission modes: where the human sits in the loop“suspicious bash commands require manual approval even if previously allowlisted”
↩︎ Permission modes: where the human sits in the loop“Sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security.”
↩︎ Sandboxing and credential protection“All operations in cloud sessions are logged for compliance and audit purposes”
↩︎ Audit, monitoring and organisational enforcement“Use managed settings to enforce organizational standards”
↩︎ Audit, monitoring and organisational enforcement“A deny rule matches the command as written”
↩︎ Exam trap 2“A deny rule matches the command as written”
↩︎ Prediction“Audit or block settings changes during sessions with ConfigChange hooks”
↩︎ Checkpoint - 4.https://code.claude.com/docs/en/sandboxingOfficial docs
“sandboxed commands read a sentinel copy of the file, a stand-in whose secret is replaced with a placeholder value”
↩︎ Sandboxing and credential protection“Explicit deny rules are always respected”
↩︎ Sandboxing and credential protection“User settings, managed settings, and the --settings CLI flag can set it.”
↩︎ Exam trap 3“The deny holds inside a wider allow”
↩︎ Checkpoint