Security Hardening Claude Agents: Sandboxing & Least Privilege

An agent that can call tools is, by definition, a program that takes actions in the world based on text it reads. The moment some of that text comes from outside your control — a web page it fetched, an email it parsed, a document a user uploaded — your agent is executing on attacker-influenced input. Traditional appsec assumes a clear line between code and data. Agentic systems blur it: the data is the instructions. Hardening a Claude orchestration system means rebuilding that line deliberately, with sandboxing, least privilege, careful secrets handling, and a real plan for prompt injection. This post lays out a defense-in-depth approach that holds up when the agent meets hostile input.

The threat model is different

Start by naming what can go wrong, because the list isn't the usual one. An agent can be persuaded by injected text to misuse a legitimate tool — exfiltrating data it has access to, taking a destructive action, or leaking a secret. It can be tricked into calling a tool with attacker-chosen arguments. And because orchestrators spawn subagents that carry their own permissions, a compromise in one branch can reach further than you'd expect. The governing principle for all of it is the same one that has protected systems for decades, applied freshly: assume any input may be hostile, and ensure that even a fully manipulated agent cannot do more damage than its narrowest necessary permissions allow.

Sandbox the tools, not just the model

The most important hardening move is to constrain what tools can do, independent of what the model decides to ask. If an agent has a shell or code-execution tool, run it in an isolated sandbox — a container or microVM with no host filesystem access, no ambient credentials, and an egress allowlist so it can only reach the specific endpoints it needs. Claude Code's own execution model leans on sandboxed runners for exactly this reason: the agent can be as creative as it likes inside the box, and the box is what limits the blast radius.

Network egress deserves special attention because it is the classic exfiltration path. A common injection attack instructs the agent to take sensitive data it can see and send it to an attacker's URL. If the sandbox can only make outbound connections to an allowlist of approved hosts, that attack fails at the network layer no matter how convincing the injected prompt was. Egress control is one of the highest-value, lowest-effort defenses you can add.

flowchart TD
  A["Agent requests tool action"] --> B{"Tool in allowed set for this agent?"}
  B -->|No| C["Deny & log"]
  B -->|Yes| D{"Action mutating or sensitive?"}
  D -->|No| E["Run in sandbox"]
  D -->|Yes| F{"Within policy & scope?"}
  F -->|No| G["Require human approval"]
  F -->|Yes| E
  E --> H{"Egress to allowlisted host only?"}
  H -->|No| C
  H -->|Yes| I["Return result"]

Least privilege, per agent and per tool

Least privilege is the doctrine that every component should hold only the permissions it needs to do its job, and nothing more. In an orchestration system this applies at two levels. Per agent: a subagent assigned to summarize documents has no business holding write access to your database, so don't give its toolset that tool at all. Per tool: the credentials a tool uses should be scoped down — a read-only database role for a lookup tool, an API key that can only touch the one resource it needs, write access gated behind a separate, explicitly granted tool.

This containment is what makes prompt injection survivable rather than catastrophic. If an attacker convinces a read-only research subagent to "delete all records," the agent simply has no tool capable of doing so; the request dies for lack of capability. Design the toolset so that the union of what any single compromised agent can do stays small and recoverable. When a step genuinely needs a dangerous capability, isolate it behind a narrow tool with its own approval gate rather than handing broad power to a general-purpose agent.

Keep secrets out of the context window

A subtle and common mistake is putting secrets where the model can see them. API keys, tokens, and credentials should never be placed into the prompt or the context window — not in the system prompt, not in tool definitions, not echoed back in tool results. The model doesn't need to know the secret; it needs to invoke a tool, and your tool layer injects the credential at execution time, on the server side, where the model never observes it. This matters because anything in the context can be coaxed out by injection, and because transcripts get logged. Treat the boundary as absolute: the orchestrator decides intent, the tool runtime holds the keys.

Apply the same care to tool outputs. If a tool returns a record that happens to contain sensitive fields, redact or omit them before they enter the context unless the agent genuinely needs them. Every secret-shaped value that reaches the model is a value an attacker might exfiltrate.

Defending against prompt injection directly

Sandboxing and least privilege contain the damage; you also want to reduce the odds of injection succeeding in the first place. Several layered tactics help. Clearly delimit untrusted content in the context and instruct the model that text inside those bounds is data to be analyzed, never instructions to follow — Claude respects this framing well when it's explicit. Run a separate, cheap classification pass over high-risk inputs to flag obvious injection attempts before they reach the main reasoning loop. And for any high-consequence action — sending money, deleting data, emailing customers — keep a human approval step or a deterministic policy check between the model's decision and the irreversible effect. No single layer is sufficient; the strength comes from stacking containment, detection, and approval so that defeating one still leaves the others standing.

Frequently asked questions

Can I fully prevent prompt injection?

No — there is no known way to make a model perfectly immune to adversarial instructions in its input. That's precisely why the strategy is defense in depth: assume injection can succeed, and use sandboxing, least-privilege tool scopes, egress allowlists, and human approval gates so that a successful injection still can't cause real harm.

Where should API keys live in an agent system?

In your tool execution layer on the server side, injected at call time, never in the prompt or context window. The model should be able to trigger a tool without ever seeing the credential the tool uses. This keeps secrets out of transcripts and out of reach of exfiltration attempts.

How do I let an agent take risky actions safely?

Isolate each risky capability behind its own narrow tool, scope that tool's credentials tightly, and place a policy check or human approval between the model's request and the actual effect. The agent proposes; a deterministic gate disposes. This keeps the dangerous surface small and auditable.

Secure agentic AI on your phone lines

CallSphere builds these defenses — sandboxed tools, least-privilege scopes, server-side secrets — into voice and chat agents that handle real customer data, use tools mid-conversation, and book work 24/7 without exposing what they shouldn't. See the hardened system at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.