What you will be able to do
- Reduce system-prompt leakage without hurting task performance
- Apply least privilege, fail-closed permissions and credential isolation to protect authorization, authentication, confidentiality and integrity
- Pick the right data-handling arrangement (ZDR or HIPAA readiness) for personal and health data, and know what each one does not cover
1.Preventing data leakage through the prompt
Data leaks from Claude applications in two main ways. The model can reveal what is in its prompt, or it can reach data and systems it never needed. This section covers the first; the next covers the second.
A prompt leak exposes information you assumed was hidden in your prompt, such as a proprietary formula in the system prompt. The documentation is frank that no method is foolproof, and it warns against over-engineering: leak-resistant prompting adds complexity that can degrade the rest of the task. It recommends these techniques only when absolutely necessary, and thorough testing when you do use them.
The techniques it lists:
- Separate context from queries. Keep key information in the system prompt, apart from the user's query, and re-emphasize the key instructions in the user turn. (The page also mentions prefilling the assistant turn, but prefilling isn't supported on Claude 4.6 and later models, so don't rely on it.) - Use post-processing. Filter Claude's outputs for keywords that might indicate a leak, using regular expressions, keyword filtering or other text processing. - Avoid unnecessary proprietary details. If Claude doesn't need something to do the task, leave it out. Extra content also distracts Claude from its "no leak" instructions. - Regular audits. Periodically review your prompts and Claude's outputs for leaks.
Sources1
2.Authorization and authentication: least privilege and credentials Claude never sees
The second leakage path is access. The more Claude can reach, the more a successful injection or a mistake can expose. So the core authorization rule is least privilege: don't give Claude secrets it doesn't need, run tools in sandboxed environments, and scope permissions as narrowly as you can.
Claude Code's permission system shows what narrow scoping looks like. You can set each tool and bash command to be allowed, blocked, or to prompt for approval. Glob patterns let you write rules such as blocking any command that uses sudo, and organizations can set policies that apply to every user. Matching fails closed: in Manual mode, any command that doesn't match a rule needs approval, and so does any command that can't be parsed cleanly. Know the limits, though. The documentation calls this a permission gate, not a sandbox. Apart from a few built-in safety checks, it doesn't work out whether a command is dangerous from its target path or its effects.
Authentication secrets need the same discipline. Claude Code stores API keys and tokens in the macOS Keychain when one is available, and protects them with file permissions on Windows and Linux. For agents you deploy, the documentation recommends a proxy that injects credentials. The agent never sees the actual credentials, the proxy can enforce an allowlist of permitted endpoints and log every request, and credentials sit in one secure place instead of being copied to each agent. Claude Code cloud sessions follow the same pattern. GitHub credentials stay encrypted on Anthropic's servers and never enter the session VM, which holds only a short-lived credential scoped to that session.
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.
Access control extends to connected services. When Claude reaches tools through MCP, the MCP authorization specification requires every MCP server to check that a token presented to it was issued specifically for that server's use. It also requires every authorization server endpoint to be served over HTTPS. This prevents a token issued for one service from being accepted by another.
Integrity comes from the same controls, seen from the other side. Claude Code cloud sessions restrict git pushes to the current working branch and log every operation for compliance and audit, so changes stay both limited and traceable.
3.Privacy and PII: where conversation data lives and for how long
Once personal data is in a prompt, protecting its confidentiality and privacy depends on what happens to that prompt afterwards. For the Claude API, Anthropic describes baseline commitments. Retained data is never used for model training without your express permission. Only what a feature technically needs is kept. Conversation content isn't retained by default; the exception is Covered Models, which require 30-day retention. At rest, the Anthropic API uses AES-256 infrastructure-level disk encryption.
On top of that baseline there are two arrangements you opt into, built for different kinds of sensitive data:
| Aspect | Zero data retention (ZDR) | HIPAA readiness |
|---|---|---|
| What it does | Anthropic does not store prompts or responses at rest after the API response is returned | Applies encryption, access controls and audit logging to protect PHI throughout its lifecycle, instead of requiring immediate deletion |
| How you get it | Contact the Anthropic sales team; enabled per organization, and not automatically extended to other organizations under the same account | Sign a BAA and enable HIPAA readiness from the Claude Console |
| Claude Code | Covered with API keys from a Commercial organization, or through Claude Enterprise with ZDR enabled | Not covered |
| Notable exclusions | Features marked "No" in the eligibility table, such as code execution; CORS is not supported, so browser apps must route through a backend proxy server | Beta features unless explicitly listed; Claude Platform on AWS and Microsoft Foundry |
HIPAA readiness alone. Anthropic's documentation says an organization handling PHI should use HIPAA readiness and doesn't also need ZDR. HIPAA readiness applies a broader set of safeguards instead of deleting data immediately.
Neither arrangement covers everything around your application. Data processed by third-party websites, tools or other integrations falls outside ZDR, so every connector that receives personal data needs its own review. There is also a copy on the developer's machine: Claude Code clients cache session transcripts locally, in plaintext under ~/.claude/projects/, for 30 days by default so sessions can be resumed. That period is set by cleanupPeriodDays. This local cache is separate from anything Anthropic retains on its side, and if prompts contain PII, it is one more place that PII now lives.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Claude Code's command permission rules act as a sandbox that works out whether a command is dangerous.Why is that wrong?
Permission rules match commands against allow and deny patterns. Apart from a few built-in safety checks, they don't judge a command's target path or effects; isolation comes from the sandbox.
Covered in Authorization and authentication: least privilege and credentials Claude never sees
2.An organization processing PHI through the Claude API has to enable both ZDR and HIPAA readiness.Why is that wrong?
HIPAA readiness is the arrangement for PHI, and ZDR isn't needed on top of it.
Covered in Privacy and PII: where conversation data lives and for how long
3.Adding as many leak-proofing instructions as possible to the system prompt is always the safer choice.Why is that wrong?
Leak-resistant prompting adds complexity that can degrade performance on the rest of the task. Use it only when necessary, and test it.
Covered in Preventing data leakage through the prompt
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/reduce-prompt-leakOfficial docs
“Consider using leak-resistant prompt engineering strategies only when absolutely necessary.”
↩︎ Preventing data leakage through the prompt“Filter Claude's outputs for keywords that might indicate a leak.”
↩︎ Preventing data leakage through the prompt“If Claude doesn't need it to perform the task, don't include it.”
↩︎ Preventing data leakage through the prompt“Overly complex leak-prevention can degrade results. Balance is key.”
↩︎ Exam trap 3 - 2.https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaksOfficial docs
“don't give Claude access to secrets it doesn't need, run tools in sandboxed environments”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees - 3.
“Commands that cannot be parsed cleanly, or that do not match an allow rule, require explicit approval.”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees“Credentials are stored in one secure location rather than distributed to each agent”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees“This is a permission gate, not a sandbox”
↩︎ Exam trap 1 - 4.https://code.claude.com/docs/en/securityOfficial docs
“API keys and tokens are stored in the macOS Keychain when available, and protected by file permissions on Windows and Linux.”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees“Git push operations are restricted to the current working branch”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees - 5.https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerationsOfficial docs
“MCP servers MUST validate that tokens presented to them were specifically issued for their use”
↩︎ Authorization and authentication: least privilege and credentials Claude never sees - 6.
“Retained data is never used for model training without your express permission.”
↩︎ Privacy and PII: where conversation data lives and for how long“Under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned.”
↩︎ Privacy and PII: where conversation data lives and for how long“Data processed by third-party websites, tools, or other integrations is not covered”
↩︎ Privacy and PII: where conversation data lives and for how long“If your organization handles PHI, HIPAA readiness is the arrangement to use; you do not also need ZDR.”
↩︎ Exam trap 2 - 7.https://code.claude.com/docs/en/data-usageOfficial docs
“Claude Code clients store session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default”
↩︎ Privacy and PII: where conversation data lives and for how long