What you will be able to do
- Choose a Claude Code permission mode and rules that grant an agent the least authority it needs, and add hooks as a deterministic deny layer
- Store, rotate, scope and scan API keys, and keep credentials out of the agent's reach with a proxy
- Harden an agent's runtime for integrity and against exfiltration with sandboxing and container flags
- Reduce prompt and data leakage, and handle PII and PHI within ZDR and HIPAA-ready arrangements
1.Authorization: permission modes, rules and hooks
Authorization decides what an agent may do, and in Claude Code it is set with permission rules and modes. Allow rules let a tool run without approval, ask rules prompt for confirmation each time, and deny rules block the tool entirely. The mode sets what happens to everything the rules don't cover.
| Mode | Behavior |
|---|---|
| default (Manual) | Prompts for permission on first use of each tool |
| acceptEdits | Auto-accepts file edits and common filesystem commands in the working directories |
| plan | Reads files and runs read-only commands; doesn't edit source files |
| auto | No routine prompts; a background classifier checks actions against your request |
| dontAsk | Auto-denies anything that would prompt; pre-approved tools still run |
| bypassPermissions | Skips prompts, except for actions no mode auto-approves |
For a headless agent with a fixed toolset, dontAsk together with explicit allow rules gives deny-by-default behavior: anything not pre-approved is refused, not prompted. bypassPermissions works the other way and grants broad authority.
Know the limits of this layer. Claude Code parses Bash commands into an AST and matches them against your rules. Commands that can't be parsed cleanly, or that match no allow rule, require approval. The documentation is explicit that this is a permission gate and not a sandbox. Apart from a few built-in checks, it doesn't infer whether a command is dangerous from its target or effects.
Hooks add a deterministic policy layer in your own code. A PreToolUse hook can return permissionDecision: "deny" to block a tool call, and the reason is shown to Claude. A hook can't override your configuration, though: deny and ask rules are still evaluated whatever the hook returns.
Checkpoint 1 of 6· Exam question
A team is deploying an agent that processes untrusted third-party documents and has access to internal APIs that can send emails and transfer funds. To limit the damage a successful prompt injection could cause, what should the team do when configuring the agent's capabilities?
Correct answer: A — Apply the principle of least privilege by scoping the agent's tool access narrowly, excluding secrets and sensitive actions it does not need for the task
- A. Correct. Limiting an agent's access to sensitive data and actions under the principle of least privilege is the recommended way to reduce the blast radius of a successful injection.
- B. Incorrect. Broad, unscoped access maximizes rather than minimizes the damage a successful injection can cause and contradicts least-privilege guidance.
- C. Incorrect. A shared administrator-level account is the opposite of least privilege and gives any successful injection maximum reach across systems.
- D. Incorrect. Removing all automation defeats the purpose of building the agent; the guidance is to scope access narrowly, not eliminate it entirely.
Checkpoint 2 of 6· Check yourself
A PreToolUse hook returns permissionDecision "allow" for a Bash command that matches a deny rule in settings. What happens?
Hooks add policy on top of permission rules but can't override them. Deny and ask rules are evaluated regardless of the hook's decision.
“Deny and ask rules are still evaluated regardless of what the hook returns”Source: code.claude.com
2.Authentication and secrets: keys out of code and out of reach
An API key is how your application authenticates. If it leaks, someone else can authenticate as you. Anthropic's API key guidance says to load the key from the environment, never from a hard-coded string. In the cloud, use your hosting provider's mechanism for injecting environment variables.
Checkpoint 3 of 6· Fill the gap
Which call completes this sample so the key is read from the environment, not from source code?
from dotenv import load_dotenv
import os
load_dotenv()
my_api_key = os. ? ("ANTHROPIC_API_KEY")os.getenv reads ANTHROPIC_API_KEY from the environment that load_dotenv populated, so the key never appears in the code.
Source: support.claude.comThe same guidance covers the rest of a key's life. Rotate keys on a consistent schedule, for example every 90 days, by creating new ones and deactivating the old ones. Separate keys for development, testing and production, so a compromised key can be disabled without affecting the other environments. Scan repositories for committed secrets: turn on your source-control provider's secret scanning, use tools such as Gitleaks, and add scanning to CI/CD so secrets are caught before they reach the main branch. Claude Code stores its own API keys and tokens in the macOS Keychain where available, and protects them with file permissions on Windows and Linux.
For agents, the stronger pattern is to keep credentials out of the agent entirely. In the Agent SDK deployment guidance, a proxy outside the agent's container injects credentials. The agent never sees them, the proxy enforces an endpoint allowlist and logs every request, and credentials live in one secure place instead of being copied to each agent. Don't mount credential files into the agent's filesystem either.
| File | Risk |
|---|---|
| .env, .env.local | API keys, database passwords, secrets |
| ~/.aws/credentials | AWS access keys |
| ~/.kube/config | Kubernetes cluster credentials |
| .npmrc, .pypirc | Package registry tokens |
| *.pem, *.key | Private keys |
Checkpoint 4 of 6· Check yourself
One key is used across dev, test and production, and it leaks from a test machine. Which practice would have limited the damage most directly?
Keys scoped per environment let you disable only the affected use case. A shared key forces you to revoke production access too.
“use different API keys for development, testing, and production environments”Source: support.claude.com
3.Integrity and exfiltration: isolating the runtime
Permission rules decide what Claude may attempt. Isolation decides what it can actually reach, which protects the integrity of your systems and closes off exfiltration paths. The Agent SDK guidance offers a range of options. The sandbox runtime has secure defaults and very low overhead. Containers depend on how you set them up. gVisor and VMs give excellent isolation when configured correctly, at a higher cost. A hardened container drops capabilities, makes the root filesystem read-only, removes networking, and mounts code read-only:
docker run \
--cap-drop ALL \
--security-opt no-new-privileges \
--security-opt seccomp=/path/to/seccomp-profile.json \
--read-only \
--tmpfs /tmp:rw,noexec,nosuid,size=100m \
--tmpfs /home/agent:rw,noexec,nosuid,size=500m \
--network none \
--memory 2g \
--cpus 2 \
--pids-limit 100 \
--user 1000:1000 \
-v /path/to/code:/workspace:ro \
-v /var/run/proxy.sock:/var/run/proxy.sock:ro \
agent-imageWith --network none, the agent's only route out is the mounted proxy socket. Domain allowlists have limits too. The sandbox proxy matches on the client-supplied hostname and doesn't inspect TLS. If the agent holds permissive credentials for an allowed domain, make sure it can't use that domain to trigger other requests or exfiltrate data. For audit integrity, Claude Code cloud sessions log every operation for compliance and audit purposes.
Checkpoint 5 of 6· Check yourself
A team has detailed allow and deny rules for Bash and concludes the agent is now sandboxed. What is wrong with that conclusion?
The parser matches commands against rules but doesn't judge danger from targets or effects. Isolation comes from the environment.
“This is a permission gate, not a sandbox”Source: code.claude.com
4.Confidentiality and privacy: prompt leaks, PII and PHI
Prompt leakage exposes material you expected to stay hidden in your prompt. Anthropic's guidance lists several ways to reduce it. Separate context from queries by keeping key information in the system prompt. Post-process Claude's outputs with regular expressions or keyword filters. Audit prompts and outputs regularly. Most effectively, leave out proprietary details Claude doesn't need for the task. Two cautions apply. Leak-proofing adds complexity that can degrade task performance, so use it only when it's really needed. And the older technique of prefilling the Assistant turn to restate instructions isn't supported on Claude 4.6 and later models.
PII and PHI. Protected health information is any individually identifiable health information. It usually appears in message content, attached files, and file names or metadata. Organizations handling PHI should use HIPAA readiness (a signed BAA plus a HIPAA-enabled organization). The API then rejects non-eligible features with a 400 error. One detail is easy to miss: JSON schemas used with structured outputs or strict: true tools are compiled and cached separately, without PHI protections. Never put patient data in schema property names, enum values, const values or patterns. Claude Code isn't covered under HIPAA readiness.
Retention. Under zero data retention (ZDR), Anthropic doesn't store prompts or responses at rest after the API response is returned. Data that Anthropic does retain is never used for training without your express permission. An organization handling PHI doesn't also need ZDR.
Checkpoint 6 of 6· Check yourself
A HIPAA-enabled app uses structured outputs. A developer adds patient names as enum values in the JSON schema to constrain extraction. Why is this a problem?
Schema grammars are cached outside the protected message content, so PHI belongs only in prompts and responses.
“These cached schemas do not receive the same PHI protections as prompts and responses.”Source: platform.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Claude Code's AST-based command parsing works as a sandbox that blocks dangerous commands.Why is that wrong?
It only matches commands against permission rules. Filesystem and network isolation come from sandboxing, containers or VMs.
Covered in Integrity and exfiltration: isolating the runtime
2.A PreToolUse hook returning "allow" overrides any deny rule in settings.Why is that wrong?
Hooks can add a deny, but configured deny and ask rules are still evaluated whatever the hook returns.
3.Prefilling the Assistant turn to restate "never reveal X" is a current prompt-leak mitigation on every model.Why is that wrong?
Prefilling isn't supported on Claude 4.6 and later models. Rely on separating context, filtering outputs and leaving out unneeded details.
Covered in Confidentiality and privacy: prompt leaks, PII and PHI
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/permissionsOfficial docs
“Auto-denies every call that would otherwise prompt”
↩︎ Authorization: permission modes, rules and hooks - 2.
“Commands that cannot be parsed cleanly, or that do not match an allow rule, require explicit approval.”
↩︎ Authorization: permission modes, rules and hooks“The agent never sees the actual credentials”
↩︎ Authentication and secrets: keys out of code and out of reach“ensure it cannot use that domain to trigger other network requests or to exfiltrate data”
↩︎ Integrity and exfiltration: isolating the runtime“This is a permission gate, not a sandbox”
↩︎ Exam trap 1“This is a permission gate, not a sandbox”
↩︎ Checkpoint - 3.https://code.claude.com/docs/en/hooksOfficial docs
“"deny" prevents the tool call.”
↩︎ Authorization: permission modes, rules and hooks“Deny and ask rules are still evaluated regardless of what the hook returns”
↩︎ Exam trap 2“Deny and ask rules are still evaluated regardless of what the hook returns”
↩︎ Checkpoint - 4.https://support.claude.com/en/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secureOfficial docs
“Regularly rotate your API keys on a consistent schedule (for example, every 90 days) by creating new ones and deactivating old ones.”
↩︎ Authentication and secrets: keys out of code and out of reach“Regularly check your source control repositories for accidentally committed secrets.”
↩︎ Authentication and secrets: keys out of code and out of reach“use different API keys for development, testing, and production environments”
↩︎ Checkpoint - 5.https://code.claude.com/docs/en/securityOfficial docs
“API keys and tokens are stored in the macOS Keychain when available”
↩︎ Authentication and secrets: keys out of code and out of reach“All operations in cloud sessions are logged for compliance and audit purposes”
↩︎ Integrity and exfiltration: isolating the runtime - 6.https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-prompt-leakOfficial docs
“Filter Claude's outputs for keywords that might indicate a leak.”
↩︎ Confidentiality and privacy: prompt leaks, PII and PHI“prefilling is not supported on Claude 4.6 and later models”
↩︎ Exam trap 3 - 7.
“Do not include PHI in JSON schema definitions.”
↩︎ Confidentiality and privacy: prompt leaks, PII and PHI“Under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned.”
↩︎ Confidentiality and privacy: prompt leaks, PII and PHI“These cached schemas do not receive the same PHI protections as prompts and responses.”
↩︎ Checkpoint