Agent Security Best Practices

Ten practices for sandboxing, credential scoping, and containment - expanded into a checklist you can use in design reviews and PR gates.

Agents fail closed when tools, secrets, and networks are designed as small systems that stay small under attack.

How to Use This List

Walk A when designing tools and roles; B when wiring isolation; C when operating after launch.
Tick items only when true in code or config, not as aspirations.
Pair with Security Checklist Before Shipping an Agent to Production for a launch-time gate.
Re-check after adding tools, MCP servers, browsers, or higher autonomy.

A - Shrink the Action Space

1. Default every tool to least privilege. Narrowest data, methods, paths, and side effects that still complete the job; expand only with review.
2. Prefer intent-shaped tools over platform-shaped tools. refund_order beats raw SQL, shell, or open HTTP with admin credentials.
3. Keep per-role allowlists. Multi-agent setups must not share a superuser tool registry under different names.
4. Gate irreversible actions in the host. Approvals, dual control, or dry-runs enforced in code - prompts are not controls.
5. Cap volume as a privilege. Rate, row, refund, email, and turn limits stop loops from becoming incidents.

B - Isolate Execution, Secrets, and Network

6. Sandbox untrusted code execution. Containers or stronger isolators: non-root, read-only root, resource limits, ephemeral jobs.
7. Never grant blanket production shell. Use structured tools or allowlisted argv; break-glass only with audit and humans.
8. Scope and time-bound credentials. Short-lived, purpose-built tokens; master secrets only in vault/host, never in prompts or sandboxes.
9. Default-deny egress. Per-tool host allowlists, block metadata/private ranges, separate model egress from sandbox egress.
10. Treat all tool I/O as untrusted content. Observations can carry injection; isolate instructions from data and validate outputs.

C - Operate Containment in Production

11. Enforce max turns, timeouts, and cost budgets on every agent loop, including specialists and retries.
12. Log policy decisions, not only model text. Tool name, allow/deny, destination host, key id, approver, policy version.
13. Maintain a kill switch and practice it. Disable tools or the agent without a full product outage.
14. Red-team with realistic injection and SSRF cases before widening autonomy or tools.
15. Review privileges on a cadence. New tools, MCP servers, and model changes trigger the same security pass as initial launch.

Applying These Practices in Order

Action space (1-5): cheapest fix on a whiteboard; hardest after tool sprawl ships.
Isolation (6-10): hard launch blockers when code exec, secrets, or external calls exist.
Operate (11-15): keeps containment honest after real traffic and real attackers (including accidental ones).

FAQs

Why "ten practices" if there are fifteen checkboxes?

The section promise is ten core practices (items 1-10). Items 11-15 extend them into operations so the list stays useful after launch.

What is the first practice if we can only adopt one?

Remove generic shell and open HTTP tools; replace with narrow allowlisted tools. That single change collapses most blast radius.

How do these practices relate to framework choice?

They are framework-agnostic. LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, and custom hosts all need the same boundaries.

Do internal-only agents need the full list?

Yes when they hold prod credentials or can change prod systems. Network location is not a control.

Is a strong system prompt enough for practice 10?

No. Use structural separation, output validation, and least-privilege tools so injection cannot unlock powerful actions.

How narrow is "narrow enough" for a tool?

If you cannot state the business invariant in one sentence (for example "refunds at most $X on orders for this tenant"), split or cap the tool.

Where should egress be enforced?

At least twice when risk is high: in the tool client and at the network/proxy layer so bypasses are harder.

How do sandboxes interact with package installs?

Prefer prebaked images. Runtime installs need network and supply-chain controls; they conflict with default-deny egress.

What evidence shows practice 8 was violated?

Long-lived admin keys in the agent env, secrets in prompts/traces, or code-exec jobs that can read os.environ full of production credentials.

Can we implement these incrementally?

Yes. Ship allowlists, budgets, and no-shell first; then containers; then minted tokens and mesh egress. Do not open autonomy faster than isolation.

How does observability support security?

You cannot revoke, alert, or forensically explain what you never logged. Practice 12 is the bridge to the observability section.

Where should teams link this list?

In the section sidebar as the close-out checklist, in ADRs for agent platforms, and in on-call runbooks for tool incidents.

The Principle of Least Privilege Applied to Agent Tools - principle deep dive
Agent Security Basics - first sandbox patterns
Containerized Sandboxes for Code-Executing Agent Tools - isolation recipe
Scoping API Keys and Credentials Passed to an Agent - credential recipe
Never Grant Blanket Shell Access in Production: What to Do Instead - shell alternatives
Network Egress Controls for Agents That Call External Tools - egress recipe
Security Checklist Before Shipping an Agent to Production - launch gate
How Prompt Injection Attacks Actually Work - content-layer attacks

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.

Agent Security Best Practices

