Securing Claude Agents: Sandboxing & Least Privilege

The Anthropic Economic Index tells a story about trust. The tasks people increasingly delegate to Claude — editing code, querying production data, sending messages, hitting internal APIs — are tasks with real-world consequences. The moment an agent can act, not just talk, its security posture stops being theoretical. A prompt-injected web page, an over-broad tool, or a leaked secret turns a helpful assistant into a confused deputy executing an attacker's intent.

Agent security is its own discipline because the threat model is unusual: the "untrusted input" can be anything the agent reads — a file, a webpage, a tool result — and the model is, by design, eager to act on instructions it finds. This post lays out the four pillars that contain that risk: sandboxing, least privilege, secrets handling, and prompt-injection defense.

Key takeaways

• An agent that can act has a blast radius; security work is about shrinking it before something goes wrong.
• Sandboxing isolates execution so a bad action can't touch the host, the network, or other tenants.
• Least privilege means each tool gets the narrowest scope that still does its job — read-only by default, write only where required.
• Secrets belong in the runtime environment, never in the prompt or context where the model could echo them.
• Prompt injection is the signature agent attack: untrusted content tries to hijack the agent's instructions. Treat all tool/web output as untrusted.

The agent threat model in one paragraph

A classic app trusts its code and distrusts user input. An agent inverts part of this: the model itself decides what to do, and it forms those decisions from content it reads at runtime. That content — a GitHub issue, a scraped page, an email, a database row — can contain instructions. If the agent has a tool that can exfiltrate data or take a destructive action, an attacker who controls any input the agent reads can try to steer it. This is the confused deputy problem: the agent has authority the attacker lacks, and the attack is to borrow it.

Anthropic's own guidance for Claude Code and the Agent SDK leans hard on this: permissions, sandboxes, and human-in-the-loop gates exist because the model will, by default, try to be helpful to whatever instructions it encounters. Security is the layer that decides which of those instructions are allowed to become actions.

The practical consequence is that you should design as if the model will eventually be tricked, because at sufficient scale it will. Security that depends on the model never being fooled is not security; it's hope. Every meaningful control in this post — sandboxing, allowlists, scoped credentials, approval gates — shares one property: it works even if the model is fully under an attacker's influence on a given turn. That's the test to apply to any defense you add. If your answer to "what stops the bad action?" is "the model wouldn't do that," you don't have a control yet. If your answer is "the credential physically can't, the network has nowhere to send it, and a human has to approve," you do.

Defense in depth: how the layers fit

flowchart TD
  A["Untrusted input: web, file, tool result"] --> B["Claude proposes an action"]
  B --> C{"Tool in allowlist?"}
  C -->|No| D["Block & log"]
  C -->|Yes| E{"Least-privilege scope ok?"}
  E -->|Write/destructive| F["Require human approval"]
  E -->|Read-only| G["Run inside sandbox"]
  F --> G
  G --> H["No host, no secrets, scoped network"] --> I["Return result to context"]

Sandboxing and least privilege in practice

Sandboxing means the agent's tools execute somewhere they can't hurt you: a container without host filesystem access, with egress restricted to an allowlist, and with no ambient credentials. If an agent runs shell commands, it should run them in an ephemeral container scoped to the working directory, not on your laptop with your SSH keys mounted. Claude Code's permission and sandbox model exists precisely so that "run this command" doesn't mean "run anything, anywhere."

Least privilege is the schema-level twin of sandboxing. Each tool you expose should grant the minimum capability that completes its job. A reporting agent gets a read-only database role; it cannot issue DELETE because the credential it holds physically can't. Here's the principle expressed as a tool allowlist for an Agent SDK setup — write and network tools are simply absent for a read-only analyst agent.

{
  "agent": "data-analyst",
  "allowed_tools": ["sql_read", "read_file", "list_dir"],
  "denied_tools": ["sql_write", "shell", "http_post", "send_email"],
  "sql_read": { "role": "readonly", "row_limit": 5000 },
  "require_approval_for": ["any_write", "external_send"]
}

