Securing Claude agents: sandboxing, least privilege, injection (Enterprise AI Transformation Claude)

The moment a Claude agent gains the ability to act — run code, hit APIs, send email, write to a database — it stops being a chat assistant and becomes a piece of privileged software that takes instructions from natural language. That combination is powerful and dangerous. An agent that reads a web page, a support ticket, or a PDF is reading text that an attacker may have written, and that text can try to redirect the agent's behavior. Security hardening for agents is not a nice-to-have you bolt on before launch; it is the architecture you build around the model from day one. This post lays out the four pillars — sandboxing, least privilege, secrets handling, and prompt-injection defense — with concrete patterns for Claude.

Key takeaways

• Treat every agent as untrusted code with a network connection — sandbox its execution and tool access by default.
• Apply least privilege at the tool level: each agent gets only the specific, scoped tools it needs, nothing more.
• Never put secrets in the prompt or context; inject them at the execution boundary, outside what the model can see or emit.
• Prompt injection is the defining agent threat — any tool that ingests external content can carry adversarial instructions.
• Defense is layered: isolate untrusted content, require human approval for high-impact actions, and validate every tool call before it runs.

Pillar 1: sandboxing

The first principle is that an agent's actions should happen inside a box you control. If the agent can run shell commands or code, it should do so in an isolated environment — a container or microVM with no access to the host filesystem, no ambient cloud credentials, and a tightly restricted network egress allowlist. Claude Code and the Agent SDK are designed to run tools through a controlled execution layer precisely so you can interpose these boundaries.

The reason matters: even a perfectly aligned agent can be manipulated into running something harmful if it processes attacker-controlled input. Sandboxing means that when — not if — something slips through your other defenses, the blast radius is contained to a disposable environment rather than your production network. Design the sandbox so that the worst case is "the agent did something useless in a throwaway container," not "the agent exfiltrated the database."

Concretely, that means no shared mounts into sensitive directories, no inherited cloud instance roles, a non-root user, an explicit egress allowlist of the few hosts the task legitimately needs, and a hard timeout and CPU cap so a runaway process dies on its own. Treat each agent run as disposable: spin up a fresh environment, let it do its work, capture the output, and tear it down. The discipline that protects a multi-tenant CI system is exactly the discipline an agent needs, for the same reason: you are executing instructions you did not fully write.

Pillar 2: least privilege

Least privilege is the practice of giving the agent the narrowest set of capabilities that lets it do its job, and nothing else. For agents this is concrete and enforceable because capabilities are tools. A support-triage agent should have read_ticket and categorize_ticket — not delete_user, not issue_refund, not a generic run_sql. The smaller the tool surface, the smaller the set of things any injection can ever accomplish.

flowchart TD
  A["External content enters tool result"] --> B{"Trusted source?"}
  B -->|Yes| C["Use normally"]
  B -->|No| D["Tag as untrusted, isolate"]
  D --> E["Agent proposes tool call"]
  C --> E
  E --> F{"High-impact action?"}
  F -->|No| G["Validate args & run in sandbox"]
  F -->|Yes| H["Require human approval"]
  H --> G
  G --> I["Log & return result"]

Scope tools tightly at definition time. Instead of one omnipotent database tool, expose narrow, parameterized operations with server-side authorization. A good rule: if you would not hand the capability to a brand-new contractor on day one without supervision, do not hand it to an autonomous agent without an approval gate.

Pillar 3: protect secrets

Secrets — API keys, tokens, database passwords — must never live in the prompt, the system message, or anywhere in the context window. Anything in the context can be reflected back in the model's output, logged, or coaxed out by injection. The correct pattern is to keep secrets entirely outside the model's awareness: the agent calls a tool by name, and your execution layer attaches the credential when it makes the real API call.

# Agent sees ONLY this — no key anywhere in context
{ "name": "send_email", "arguments": { "to": "a@b.com", "subject": "..." } }

