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.

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

Which section of this list matters most to get right first?

Threat Model Discipline (Section A) and Least-Privilege Tool Scoping (Section C), since they determine the blast radius of everything else. A well-grounded, well-cited RAG answer from an over-privileged tool is still a serious risk if that tool gets manipulated.

Do all these practices apply to a simple, read-only chatbot with no tools?

Sections A, B, E, and F still apply in reduced form, since even a read-only pipeline has an untrusted-content surface and PII/compliance exposure. Sections C, D, and G are primarily relevant once tool access or caching enters the picture.

How is this best-practices list different from the individual checklists elsewhere in this section?

The dedicated checklists (tool scoping, SOC2/GDPR, citation and grounding) go deeper on their specific topic with detailed numbered steps. This page is a condensed, cross-cutting summary meant for quick reference and design review, not a replacement for the detailed pages.

Why does Section D insist on per-tool credentials instead of one shared credential?

A shared credential means every tool inherits the combined permissions of all of them, so a gap in any single tool's validation exposes everything the shared credential can reach. Per-tool credentials keep each tool's actual blast radius equal to its stated scope.

Is a regex-based injection filter (item in Section B) sufficient on its own?

No, it should be one layer among several, paired with delimiter isolation and explicit system-prompt framing. Regex catches known phrasings but misses paraphrases, encoded text, and injections in other languages.

What's the fastest way to check whether prompt caching (Section G) is actually saving money?

Check the cache_read_input_tokens and cache_creation_input_tokens fields on response usage data across real traffic. A healthy pattern shows many cache reads relative to cache writes.

How does Section F (retrieval quality) connect to security rather than just answer quality?

Poor grounding and poor security overlap more than they first appear, a RAG pipeline that includes low-relevance or unverified chunks is both more likely to hallucinate and more exposed to indirect injection, since a wider, less curated retrieved set is a wider untrusted-content surface.

Do these best practices assume a specific vector database or retrieval stack?

No, they're written to apply regardless of which vector database, embedding model, or hybrid search implementation you use, the practices concern the pipeline's structure and controls, not a specific vendor's API.

What should trigger a full re-review of this checklist for an existing agent?

Adding a new tool, connecting a new retrieval source, changing which credentials back existing tools, or expanding what data an agent can access, any of these changes the risk profile enough to warrant walking through the relevant sections again.

Are Sections D (secrets) and E (compliance) redundant with each other?

They overlap but aren't redundant, Section D focuses on preventing leaks and exfiltration through tool use, Section E adds the specific legal and audit-trail obligations (retention limits, data subject rights, attributable access logging) that apply once PII is involved, whether or not a leak ever occurs.

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.