Claude Agent Security: Claude Code Security, Agent SDK Hardening, and Runtime Controls

This is the honest inventory, taken from Anthropic's own security documentation rather than from a comparison chart. If you are evaluating Claude Code, assume all of it is on before you add anything.

Anthropic closes its security page with a line worth quoting to anyone who thinks a vendor default is a finished control: "While these protections significantly reduce risk, no system is completely immune to all attacks." That is the correct posture, and it is also the argument for defense in depth.

Every item here is a consequence of how the product is designed for a single developer, not a defect. They become problems at the point where an organisation, rather than an individual, has to answer for the deployment.

• The approval gate assumes somebody is watching. Fail-closed matching, trust verification, and command injection detection all resolve to a prompt. In an interactive terminal that is a real control. In a scheduled job, a CI pipeline, or a headless Agent SDK service, there is nobody to answer it, and teams reach for broader allow rules or the flag that skips permissions entirely to make the job run.
• Trust verification is off in the mode CI uses. Anthropic documents that trust verification is disabled when running non-interactively with the -p flag. That is precisely the mode automation runs in, which means the check that would have flagged a new MCP server or an unfamiliar codebase is not running where the human review is also absent.
• Configuration is per repository and owned by engineering. Allow rules live in settings files checked into source control. Loosening one is an ordinary-looking pull request reviewed by application reviewers. Nothing about the diff announces itself as a policy change, and there is no fleet-wide view of what the current effective policy is.
• Read access is the underrated risk. Anthropic's deployment guide lists the files that leak even under a read-only mount: .env files, git credentials, AWS and Google Cloud credential files, kubeconfig, npm and PyPI tokens, and private keys. An agent that can read those and reach the network does not need write access to hurt you.
• The sandbox shares a kernel and does not inspect TLS. Anthropic says both things directly. Sandboxed processes share the host kernel, so a kernel bug is an escape path, and the built-in proxy allowlists domains by the hostname the client supplied without terminating TLS, so code inside the sandbox can potentially reach hosts outside the allowlist.
• Logs are developer logs. OpenTelemetry metrics tell you usage. They are not an append-only, per-decision record of which tool call was requested, whether policy allowed it, and who owned the agent that asked. That distinction is the whole of agent audit trail.

None of this argues against running Claude Code. It argues for putting a control point where the developer's configuration is not the last word. The general version of that argument is on AI runtime security, and the coding-agent-specific version is on securing coding agents.

When you build on the Claude Agent SDK, your agent runs on your infrastructure and the terminal prompt disappears. Anthropic publishes a deployment guide for exactly this case, and it is refreshingly unromantic: the same principles that apply to running any semi-trusted code apply here, meaning isolation, least privilege, and defense in depth. The four isolation technologies it compares, with the tradeoffs Anthropic itself gives:

The single most useful pattern in that guide is not an isolation technology at all. It is the credential proxy. Rather than handing the agent an API key, you run a proxy outside the agent's boundary that injects the credential into outbound requests. The agent can call the API and never sees the secret, the proxy enforces an endpoint allowlist, and every request is logged in one place. Combined with a container started with no network interfaces at all, where the only route out is a mounted Unix socket to that proxy, a compromised agent cannot exfiltrate to an arbitrary server because it has nowhere to send it.

One practical trap: not every program respects the proxy environment variables. Anthropic notes that Node.js fetch ignores them by default, and that Node 24 and later need an explicit environment flag to honour them. An agent that bypasses your proxy is an agent outside your allowlist. Broader guidance on isolating agent execution is on AI agent sandboxing, and the step-by-step version is in how to sandbox an AI agent.

Claude Code connects to Model Context Protocol servers, and this is the sharpest boundary in the whole product. Anthropic's security documentation draws it explicitly: Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server. Directory presence is a listing decision, not a security assurance, and anything you add yourself carries no review at all.

That matters because tool descriptions are prompt input. Invariant Labs documented tool poisoning in April 2025 as malicious instructions embedded within MCP tool descriptions that are invisible to users but visible to AI models, with a proof of concept that exfiltrated a Cursor MCP config file and an SSH private key. The Cloud Security Alliance followed in July 2026 with a study of more than 45 real-world MCP servers reporting attack success rates above 60 percent and peaking at 72.8 percent. CVE-2025-54136, rated CVSS 8.8, captured the structural version of the problem: approving a tool definition once does not bind the server to that definition later.

Three controls close most of it, and only the first is native to Claude Code. Keep your allowed server list in version control, as Anthropic recommends, so adding a server is a reviewed change. Pin tool definitions by SHA-256 hash so a silent server-side rewrite fails instead of executing. And treat everything an MCP server returns as untrusted content that gets inspected before the agent acts on it, which is the same rule you apply to a fetched web page. The full treatment is on MCP server security, and the architecture that enforces it centrally is on MCP gateway.

This is the sequence we recommend to teams running Claude Code or Agent SDK services at more than one team's worth of scale. The first four are Anthropic's own guidance and cost nothing but an afternoon.

1. Turn on managed settings. Organisation-level policy files apply across users instead of relying on each engineer's local configuration. Pair them with ConfigChange hooks so settings edits during a session are audited or blocked outright.
2. Enable the bash sandbox before you widen allow rules. Teams usually loosen permissions to stop the prompts. Sandboxing removes most prompts without removing the boundary, which is the trade you actually wanted.
3. Sanitize what you mount. Exclude .env files, cloud credential directories, kubeconfig, registry tokens, and private keys from anything the agent can read, including read-only mounts. Copy in the source files needed rather than mounting a home directory.
4. Put credentials behind a proxy. The agent should be able to call the service without ever holding the key. This is the highest-value change in the entire Anthropic deployment guide and it also gives you a single log of outbound calls.
5. Give each agent its own identity. Not native to Claude Code, where an agent inherits whatever the launching developer or service account holds. Without it, attribution afterwards is guesswork. See AI agent identity.
6. Treat headless runs as a separate risk tier. Anything running with the -p flag has no trust verification and no human to approve a prompt. Give those runs their own narrower policy rather than the interactive one.
7. Gate irreversible actions on a human. Production writes, deletions, payments, and outbound messages should stop for approval regardless of which repository the agent was launched from. See human in the loop AI agents.
8. Run in observe mode first. Two weeks of watching what your Claude agents actually call is worth more than a policy written from imagination, and it makes the switch to enforce uneventful. See tool permissions.
9. Keep one trail across every agent. One append-only record covering Claude Code, Agent SDK services, and anything built on another framework, so a question about last Thursday has one place to be answered.

Steps one through four are configuration you should do today whether or not you ever buy anything. Steps five through nine need a control point outside the agent process, because each one is a property no per-repository setting can guarantee across teams.

Teams rarely run one framework. The useful comparison is not which is safest but which controls each one gives you for free, so you know what you are still on the hook for. If the other tool in your estate is Google's, the equivalent inventory is on Gemini CLI security, and we compare the two directly in Gemini CLI vs Claude Code.

Claude wins the top half of that table outright, and it is worth choosing on those grounds. The bottom three rows are identical for both, and they are the rows a security owner is judged on. That is the gap we fill, and we fill it the same way for both, which is the point of being stack-neutral. If OpenAI is the third framework in your estate, the equivalent breakdown of its guardrail scoping rules is on OpenAI agent security.