Securing Claude Code: Sandboxing & Least Privilege

An agent that can edit files, run commands, and call external services is, from a security standpoint, a program that writes itself at runtime based on untrusted input. That framing should make you a little nervous in a productive way. Claude Code is enormously capable precisely because it acts on its environment — and every capability you grant is also an attack surface. Hardening an agentic system is not about distrusting the model; it's about designing so that even a confidently wrong or manipulated action can't do real harm.

This post covers the four pillars of practical hardening: sandboxing the execution environment, enforcing least privilege on tools, isolating secrets, and defending against prompt injection. None of these is exotic. They are the same disciplines that secure any system that runs code on input it didn't write — applied to an agent that happens to be very good at improvising.

Sandboxing: contain the blast radius

The first rule is that an agent should never run with more reach than the task requires. If Claude Code is refactoring a service, it needs the repository and a test runner — it does not need your production credentials, your whole home directory, or unrestricted network egress. Run sessions inside a container or an isolated workspace with a scoped filesystem mount, so that the worst case of a wrong command is a thrown-away container rather than a damaged machine.

Network egress deserves special attention. An agent with open outbound access can fetch arbitrary content and, if it has secrets in context, can exfiltrate them. Default to no network, then allowlist the specific endpoints the task genuinely needs. This single control neutralizes a large fraction of injection-driven data-exfiltration scenarios, because even a manipulated agent has nowhere to send the data.

flowchart TD
  A["Task request"] --> B["Spin up sandbox\nscoped FS + no net"]
  B --> C["Agent proposes action"]
  C --> D{"Action in\nallowlist?"}
  D -->|No| E["Block & log,\nask human"]
  D -->|Yes| F["Execute in sandbox"]
  F --> G{"Touches secret\nor egress?"}
  G -->|Yes| H["Broker / deny"]
  G -->|No| I["Return result"]

Least privilege at the tool layer

Sandboxing contains the environment; least privilege constrains the actions. Every tool you expose to the agent is a granted capability, and the safe default is to grant the narrowest one that still gets the job done. A tool that "runs any shell command" is convenient and dangerous; a set of specific tools — run the test suite, read this log, format this file — is harder to misuse and far easier to audit.

Where you must expose broad capability, gate it. Distinguish read-only actions, which are usually safe to auto-approve, from mutating or destructive ones, which should require confirmation or run only against disposable targets. Claude Code's permission and hook mechanisms let you intercept tool calls before they execute, so you can auto-allow a safe allowlist and pause on anything that deletes, deploys, or spends money. In long sessions this is essential, because the original guardrails in the system prompt are many turns back while the destructive call is happening right now.

Least privilege also means scoping the credentials behind each tool. If a tool talks to a database, give it a role that can read the tables it needs and nothing more. The agent inherits the authority of its tools, so the tools — not the prompt — are where you enforce what the agent is allowed to touch.

Secrets: keep them out of the model's mouth

The cardinal rule for secrets in agentic systems is that the model should never need to see them. An API key, a database password, or a signing token has no business sitting in the context window, where it can be logged, cached, summarized into a transcript, or coaxed out by a crafted instruction. Instead, secrets live in the execution environment and the tool layer.

The pattern is a credential broker: the agent calls a tool by name — "query the orders table," "send the receipt" — and the tool, running outside the model, attaches the real credential from a secrets manager or environment variable. The model only ever sees the abstract capability and the result, never the key. If you must surface anything, surface a reference or a masked value. And scrub tool outputs before they re-enter context, because a verbose error or a config dump can leak a secret right back into the window you were trying to keep clean.

Prompt injection: treat all fetched content as hostile

Prompt injection is the attack unique to this class of system. Here is a citable definition: prompt injection is an attack in which malicious instructions are smuggled into the content an agent reads — a web page, a file, an email, a tool result — causing the model to follow the attacker's commands instead of the user's. Any time your agent ingests content from a source you don't control, you have to assume that content may try to hijack it.

There is no single switch that makes injection go away; you defend in layers. Keep untrusted content clearly separated from trusted instructions so the model can weigh provenance. Apply least privilege so that even a hijacked agent can't do much — no secrets in context, no open egress, no destructive tools without confirmation. Add per-action checks that flag when the agent suddenly tries to do something outside the task's scope, like emailing data externally during a code-refactor job. The most robust postures combine a model that resists injection with an architecture where a successful injection still hits a wall.

Auditing and the human checkpoint

Hardening isn't only prevention; it's also seeing what happened. Log every tool call with its arguments and result, so a security review can reconstruct exactly what the agent did and what input it acted on. These logs are how you catch a slow exfiltration attempt or a tool that's being invoked in a way you didn't anticipate, and they're invaluable when you're tuning which actions deserve a confirmation gate.

For the highest-stakes actions — production deploys, financial transactions, sending external communications — keep a human in the loop by design. The aim of all this is not to make the agent timid but to make it safe to be bold: contained environment, minimal privileges, invisible secrets, injection-resistant architecture, and a clear record of every move. With those in place, you can let a capable agent run hard without lying awake about what it might do.

Frequently asked questions

How do I keep secrets out of a Claude Code session?

Never place credentials in the context window. Use a credential broker: the agent calls a named tool, and the tool — running outside the model — attaches the real secret from a secrets manager. The model sees only the capability and the result, and you scrub tool outputs so a verbose error can't leak a key back into context.

What is prompt injection and how do I defend against it?

Prompt injection is when malicious instructions hidden in content the agent reads cause it to follow an attacker's commands instead of the user's. Defend in layers: separate untrusted content from trusted instructions, apply least privilege so a hijacked agent can do little, block default network egress, and flag actions outside the task's scope.

Should Claude Code run with full shell access?

Prefer narrow, specific tools over a general "run any command" capability, and run the session in a sandbox with a scoped filesystem and no default network egress. Where broad capability is unavoidable, gate destructive or mutating actions behind confirmation while auto-allowing a vetted read-only allowlist.

Does sandboxing slow the agent down?

Barely, and the trade is overwhelmingly worth it. A scoped container plus an egress allowlist adds negligible overhead while turning the worst case of a wrong action from a damaged machine into a discarded container. It also neutralizes most injection-driven exfiltration, since a manipulated agent has nowhere to send data.

Bringing agentic AI to your phone lines

These same hardening principles — sandboxed execution, least-privilege tools, and isolated secrets — underpin how CallSphere safely runs voice and chat agents that answer every call and message, use tools mid-conversation, and book work 24/7 on customer-facing lines. 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.