Security Guardrail Rules Every Tech Lead Should Enforce
These rules are the non-negotiable security defaults for production agents with tools, credentials, or network access.
Agents fail differently from ordinary services because the model chooses tools and arguments under the influence of user content, retrieved documents, and tool outputs.
Security that lives only in the system prompt is not security.
How to Use This List
- Treat this as a go/no-go gate before real users, real data, or real money touch a tool-using agent.
- Tick a rule only when evidence exists in code, config, or a linked runbook - not when it is "planned."
- Re-run after any new tool, autonomy increase, tenant type, or model path.
- Pair with the agent security section for deeper sandbox, egress, and credential recipes.
Threat Model Rules
- Write a short threat model before production. Cover injection via user content and tools, secret theft, data exfil, spend abuse, and lateral movement.
- Record autonomy level explicitly. Draft / recommend / supervised execute / narrow auto - with criteria for moving up.
- List irreversible actions in scope. Money, delete, external send, auth change, and prod deploys need gates.
- Label data classes in prompts and tools. Public / internal / PII / secrets / regulated drive logging and provider policy.
- Assume tool results and retrieved docs can contain attacker instructions. Defense cannot depend on "the model will notice."
Least Privilege and Tool Rules
- Allowlist tools per agent role. No kitchen-sink registry in production.
- One tool, one job. Intent-shaped APIs beat generic supertools.
- Validate all tool arguments in host code. Types, ranges, enums, length caps, reject unknown fields.
- No master or admin keys in the agent. Scoped roles only; prefer short-lived credentials.
- Read tools must not be able to write. Separate credentials and handlers.
- No blanket shell in production. Prefer intent-shaped tools; break-glass shell only with approval and audit.
- Path and workspace jail for file tools. No host home, no secret mounts, no arbitrary absolute paths.
- Rate and amount caps for high-risk actions. Refunds, emails, rows, and API calls bounded per run and per tenant.
- Human approval enforced in host code for irreversible actions. Prompt text is not a control.
Sandbox and Execution Rules
- Run untrusted code outside the API process. Container, microVM, or equivalent isolation.
- Network default deny for code sandboxes. Open egress only with a named justification and allowlist.
- Read-only root and limited writable tmp. Drop capabilities; non-root; no new privileges.
- CPU, memory, PID, and time limits with hard kill. Resource exhaustion is a security and reliability issue.
- Scrub sandbox environment of provider and DB secrets. Code-exec must not inherit prod credentials.
- No Docker socket or privileged mounts exposed to agent code.
Network Egress and Data Boundary Rules
- Per-tool destination allowlist. Named hosts, not open internet.
- Block cloud metadata and link-local ranges. SSRF to metadata is a classic failure mode.
- Private network access only via named internal services. Not broad RFC1918 free reign.
- Re-validate redirects on HTTP clients used by tools. Open redirects defeat naive allowlists.
- Separate model-provider egress from untrusted sandbox egress. Different trust domains.
- Apply data-retention filters when routing through multi-provider gateways. Some providers retain prompts (verify at build).
Injection and Output Guardrail Rules
- Never obey instructions found inside tool results or documents as system policy. Host policy overrides content.
- Validate structured model output before executing side effects. Schema validation is a guardrail.
- Content-filter or policy-check high-risk generations when product risk requires it. Especially user-facing or regulated domains.
- Truncate and sanitize tool observations before re-injection. Huge dumps hide injection and leak data.
- Do not place secrets in prompts, few-shots, or model-visible tool args.
- Prefer allowlisted actions over free-form natural language that becomes code or SQL.
Detection, Kill Switch, and Review Rules
- Log security-relevant events with run ids. Tool name, decision (allow/deny), and redacted args.
- Alert on anomalous tool rates, spend, or deny spikes. Detection is part of the control set.
- Maintain a tested kill switch to disable an agent, tool, or key without full outage theater.
- Run negative tests in CI. Escape attempts (path, network, import) fail closed.
- Re-review security when autonomy or tools expand. Privilege expansion is a new ship, not a drive-by config change.
- Document exceptions with owner and expiry. Permanent silent exceptions are drift.
Quick Anti-Patterns
| Anti-pattern | Why it fails | Replace with |
|---|---|---|
| "Please do not access secrets" in the prompt | Model may ignore under injection | Host denial + scrubbed env |
| Shared admin API key for all tools | Blast radius is total | Per-tool scoped credentials |
| Open egress for convenience | Exfil and SSRF | Destination allowlist |
Production run_shell | Arbitrary host control | Intent-shaped tools |
| Logging full prompts with tokens | Observability becomes a breach | Redaction pipelines |
| Self-merged tool privilege increases | No adversarial review | Second reviewer + checklist |
FAQs
Is prompt injection fully solvable with a better model?
No.
Reduce impact with least privilege, validation, and sandboxing; improve detection with filters and evals.
Do not treat "smarter model" as the only control.
Do these rules apply to read-only agents?
Yes, scaled down.
Read-only agents still risk data exfil, spend abuse, and injection that tries to escalate tools later.
Where should security checks run - model or host?
Host code is authoritative.
Models can assist with classification; they must not be the only gate before irreversible actions.
How strict should sandboxes be for internal tools?
As strict as the data and credentials they can reach.
Internal does not mean low impact.
What is the minimum viable security set for a pilot?
Scoped tools, no shell, schema validation, spend caps, secret scrubbing, and a kill switch.
Add sandbox and egress hardening before write tools or untrusted code execution.
How do multi-tenant agents change the rules?
Isolation becomes mandatory: no shared downstream tokens, strict tenant ids on every tool call, and careful logging redaction.
Are guardrail libraries enough?
They help with content filtering and policy checks.
They do not replace least privilege, sandboxing, or egress allowlists.
How often should we re-run this list?
Before first production traffic, after material tool or autonomy changes, and on a fixed security review cadence.
What if a stakeholder wants "full computer use" autonomy?
Require a separate threat model, sandbox design, and approval matrix.
Do not silently promote a chat agent to host control.
How do these rules relate to the full security checklist section?
This page is the tech-lead rule set.
The agent security section expands each control into implementation checklists and recipes.
Should personal agents on a VPS follow the same rules?
Yes for shell, email, calendar, and credentials.
Blast radius is personal but still real.
What is the first control to implement if we can only pick three?
Tool allowlist with least privilege, host-side validation, and a kill switch / spend cap.
Then sandbox and egress.
Related
- How Opinionated Rules Prevent Agent Production Incidents - why enforced defaults beat prompt hope.
- Tool Design Rules for Safe, Composable Agents - tool scoping and validation depth.
- The Core Agent Rules: A Quick-Reference List - condensed security rows.
- AI Agent Rules Best Practices - checklist form including security items.
- Security Checklist Before Shipping an Agent to Production - full pre-launch security gate.
- The Principle of Least Privilege Applied to Agent Tools - privilege design.
- Never Grant Blanket Shell Access in Production: What to Do Instead - shell alternatives.
- Guardrail Libraries and Content Filtering Layers for Agents - content-layer defenses.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.