Security hardening for Claude Code agents in production

The moment my Claude Code app stopped being a toy was the moment it could touch real things — a database with real customer rows, an outbound email tool, a filesystem with real files. That is also the moment security stopped being theoretical. An agent that can take actions on your behalf is, by definition, a system that can take harmful actions if it is confused, manipulated, or simply wrong. As a non-technical founder, I had to learn that giving an agent autonomy without giving it boundaries is not a shortcut — it is a liability waiting to be triggered.

Why agents need a different security model

Traditional software does exactly what it is coded to do. An agent decides what to do at runtime based on language, which means its behavior can be steered by language — including language that arrives from untrusted sources. A document the agent reads, a web page it fetches, a customer message it processes: any of these can contain instructions aimed at the agent rather than at you. This is the core of prompt injection, and it is the failure mode that has no analog in conventional code. The defense cannot be "write the agent perfectly"; it must be "assume the agent can be fooled and limit the blast radius when it is."

Prompt injection is an attack where malicious instructions embedded in content the agent processes cause it to take actions the user never intended. Once you internalize that any input the agent reads might be adversarial, the whole design shifts toward containment: least privilege, sandboxing, and strict boundaries around anything dangerous.

Least privilege: the agent only gets what the task needs

The first principle I applied was least privilege, the same one good engineers apply to any system. The agent should hold only the permissions the current task requires, and no more. My early mistake was handing the agent a broad, all-powerful toolset because it was convenient. The fix was scoping. A read-only task gets read-only tools. A task that should only touch one table gets a tool that can only query that table. A drafting task can compose an email but cannot send it without a separate, gated step.

Claude Code's permission model and hooks make this enforceable rather than aspirational. You can require explicit approval for sensitive actions, restrict which commands or paths a tool may touch, and deny by default. Agent Skills help too, because a skill ships a curated toolset — the agent loads exactly the capabilities a task needs and nothing else. Narrowing what the agent can do is far more reliable than instructing it about what it should not do.

flowchart TD
  A["Untrusted input reaches agent"] --> B{"Action requested?"}
  B -->|Read-only| C["Allow in sandbox"]
  B -->|Mutating or external| D{"Within least-privilege scope?"}
  D -->|No| E["Deny & log"]
  D -->|Yes| F{"High-risk action?"}
  F -->|Yes| G["Require human approval"]
  F -->|No| H["Execute with scoped creds"]
  G --> H
  H --> I["Audit log"]

Sandboxing: contain what the agent can reach

Least privilege limits which tools the agent holds; sandboxing limits what those tools can reach. I ran the agent's code execution and file access inside a constrained environment with no path to production credentials, no broad network egress, and a clearly bounded filesystem. The point is simple: even if the agent is manipulated into trying something destructive, it should be physically unable to reach anything important. A sandbox turns a potential catastrophe into a contained, observable event.

Network access deserves special attention because it is the channel through which both injected instructions arrive and exfiltrated data could leave. I restricted outbound access to a known allowlist of endpoints the app genuinely needs. That single control closes off the most common exfiltration path — an injected instruction telling the agent to POST your data somewhere — because the destination simply is not reachable from inside the sandbox.

Secrets: never put credentials where the model can see them

The most important rule I learned about secrets is that the model should never see them at all. API keys, database passwords, tokens — none of these belong in the prompt, the context, or anywhere the agent can read and accidentally repeat. Instead, secrets live in the environment or a secret manager, and tools use them internally. The agent asks a tool to send an email; the tool reads the credential and sends it; the agent never touches the key. If the model cannot see a secret, no amount of clever injection can make it leak it.

This boundary is easy to violate by accident. Logging a full prompt that happened to include a token, echoing an environment variable into context, returning a raw error that embeds a connection string — all of these quietly expose secrets. I added a scrubbing step to logging and made tools return sanitized errors. Treat any path where text leaves the system — logs, error messages, responses — as a place a secret could escape, and close each one.

Defending against prompt injection in practice

You cannot make an agent immune to manipulation, so the strategy is layered defense plus containment. First, separate trusted instructions from untrusted data: the agent's actual instructions come from you, and content it reads is clearly framed as data to analyze, not commands to obey. Second, gate consequential actions behind confirmation so that even a successfully injected instruction cannot, say, delete records or send mail without a human in the loop. Third, validate and constrain outputs — an agent that should only return a category cannot be tricked into returning a shell command if the tool boundary rejects anything that is not one of the allowed categories.

The combination matters more than any single control. Injection might slip past your framing, but if the dangerous action is gated and the environment is sandboxed and the credentials are out of reach, the attack lands on nothing. Security for agents is not about a perfect prompt; it is about ensuring that when the prompt fails — and eventually it will — the damage is bounded, logged, and recoverable.

Frequently asked questions

Can I fully prevent prompt injection?

No, and any tool that promises immunity should be treated skeptically. Because agents act on language, language can manipulate them. The realistic goal is to make injection inconsequential: least privilege, sandboxing, gated actions, and secrets the model never sees, so that a successful injection has nothing valuable to reach.

Where should API keys and passwords live?

In environment variables or a secret manager that tools read internally — never in the prompt or context. The agent should invoke a tool that uses the credential without ever seeing the credential itself. Also scrub logs and error messages so secrets cannot escape through those side channels.

Which actions should require human approval?

Anything irreversible or externally visible: deleting data, sending messages to real people, moving money, changing permissions. Read-only and easily reversible actions can run autonomously inside the sandbox. Gating the small set of genuinely dangerous actions gives you most of the safety with minimal friction.

How does least privilege differ from sandboxing?

Least privilege limits which tools and permissions the agent holds; sandboxing limits what those tools can physically reach — filesystem, network, credentials. They are complementary layers. Least privilege reduces the chance of a bad action; sandboxing reduces the impact when one slips through anyway.

Bringing agentic AI to your phone lines

Sandboxing, least privilege, and injection defense matter just as much when an agent is talking to real callers and acting on their behalf. CallSphere builds these same security patterns into its voice and chat agents, so they use tools safely, stay within scope, and protect customer data on every call. 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.