The point is that capability is denied by construction, not by hoping the model behaves. Even a perfectly prompt-injected agent cannot delete rows it has no permission to delete.

Secrets and prompt-injection defense

Secrets should never enter the model's context. If an API key is in the system prompt, a clever injection can ask the agent to print it, and it might. Instead, inject secrets at the tool-execution layer: the tool runner reads the key from the environment and uses it; the model only ever sees "called the API, here's the result." The model orchestrates; the runtime holds the credentials.

Prompt-injection defense is partly architectural and partly hygiene. Architecturally, the sandbox and allowlist mean a successful injection still can't do much. For hygiene: clearly delimit untrusted content in the prompt, instruct Claude to treat tool and web output as data rather than commands, and put a human approval gate in front of any irreversible action. No filter catches every injection, so the durable defense is that the agent simply lacks the authority to do the dangerous thing without a human saying yes.

A useful mental model is to separate the agent's two information streams. The control plane is your system prompt and rules — content you authored and trust. The data plane is everything the agent reads at runtime — files, pages, tool results, user messages — none of which you control. The cardinal sin is letting data-plane content be interpreted as control-plane instructions. Architecturally you can't fully prevent the model from blurring the line, so you compensate downstream: the actions reachable from data-plane influence are deliberately limited, and the high-authority actions live behind a gate the data plane can't reach. When you design tools, ask of each one: "if an attacker wrote the input that triggers this, what's the worst that happens?" If the answer is unacceptable, that tool needs a tighter scope or a human in front of it.

Common pitfalls

• Putting secrets in the prompt. Anything in context can be echoed. Keep keys in the runtime environment, never in the system prompt or tool descriptions.
• Broad write tools by default. Giving an agent a general shell or http tool grants enormous capability. Prefer narrow, purpose-built tools.
• Trusting tool output. A scraped page or a database row can contain injected instructions. Treat all retrieved content as untrusted data.
• No human gate on irreversible actions. Sending money, deleting data, or emailing customers should require explicit approval.
• Running tools on the host. Executing agent commands directly on a dev machine with mounted credentials defeats every other control.

Harden a Claude agent in six steps

1. Define an explicit tool allowlist; deny everything not on it.
2. Give each tool the narrowest scope — read-only roles, row limits, path restrictions.
3. Run all tool execution inside an ephemeral sandbox with restricted egress and no host access.
4. Inject secrets at the tool layer from the environment; keep them out of the model's context.
5. Delimit untrusted content and instruct Claude to treat tool/web output as data, not commands.
6. Require human approval before any irreversible or external-send action.

Controls mapped to threats

Frequently asked questions

What is prompt injection in an AI agent?

Prompt injection is an attack where untrusted content the agent reads — a webpage, file, or tool result — contains instructions that hijack the agent's behavior. The durable defense is least privilege and human approval gates, so even a hijacked agent can't perform a dangerous action on its own.

Where should I store secrets for a Claude agent?

In the runtime environment, read by the tool execution layer at call time — never in the system prompt, tool descriptions, or any context the model sees. The model should orchestrate API calls without ever holding the credentials itself.

Do I need a sandbox if I already have an allowlist?

Yes. The allowlist limits which tools exist; the sandbox limits what those tools can reach if one misbehaves or has a bug. They are complementary layers — defense in depth — and you want both for any agent that runs code or hits the network.

How do I handle irreversible actions safely?

Gate them behind explicit human approval. Sending money, deleting data, or contacting customers should never happen autonomously; route those actions to a confirmation step so a person signs off before the agent acts.

Secure agentic AI on your phone lines

The same least-privilege and sandboxing discipline that keeps a coding agent safe is what makes an automated voice agent trustworthy with real customer actions. CallSphere brings these agentic-AI patterns to voice and chat — assistants that use tools mid-call within tight, audited permissions. See it 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.