Security, Compliance & RAG Best Practices

These are the standing rules for building production Claude applications that combine tool use, retrieval, and sensitive data safely. Use it as a reference during design review, not only at launch.

How to Use This List

• Treat every rule as a positive statement of what "good" looks like, tie it to a lint rule, a code review checklist item, or an architecture decision record where possible.
• Rules are grouped by the same structure as the rest of this section: threat model, injection defense, tool scoping, secrets, compliance, and retrieval quality.
• Revisit this list whenever you add a new tool, a new data source, or a new integration, not only when something goes wrong.

A - Threat Model Discipline

• Map untrusted content, tool access, and permission scope for every agent before launch. These three factors multiply risk rather than adding to it, reducing any one to near zero controls the overall exposure regardless of the other two.
• Re-evaluate the threat model whenever retrieval or tool access changes, not just at initial design. Adding a new tool or a new retrieval source to an existing agent changes its risk profile as much as building a new agent from scratch.
• Assume internal content sources are not automatically trusted content sources. Anyone with edit access to an internal wiki, ticket queue, or document store can plant content your pipeline later retrieves, "internal" narrows who could be an attacker, it doesn't remove the threat.

B - Indirect Prompt Injection Defense

• Wrap every piece of retrieved or tool-sourced content in explicit data delimiters. Tags like <source> or <retrieved_document> give Claude a machine-parseable boundary between trusted instructions and untrusted content.
• State in the system prompt that delimited content is data, not instructions, even if it claims otherwise. Injected content often specifically tries to impersonate a system message, address that directly rather than assuming the model infers it.
• Run a pre-filter against known instruction-like phrasings before content ever reaches the prompt. A regex or keyword filter is not sufficient alone, but it is a cheap, effective first layer that catches common attack patterns.
• Apply the same isolation pattern to tool results as to document retrieval. A web search tool, a document-reading tool, or a third-party API integration all pull in untrusted content just like a vector database, and need the same defenses.
• Maintain and periodically expand an adversarial test set for injection resistance. New injection phrasings appear regularly, a static test set from initial launch stops catching real attacks over time.

C - Least-Privilege Tool Scoping

• Give every tool the narrowest input_schema that still does its job. Prefer enums and internally-resolved values over open-ended string parameters for anything that maps to a real action.
• Issue a separate, scoped credential per tool rather than one shared credential across an agent. A shared credential collapses the blast radius of the entire toolset into whatever that one credential can access.
• Validate every tool argument in code before execution, regardless of what the model claims. Treat Claude's tool call arguments as untrusted input, the same way you'd treat a value from an HTTP request body.
• Cap the blast radius of a single tool call with rate limits and record limits. Bound how many times a tool can be called per session and how many records a single call can touch.
• Get a second reviewer, who didn't build the tool, to sign off on its scope before deployment. The original author's mental model of "what this is for" makes it easy to overlook what the tool is actually capable of.

D - Secrets and Exfiltration Prevention

• Never place a credential in a prompt string, system prompt, or tool argument. Load secrets only inside tool implementation code, from an environment variable or a dedicated secrets manager, never anywhere the model's context window could see them.
• Allowlist destinations for any tool that can send data externally. Check the target host or address against an explicit allowlist before executing, don't trust a destination the model supplied.
• Allowlist the fields a tool payload can contain, using schema constraints like additionalProperties: False. This blocks the model from constructing an out-of-scope call at the schema level, before your own validation code even runs.
• Redact secret-shaped and PII-shaped content before it reaches any log, error message, or third-party observability tool. Route all logging through a single redaction function so no code path can accidentally write unredacted content.
• Log every tool call attempt, success, and block, not just the successful ones. A complete audit trail is what lets you reconstruct exactly what happened during a suspected incident.

E - SOC2 and GDPR Compliance

• Send only the fields a prompt actually needs, and strip PII from retrieved context before it enters a prompt. Minimizing what reaches the model in the first place is the cheapest and most reliable compliance control.
• Enforce retention limits with automated deletion, not a policy document alone. A written retention policy without an enforcing job or database TTL is a paper control that won't hold up under a SOC2 Type II audit.
• Apply retention and erasure logic to vector store indexes, not only to conversation logs. RAG pipelines routinely retain PII-containing chunks indefinitely because indexed content doesn't look like a traditional log.
• Log PII access with attributable identity, not a generic application-level entry. A SOC2 audit specifically looks for who or what accessed sensitive data, "someone" is not sufficient evidence.
• Be able to locate and export or delete all Claude API interactions tied to a specific user's identifier. This is the operational requirement behind GDPR data subject access and erasure rights, and it needs to be tested before it's needed, not built during an active request.

F - Retrieval Quality and Grounding

• Tune chunk size and overlap against measured retrieval quality, not against embedding cost alone. A smaller chunk size is cheaper but can degrade answer quality in ways that don't surface until users notice.
• Combine keyword and embedding search for corpora with exact-match-sensitive content. Pure semantic search underweights product codes, error codes, and proper nouns that keyword search catches reliably.
• Instruct Claude explicitly to answer only from retrieved content, and give it explicit permission to say sources don't cover a question. This single change reduces confident, ungrounded answers more than most downstream verification layers.
• Verify citations point to chunks that were actually retrieved, and spot-check that cited claims match the source text. Citation presence alone doesn't guarantee accuracy, the model can cite a real source while still misrepresenting it.
• Maintain a held-out evaluation set of real queries and track grounding accuracy over time. Retrieval, chunking, and prompting all drift as a corpus and codebase evolve, a one-time evaluation doesn't catch regressions.

G - Cost-Efficient Pipelines

• Cache genuinely stable, reused context, never per-query retrieved content. Marking volatile retrieval as cacheable causes a cache miss on every request while still paying the higher cache-write cost.
• Generate cached content deterministically so the cache prefix stays byte-identical across requests. Even minor formatting drift in "stable" content silently defeats caching.
• Verify cache hits are actually occurring in production using response usage data. Setting cache_control is not the same as confirming it's working, check cache_read_input_tokens on real traffic.

Gotchas

• Treating this list as a one-time launch checklist rather than a living review tool. Threat model, tool scope, and grounding quality all drift as an agent's tools and data sources evolve, a single pass at launch misses that drift. Fix: revisit relevant sections whenever a tool, data source, or retrieval config changes.
• Applying these practices unevenly across tools within the same agent. A team that carefully scopes one tool and leaves another loosely defined has effectively scoped the agent to its weakest tool. Fix: apply the full checklist per tool, not once per agent.
• Assuming compliance controls (Section E) are separate from security controls (Sections B-D). Redaction, access logging, and least-privilege scoping serve both purposes simultaneously, building them once for security largely satisfies the compliance requirement too. Fix: design these controls together rather than as two separate initiatives.

FAQs

Related

• Understanding the Claude Security and RAG Threat Model - the mental model this checklist operationalizes.
• Least-Privilege Tool-Scoping Checklist for Production Claude Agents - the detailed version of Section C.
• SOC2 and GDPR Considerations for PII in Prompts and Logs - the detailed version of Section E.
• Citation and Grounding Checklist to Reduce RAG Hallucinations - the detailed version of Section F.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.