Security Guardrail Rules Every Tech Lead Should Enforce
These are the enumerated security rules this site distills for shipping Claude in production - condensed here as enforceable defaults; the full reasoning and threat models live in this site's dedicated security and RAG-pipeline coverage.
How to Use This Checklist
- Apply these rules to every system that lets Claude call a tool, read a document, or act on behalf of a user - not only "agentic" features.
- Treat this as a pre-launch gate for any feature giving Claude write access to a real system.
- Re-run this checklist whenever a new tool, MCP server, or data source is added to an existing agent.
- Pair with Tool Design Rules, which covers the tool-level counterpart to several rules here.
Permission Scoping Rules
- Apply least privilege to every credential a Claude-powered system can reach. A tool, MCP server, or API key should have exactly the access its task requires - no broader grant "in case it's needed later."
- Scope credentials per tool or per integration, not per agent. One overprivileged shared credential means a bug or misuse in any single tool can affect everything that credential can touch.
- Never grant write access by default. Start every new integration read-only, and add write access deliberately, with review, once the read-only path has proven reliable.
- Expire and rotate credentials Claude-powered systems depend on. Long-lived, never-rotated API keys are a standing risk independent of how carefully the tool itself is designed.
- Keep production and staging credentials fully separate. A tool tested against staging should never be one config flip away from touching production data.
Output Validation Rules
- Treat model output as untrusted input, not a trusted instruction. Generated text and tool arguments should go through the same validation any external, unauthenticated input would - never execute a model-generated command or query directly.
- Never interpolate model output directly into a shell command, SQL query, or file path. Use parameterized queries, allowlisted commands, and path validation exactly as you would for any user-submitted value.
- Validate structured output against a schema before acting on it. A malformed or unexpectedly shaped response should be rejected and retried, not partially trusted.
- Sanitize any model output rendered back to end users. Output intended for display can carry injected markup or formatting from adversarial input earlier in the conversation - sanitize before rendering, the same as any other user-influenced content.
- Assume any external content Claude reads (documents, web pages, retrieved data) can contain adversarial instructions. Design tools and prompts so that instructions embedded in retrieved content cannot silently override the system prompt's actual authority.
Logging and Audit Rules
- Log every sensitive tool call independent of the conversation transcript. A transcript can be edited, truncated, or lost; a dedicated audit log for destructive or data-touching calls survives independently and supports incident review.
- Record who or what triggered a sensitive action, not just that it happened. For agentic systems, capture the triggering user, session, and prompt version alongside the action itself.
- Retain audit logs longer than the underlying conversation history. Compliance and incident-review needs typically outlast normal conversation retention windows - don't let log retention silently inherit a shorter default.
- Alert on anomalous tool-call patterns, not just individual failures. A single failed tool call is noise; a sudden spike in a specific tool's call volume or an unusual sequence of calls is a signal worth paging on.
Secrets and Credentials Rules
- Never place secrets in a prompt, system message, or memory file. Anything the model can read, it can also potentially repeat back - credentials belong in a vault, environment variable, or secrets manager, never in text the model processes.
- Never let a tool's error message leak a credential or internal detail back into the model's context. A failed authentication error that includes the attempted key or an internal stack trace hands that information to whatever reads the transcript next.
- Audit memory and long-term storage features for accidental secret persistence. A memory tool or cross-session store that a credential was accidentally written to will keep replaying it into future sessions until it's found and purged.
- Use short-lived, scoped tokens over long-lived static keys wherever the integration supports it. A token that expires limits the damage window if it's ever exposed.
Prompt Injection and Isolation Rules
- Isolate untrusted content from instructions the model should treat as authoritative. Clearly separate system-level instructions from user-supplied or retrieved content so a prompt injection embedded in retrieved data can't masquerade as an operator instruction.
- Never let a single agent both ingest untrusted external content and hold high-privilege tool access in the same turn without review. The classic injection risk is a tool that reads an attacker-influenced document and a tool that can take a destructive action both being available at once - separate them or add a confirmation gate between.
- Test agents against adversarial inputs before launch, not only happy-path inputs. Include prompt-injection attempts, malformed tool arguments, and boundary-pushing requests in the pre-launch test set for any tool-using agent.
Governance Rules
- Assign an explicit owner for security review of every Claude-powered feature. Security guardrails degrade the same way any other rule does without an owner - see How Opinionated Rules Prevent Claude Production Incidents.
- Re-review guardrails whenever a feature's tool access or data scope expands. A feature that started read-only and later gained write access needs its security review repeated, not grandfathered in from the original launch.
FAQs
What's the single most common security gap in Claude-powered systems?
Trusting model output as if it were a verified instruction rather than untrusted input - interpolating generated text directly into a command, query, or path without validation.
Why is prompt injection different from a normal input-validation bug?
Because the "input" is often content the model is asked to read and reason about, not content submitted directly by a user - a malicious instruction embedded in a document or web page can attempt to redirect the model's behavior mid-task, which normal form-input validation doesn't cover.
Should every tool call be logged, or only destructive ones?
At minimum, every tool call with a side effect - writes, deletions, payments, external communications. Read-only calls can be logged too for debugging, but the audit-trail requirement is strongest for anything that changes state.
How does least privilege apply to a single agent with many tools?
Each tool should carry its own scoped credential rather than the agent holding one broad credential all its tools share - that way a bug or misuse in one tool can't reach systems only a different tool needed access to.
What's the risk of storing secrets in a memory or long-term storage feature?
Anything persisted to memory gets replayed into future sessions' context - a credential written once, even accidentally, keeps being read back by the model in every subsequent session that mounts that memory until someone finds and removes it.
Why separate production and staging credentials?
Because a tool tested against staging data, with staging-scoped credentials, should never be a single config change away from operating on production - separating them removes an entire class of "accidentally tested in prod" incidents.
Do these rules apply to read-only integrations too?
Yes, though with lower urgency - read-only access still needs least-privilege scoping and can still leak sensitive data through model output, even without a write path.
How often should a security review be repeated?
At minimum whenever the feature's tool access or data scope changes, and on a periodic cadence otherwise - a feature that hasn't changed can still become risky if the threat landscape or the data it touches has.
What should be included in adversarial pre-launch testing?
Prompt-injection attempts embedded in retrieved content, malformed or boundary-pushing tool arguments, and requests designed to make the agent take an action outside its intended scope - not just typical happy-path requests.
Is alerting on tool-call volume overkill for a small team?
Not necessarily - even a simple threshold alert on an unusual spike in a sensitive tool's call count catches runaway loops and misuse far earlier than discovering it during a manual audit or a customer complaint.
How do these rules relate to the deeper security-rag-pipelines coverage on this site?
This page is the condensed, enforceable rule form; the security-rag-pipelines section covers the full threat models, architecture patterns, and worked examples these rules are drawn from.
Related
- Tool Design Rules for Safe, Composable Claude Agents - the tool-level counterpart to several rules on this page.
- How Opinionated Rules Prevent Claude Production Incidents - why these rules need an owner to stay enforced.
- The Core Claude Rules: A Quick-Reference List - the condensed version of these rules alongside every other category.
- Claude Rules Best Practices - every rule in this section restated as one checklist.
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
anthropicPython 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.