Securing Claude Code Agents: Sandboxing & Least Privilege

An agent is a program that decides what to do at runtime based on text it reads — and some of that text comes from places you don't control. That sentence should make any security engineer uneasy, and it should. A coding agent with shell access, file write permissions, and the ability to call external APIs is, from a threat-modeling standpoint, a remote-controlled operator inside your environment whose instructions are partly authored by whatever web page, ticket, or file it happens to read. Hardening Claude Code agents is about shrinking the blast radius of that uncomfortable fact.

This post walks through the layers that matter most: sandboxing the execution environment, designing tools around least privilege, keeping secrets out of the model's reach, and defending against prompt injection. None of these is optional once an agent touches anything that matters. Together they turn a powerful but dangerous capability into something you can actually run in production.

Threat-model the agent like a junior with shell access

Start by being honest about the trust boundary. Prompt injection is an attack where adversarial instructions hidden in content the agent reads — a web page, a file, an API response — hijack the agent into taking actions its operator never intended. Unlike SQL injection, there is no clean parser boundary that separates "data" from "instructions"; to a language model, it's all text. That means you cannot fully prevent injection at the prompt layer. You contain it at the capability layer.

The most useful mental model is to treat the agent as a capable but credulous junior engineer who will read every instruction it encounters and try to be helpful — including instructions planted by an attacker. You would not give that person unsupervised production database credentials and root on the build server. Apply the same instinct to the agent.

Sandbox the execution environment

The first hard boundary is the sandbox. Run agent-executed code in an isolated environment — a container or VM — with no standing access to anything it doesn't strictly need. Restrict the filesystem to a working directory. Restrict the network to an explicit allowlist of hosts, denying egress by default so a compromised run can't exfiltrate data to an arbitrary endpoint. Give the sandbox no ambient cloud credentials. The principle is that even if an attacker fully controls the agent's decisions, the sandbox limits what those decisions can reach.

flowchart TD
  A["Untrusted content enters context"] --> B["Agent proposes an action"]
  B --> C{"Action within sandbox & allowlist?"}
  C -->|No| D["Block & log"]
  C -->|Yes| E{"High-impact action?"}
  E -->|Yes| F["Require human approval"]
  E -->|No| G["Execute in sandbox"]
  F --> G
  G --> H["Return result; audit trail"]

Claude Code's hooks are the practical enforcement point for this. A pre-tool-use hook can inspect every proposed shell command or file write and block anything outside policy before it runs — no rm of paths outside the workspace, no curl to non-allowlisted hosts, no reads of dotfiles holding credentials. Because the hook sits at the boundary and not inside the model's reasoning, the model cannot talk its way past it. That is the whole point: enforcement must live where the model's persuasion can't reach.

Design tools for least privilege

The second layer is the tools themselves. Every tool you give an agent is a granted capability, and the aggregate of those capabilities is your attack surface. Design each tool to do exactly one thing with the narrowest possible scope. A tool that "runs arbitrary SQL" is a liability; a tool that "looks up an order by ID and returns its status" is a capability you can reason about. Prefer read-only tools wherever the task allows, and split read from write so the dangerous operations are few and individually auditable.

Scope credentials to match. The service account behind an agent's database tool should have permission to read the three tables it needs and nothing more — no DROP, no access to the secrets table, no write to billing. If the agent is compromised, least privilege is what stands between a bad day and a breach. And gate genuinely high-impact actions — deleting data, sending money, emailing customers, deploying — behind explicit human approval rather than letting the agent perform them autonomously.

Keep secrets out of the model's context

Secrets are a special case because language models are leaky by nature: anything in the context can end up in the output, and outputs can end up in logs, in a returned message, or in an attacker's hands via injection. The rule is simple — the model should never see raw secrets. Don't paste API keys or database passwords into prompts or tool descriptions. Instead, have the tool implementation hold the credential and inject it at call time, outside the model's view. The agent says "call the payments API"; your code attaches the key. The model orchestrates capabilities without ever holding the keys to them.

Apply the same caution to tool output. If a tool can return data containing secrets or PII, redact at the tool boundary before the result re-enters the context. Once a secret is in the conversation history it is effectively public to the rest of the run, so the cheapest place to stop a leak is before it ever arrives.

Defend against prompt injection in depth

Because you can't fully prevent injection, you defend in depth. Clearly delimit untrusted content in the prompt and instruct the model to treat anything inside those bounds as data, not commands — this raises the bar even if it isn't a guarantee. Pair it with the structural defenses above: a sandbox so a hijacked agent can't reach much, least-privilege tools so it can't do much, human approval on the irreversible steps, and a full audit log so you can detect and reconstruct anything that slips through. Run adversarial evals that deliberately plant injection payloads in tool outputs and confirm the agent's capabilities stop it, not just its instructions. Security that depends on the model choosing to behave is not security; security that holds even when the model is fully manipulated is.

Frequently asked questions

What is prompt injection and can I prevent it entirely?

Prompt injection is when adversarial instructions hidden in content the agent reads hijack it into unintended actions. Because a language model can't cleanly separate data from instructions, you can't fully prevent it at the prompt layer — you contain it with sandboxing, least-privilege tools, human approval on risky actions, and auditing.

How should an agent handle secrets?

The model should never see raw secrets. Keep API keys and passwords in your tool implementation and inject them at call time, outside the model's context. Redact any secrets or PII in tool output before the result re-enters the conversation, since anything in context can leak into outputs and logs.

Why sandbox if I already write careful prompts?

Prompts can be overridden by injected instructions; a sandbox cannot be talked out of its restrictions. Enforcement that lives at the capability boundary — isolated filesystem, network allowlist, no ambient credentials, pre-execution hooks — holds even when the model is fully manipulated, which prompt-level defenses don't.

What does least privilege mean for agent tools?

Each tool should do one narrowly-scoped thing, prefer read-only access, and run under credentials limited to exactly what it needs. High-impact actions like deleting data or sending money should require human approval. The smaller and sharper your tool set, the smaller your attack surface.

Secure agentic AI on your phone lines

Sandboxing, least privilege, and injection defense matter just as much when an agent is talking to real callers and touching real systems. CallSphere brings these hardened agentic-AI patterns to voice and chat — assistants that answer every call, use tools mid-conversation, and book work safely, 24/7. See it live 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.