Claude Code Security Hardening Guide

The short version

Claude Code security, like security for any local coding agent, comes down to one structural fact: the agent reads untrusted content while holding real authority. A repository, an issue thread, or a web page can carry instructions aimed at the agent, and the agent can act on your machine. Every control in this guide narrows one side of that combination.

The six controls that matter: treat project content as untrusted input, run with least privilege, protect the agent's own configuration files, keep credentials out of reach, constrain network egress, and keep an audit trail. None require abandoning the tool; all reduce what a successful injection can do.

Citable answer

Securing Claude Code and similar local coding agents means treating repositories and web content as untrusted input, scoping permissions per task instead of globally, protecting agent configuration files from self-modification, keeping long-lived credentials out of the agent's reach, constraining network egress, and keeping an audit log of agent actions. The threat model is indirect prompt injection: hostile instructions in content the agent reads, converted into actions the agent is authorized to take. For OpenClaw agents, Clawmont packages these controls as a local-first runtime security layer.

The attack that actually happens

The canonical demonstration is the poisoned repository. 0DIN's "clone this repo and I own your machine" research showed that project files can steer a coding agent into executing attacker-chosen commands during what looks like routine work. No exploit in the traditional sense is involved; the agent does what the content asks, because reading content is its job.

Security reporting through 2026 documents the same shape in the wild, including a case where a coding agent was steered into opening a reverse shell, one helpful-looking step at a time; TechRadar Pro summarized the expert warning as Claude Code being exploitable "simply by trying to be helpful." We analyzed all 22 published Claude Code security advisories in a companion post; the recurring lesson is that the dangerous decision happens at runtime, after static review says the project looks clean.

OWASP calls the underlying condition excessive agency: authority beyond what the task needs. The fix is not to distrust the model but to engineer the environment so that a hijacked agent has less to steal and fewer places to send it.

The hardening checklist

Treat every repository as untrusted input

A cloned repo is content your agent reads: READMEs, configs, scripts, and comments can all carry instructions aimed at the agent rather than at you. Open unfamiliar projects with the same caution you would give an email attachment, and review what the agent is asked to read before it reads it.

Run with the narrowest permissions that finish the task

Coding agents ship permission prompts and allowlists for a reason. Approve tools per task instead of globally, avoid blanket always-allow settings, and separate the environment where the agent works from the environment that holds production credentials.

Protect configuration files that change agent behavior

Agent settings files, hook definitions, and startup scripts are an escalation path: content that convinces an agent to edit its own configuration can turn one bad read into persistent code execution. Watch writes to these paths and review any diff that touches them.

Scope credentials away from the agent

Long-lived tokens in environment variables or dotfiles are exactly what exfiltration attacks look for. Use short-lived credentials, keep production secrets out of the agent's reachable filesystem, and assume anything readable can end up in a tool call.

Constrain network egress

Most exfiltration leaves through an ordinary-looking web request. Sandboxed or containerized execution with an egress allowlist limits where data can go, and unusual destinations become visible instead of silent.

Keep an audit trail of agent actions

When something looks wrong after the fact, the questions are always the same: what did the agent read, what did it run, and where did data go? If your setup cannot answer those from a log, harden the logging before adding more autonomy.

Why prompts and vigilance are not enough

Permission prompts are a real control, and approval fatigue is their real failure mode. After the fortieth prompt of the day, approval becomes a reflex, which is precisely what a patient injection exploits: each requested action looks reasonable, and the harm lives in the sequence. Microsoft's incident-response guidance makes the same point at the enterprise scale: individual agent actions routinely look legitimate while the chain is malicious.

That is the argument for automated checks at the action boundary, whatever agent you run: something that inspects the proposed command, the outbound destination, and the touched paths without getting tired. Human review scales badly against an attacker who only needs you to skim once.

Test your hardening before an attacker does

Hardening you have never exercised is a hypothesis, not a control. The cheap way to test it is a canary project: a scratch repository containing a harmless planted instruction, such as a README that asks the agent to write a marker file into a directory you consider protected, or to fetch a domain you never use. Run your normal workflow against it and check three things: the action was blocked or at least surfaced for approval, your audit trail recorded what was attempted and why, and nothing credential-shaped moved.

Then make the canary run a habit, not a one-off. Repeat it whenever the agent's configuration changes: a new MCP server, a widened allowlist, a permission set to always-allow during a long session. Configuration drift is how hardening quietly erodes, which is the posture problem we cover in our AI security posture management post. The checklist above sets the boundary; the canary tells you it still holds.

Where Clawmont fits

Honest scoping first: Clawmont does not plug into Claude Code. Clawmont is a runtime security layer for OpenClaw agents. If your agent workflow runs through OpenClaw, Clawmont applies this checklist automatically at the gateway: it inspects inputs, proposed tool calls, tool results, and outputs, watches config-write escalation paths, screens credential-shaped content, and keeps a tamper-evident local audit log. Your API keys never leave your machine.

The broader picture of what runtime protection can and cannot do, including our measured detection rates and their honest limits on novel attacks, is on the security page, and the general category comparison lives in AI agent security. Clawmont Security is $9.99/mo bundled with a persona or $19.99/mo standalone, with a 7-day free trial; see pricing.

Source context

These sources ground the threat model: proof-of-concept research on poisoned repositories, journalism documenting real exploitation of helpful coding agents, and the OWASP and incident-response framing that explains why the fix is environmental rather than behavioral.

FAQ

Is Claude Code safe to use?

Claude Code ships real safety mechanisms: permission prompts, allowlists, and sandboxing options. The residual risk is structural to all coding agents: the agent reads untrusted content (repos, issues, web pages) while holding real authority (shell, filesystem, network). Safety depends on how you configure and supervise it, which is what a hardening checklist is for.

What is the most common attack on coding agents?

Indirect prompt injection through project content. Researchers have shown that a cloned repository can carry instructions that steer an agent into running attacker-chosen commands, and security reporting through 2026 documents the same pattern: each step looks like the agent being helpful, and the sum is compromise.

Does this checklist apply to other coding agents?

Yes. The threat model is shared by Claude Code, other CLI coding agents, and agent runtimes like OpenClaw: untrusted content in, real authority out. The mechanisms differ per tool, but the six controls (untrusted-input discipline, least privilege, config protection, credential scoping, egress limits, audit evidence) transfer directly.

Where does Clawmont fit?

Clawmont does not run inside Claude Code. It is a runtime security layer for OpenClaw agents: it applies these same controls automatically at the gateway, checking inputs, tool calls, tool results, and outputs, watching config-write escalation paths, and keeping a tamper-evident audit log. If you run agents through OpenClaw, it is the packaged version of this checklist.

Claude Code Security: A Practical Hardening Guide for Local Coding Agents