# Your runtime injects the secret at the boundary:
def execute_send_email(args):
    return mail_api.send(**args, api_key=os.environ["MAIL_API_KEY"])  # key never in prompt

The model orchestrates; your code holds the keys. This separation also means a leaked transcript is not a leaked credential, which is a meaningful difference when transcripts are logged for debugging and evals.

Pillar 4: defend against prompt injection

Prompt injection is the threat unique to LLM agents, and it is worth defining precisely. Prompt injection is an attack where adversarial instructions are hidden inside content the agent processes — a web page, an email, a document, a code comment — causing the agent to take actions the user never intended. Because Claude is built to follow instructions, instructions embedded in data it reads can compete with your legitimate ones.

There is no single switch that eliminates this; defense is layered. Isolate untrusted content so the model treats it as data, not commands — wrap it in clear delimiters and tell Claude that anything inside is untrusted input to analyze, never to obey. Require human approval for irreversible or high-impact actions, so even a successful injection cannot ship money or delete data on its own. Validate every tool call against policy before execution. And constrain the tool surface with least privilege so the upside of any injection is small. Layered, these turn injection from a catastrophe into a contained nuisance.

It is worth internalizing why no single layer suffices. You cannot prompt your way to safety, because the same instruction-following that makes Claude useful is what an injection exploits; a system message saying "ignore malicious instructions" helps at the margin but is not a boundary. You cannot validate your way to safety either, because a cleverly worded request can be both syntactically valid and semantically harmful. Defense in depth works precisely because an attacker now has to defeat isolation, evade validation, slip past a human approver, and find a capability worth abusing — all at once. That conjunction is hard, which is the whole point.

Common pitfalls

• Trusting tool output. A web page or email returned by a tool is untrusted data, not a trusted instruction. Tag and isolate it.
• One do-everything tool. A generic run_sql or run_shell gives injection unlimited reach. Expose narrow, authorized operations.
• Secrets in the system prompt. Anything in context can leak. Inject credentials at the execution boundary only.
• Auto-approving high-impact actions. Refunds, deletes, and outbound messages deserve a human-in-the-loop gate.
• No egress controls in the sandbox. Unrestricted network access turns a contained agent into an exfiltration path. Allowlist destinations.

Harden an agent in 6 steps

1. Run all tool/code execution in an isolated sandbox with no host access and allowlisted egress.
2. Define tools at minimum scope; remove any capability the agent does not strictly need.
3. Move all secrets out of context and inject them only at the execution boundary.
4. Tag content from external sources as untrusted and isolate it from instructions.
5. Add human-approval gates for irreversible or high-impact tool calls.
6. Validate and log every tool call against an explicit policy before it runs.

Frequently asked questions

What is prompt injection in the context of agents?

Prompt injection is an attack where malicious instructions are embedded in content an agent processes — a web page, email, or document — causing it to take unintended actions. Because Claude follows instructions, text inside the data it reads can compete with your legitimate ones, so untrusted content must be isolated as data and never treated as commands.

Where should I store API keys for a Claude agent?

Never in the prompt, system message, or context window, since anything there can be logged or leaked. Keep secrets in your runtime environment and attach them only at the execution boundary, where your code makes the real API call. The model references a tool by name; your code supplies the credential.

How do I apply least privilege to an AI agent?

Treat tools as capabilities and give each agent only the specific, scoped tools its job requires. Replace broad tools like a generic database or shell tool with narrow, server-authorized operations, and add human-approval gates for high-impact actions. The smaller the tool surface, the less any compromise can achieve.

Is sandboxing enough on its own?

No. Sandboxing contains the blast radius but does not prevent the agent from being manipulated. Combine it with least privilege, secret isolation, and prompt-injection defenses so that even a successful manipulation has minimal capability and a small, contained impact.

Secure agents on every call

Hardening matters even more when an agent talks to the public. CallSphere builds sandboxed, least-privilege voice and chat agents that use real tools mid-conversation while keeping secrets and high-impact actions locked behind controls. See the approach in action 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.