Ten practices for sandboxing, credential scoping, and containment - expanded into a checklist you can use in design reviews and PR gates.

Agents fail closed when tools, secrets, and networks are designed as small systems that stay small under attack.

How to Use This List

Walk A when designing tools and roles; B when wiring isolation; C when operating after launch.
Tick items only when true in code or config, not as aspirations.
Pair with Security Checklist Before Shipping an Agent to Production for a launch-time gate.
Re-check after adding tools, MCP servers, browsers, or higher autonomy.

A - Shrink the Action Space

1. Default every tool to least privilege. Narrowest data, methods, paths, and side effects that still complete the job; expand only with review.
2. Prefer intent-shaped tools over platform-shaped tools. refund_order beats raw SQL, shell, or open HTTP with admin credentials.
3. Keep per-role allowlists. Multi-agent setups must not share a superuser tool registry under different names.
4. Gate irreversible actions in the host. Approvals, dual control, or dry-runs enforced in code - prompts are not controls.
5. Cap volume as a privilege. Rate, row, refund, email, and turn limits stop loops from becoming incidents.

B - Isolate Execution, Secrets, and Network

6. Sandbox untrusted code execution. Containers or stronger isolators: non-root, read-only root, resource limits, ephemeral jobs.
7. Never grant blanket production shell. Use structured tools or allowlisted argv; break-glass only with audit and humans.
8. Scope and time-bound credentials. Short-lived, purpose-built tokens; master secrets only in vault/host, never in prompts or sandboxes.
9. Default-deny egress. Per-tool host allowlists, block metadata/private ranges, separate model egress from sandbox egress.
10. Treat all tool I/O as untrusted content. Observations can carry injection; isolate instructions from data and validate outputs.

C - Operate Containment in Production

11. Enforce max turns, timeouts, and cost budgets on every agent loop, including specialists and retries.
12. Log policy decisions, not only model text. Tool name, allow/deny, destination host, key id, approver, policy version.
13. Maintain a kill switch and practice it. Disable tools or the agent without a full product outage.
14. Red-team with realistic injection and SSRF cases before widening autonomy or tools.
15. Review privileges on a cadence. New tools, MCP servers, and model changes trigger the same security pass as initial launch.

Applying These Practices in Order

Action space (1-5): cheapest fix on a whiteboard; hardest after tool sprawl ships.
Isolation (6-10): hard launch blockers when code exec, secrets, or external calls exist.
Operate (11-15): keeps containment honest after real traffic and real attackers (including accidental ones).

FAQs

Why "ten practices" if there are fifteen checkboxes?

The section promise is ten core practices (items 1-10). Items 11-15 extend them into operations so the list stays useful after launch.

What is the first practice if we can only adopt one?

Remove generic shell and open HTTP tools; replace with narrow allowlisted tools. That single change collapses most blast radius.

How do these practices relate to framework choice?

They are framework-agnostic. LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, and custom hosts all need the same boundaries.

Do internal-only agents need the full list?

Yes when they hold prod credentials or can change prod systems. Network location is not a control.

Is a strong system prompt enough for practice 10?

No. Use structural separation, output validation, and least-privilege tools so injection cannot unlock powerful actions.

How narrow is "narrow enough" for a tool?

If you cannot state the business invariant in one sentence (for example "refunds at most $X on orders for this tenant"), split or cap the tool.

Where should egress be enforced?

At least twice when risk is high: in the tool client and at the network/proxy layer so bypasses are harder.

How do sandboxes interact with package installs?

Prefer prebaked images. Runtime installs need network and supply-chain controls; they conflict with default-deny egress.

What evidence shows practice 8 was violated?

Long-lived admin keys in the agent env, secrets in prompts/traces, or code-exec jobs that can read os.environ full of production credentials.

Can we implement these incrementally?

Yes. Ship allowlists, budgets, and no-shell first; then containers; then minted tokens and mesh egress. Do not open autonomy faster than isolation.

How does observability support security?

You cannot revoke, alert, or forensically explain what you never logged. Practice 12 is the bridge to the observability section.

Where should teams link this list?

In the section sidebar as the close-out checklist, in ADRs for agent platforms, and in on-call runbooks for tool incidents.

The Principle of Least Privilege Applied to Agent Tools - principle deep dive
Agent Security Basics - first sandbox patterns
Containerized Sandboxes for Code-Executing Agent Tools - isolation recipe
Scoping API Keys and Credentials Passed to an Agent - credential recipe
Never Grant Blanket Shell Access in Production: What to Do Instead - shell alternatives
Network Egress Controls for Agents That Call External Tools - egress recipe
Security Checklist Before Shipping an Agent to Production - launch gate
How Prompt Injection Attacks Actually Work - content-layer attacks

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.

Agent Security Best Practices

Search Documentation

Agent Security Best Practices