Claude Code security best practices for agentic coding tools

At a glance

What this is: Backslash Security explains how Claude Code in the terminal expands attack surface through filesystem access, command execution, dependency installation, and API connectivity when permissions are too broad.

Why it matters: IAM, PAM, and NHI teams should read this as a reminder that agentic developer tools need runtime authorisation boundaries, not just policy and code review.

Context

Claude Code is not just a code assistant. In the article’s threat model, it behaves like an operator inside the developer terminal because it can read files, run commands, install dependencies, and modify configuration with the developer’s permissions.

That changes the identity problem around the development workstation and the IDE itself. The control question is no longer only whether a person intended an action, but whether a tool with broad runtime access can be constrained before it touches secrets, shells, or network paths.

For IAM and NHI practitioners, this is a governance issue about delegated runtime authority in a developer environment. The article’s starting point is typical for agentic coding tools that are allowed to act directly, which makes the control implications broadly applicable.

Key questions

Q: What breaks when an agentic coding tool can run in the terminal with broad permissions?

A: The security boundary breaks at the point where suggestion becomes execution. If the tool can read files, run commands, and reach APIs without tight constraints, a poisoned prompt or unsafe approval can lead to secrets exposure, destructive actions, or persistence inside the developer workflow.

Q: Why do agentic coding tools increase secret exposure risk in repositories?

A: They expand the number of objects treated as operational context. Once an assistant can ingest environment files, configuration files, command output, and tool results, any embedded secret can be surfaced, reasoned over, or forwarded without the developer deliberately copying it. The risk grows with the agent’s reach, not just with user intent.

Q: How should teams decide which Claude Code commands need human review?

A: Commands that can change code, start containers, contact remote services, or access sensitive files should not be silently approved. Put low-risk actions in the allowlist and move anything that could alter state, exfiltrate data, or expand access into an ask workflow.

Q: What is the difference between sandboxing an agentic coding tool and only tightening its permissions?

A: Permissions constrain what the tool is allowed to request or execute, while sandboxing constrains the environment in which those actions occur. In practice, you need both because a limited permission set can still be abused if the runtime itself has broad filesystem or network reach.

Technical breakdown

Why agentic coding tools behave like insiders

Claude Code is designed to interpret natural language, inspect a codebase, and then act inside the terminal with the developer’s permissions. That means the security boundary is not the model alone, but the combination of prompt, settings, filesystem access, shell execution, and any connected tools. If those permissions are broad, the tool can become a conduit for secrets exposure or destructive actions even when the underlying model is not malicious. The risk comes from delegated execution, not just generated text.

Practical implication: Treat terminal AI as a privileged runtime actor and constrain what it can read, write, and execute before adoption.

Managed settings and permission boundaries

The article centers on managed-settings.json as the control plane for Claude Code behaviour. Settings such as enabled or disabled hooks, MCP server allowlists, command allow and deny rules, and directory restrictions determine whether the tool can run pre- or post-tool scripts, access broader paths, or silently approve risky behaviour. In identity terms, this is about narrowing standing access at issuance time so the tool cannot repeatedly reassert broad authority every session. The important security property is predictable enforcement, not user memory or manual caution.

Practical implication: Review the managed settings as a governing policy surface, not a convenience file, and lock down every high-risk default.

MCP servers and command execution paths

The article treats MCP servers and shell commands as the most dangerous expansion points because they let Claude Code reach beyond the immediate code task. An unrestricted MCP server can introduce new data sources, execute scripts, or reintroduce malicious behaviour across sessions, while commands like curl, docker run, or git push can extend impact outside the developer’s intent. This is an authorisation problem disguised as productivity. Once the assistant can combine prompt interpretation with tool execution, policy must be explicit and narrow.

Practical implication: Inventory every tool path the assistant can invoke and block broad execution channels that are not essential to the work.

Threat narrative

Attacker objective: The attacker aims to use the assistant’s delegated terminal access to steal secrets, alter code, persist malicious behaviour, or execute harmful commands.

1. Entry occurs when a poisoned prompt, unsafe approval, or risky dependency suggestion reaches the agentic coding workflow inside the developer terminal.
2. Credential or secret exposure follows when the tool can read files such as .env or SSH keys and incorporate them into suggestions, scripts, or outbound actions.
3. Escalation happens when hooks, MCP servers, or shell commands persist beyond a single interaction and reintroduce malicious behaviour across sessions.
4. Impact is secrets leakage, destructive command execution, repository corruption, or persistent unauthorized access through the developer environment.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic coding collapses the separation between suggestion and execution. Claude Code is not just a code-generation aid when it can read files, run commands, and reach APIs inside the terminal. That means security teams must stop thinking only in terms of developer intent and start treating runtime tool authority as a control surface. The practitioner conclusion is simple: the assistant must be authorised like a privileged executor, not trusted like a text editor.

The decisive control is scoped runtime authority, not prompt hygiene. The article’s managed-settings.json examples show that permission boundaries, hook suppression, and server allowlists matter more than user discipline alone. A poisoned prompt is dangerous only when the tool can convert it into action. The implication for governance is that policy must live at the execution layer, where file access, shell commands, and network reach are actually enforced.

Persistent tool paths create repeatable identity risk. Hooks and MCP servers turn a one-time interaction into a recurring access path, which is why a single misconfiguration can survive restarts and continue to behave like a standing credential. That is a classic non-human identity problem inside a developer workflow. Practitioners should recognise the interface as an identity-bearing runtime and manage it accordingly.

Runtime authorisation for AI coding tools is now an identity programme concern. This article is not really about Claude Code alone. It is about how quickly agentic tooling turns workstation trust into delegated authority, and how quickly that authority becomes overbroad when defaults are left open. The right governance lens is least privilege at the tool boundary, backed by auditable approval and environment isolation.

Identity blast radius expands when terminal AI can combine multiple actions in one session. A single assistant session can move from file read to command execution to dependency installation without a human intervening between each step. That creates a larger blast radius than conventional IDE automation because authorisation, timing, and execution are all compressed together. The practitioner takeaway is to treat each tool path as a separate trust decision, not as one generic AI allowance.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Identity blast radius: terminal AI should be evaluated as a runtime authority problem, not a documentation or prompt quality problem. If an assistant can read local files, execute commands, and persist behaviour through hooks or MCP servers, then access review thinking is too slow and too coarse for the decision point that matters.

The governance shift is toward issuance-time control, where the developer environment itself becomes the enforcement boundary. That aligns the topic with least privilege, tool-specific approval, and environment isolation rather than with broad trust in the coding assistant.

Backslash Security’s analysis suggests that security teams should map agentic coding tools to the same operational discipline they use for other delegated access paths: constrain scope, reduce standing reach, and make every high-risk action visible before it executes.

For practitioners

• Harden Claude Code permissions at the managed-settings layer Disable unnecessary hooks, restrict MCP servers to explicitly trusted entries, and deny access to sensitive paths, network fetches, and broad shell commands.
• Sandbox the development environment Run the assistant inside a VM or container with filesystem and network restrictions so terminal actions cannot reach the rest of the workstation.
• Separate harmless from risky commands Use allow and ask lists so only low-risk actions are silent, while commands that can push code, launch containers, or fetch remote content require review.
• Remove plaintext secret access from the workflow Keep credentials out of local plaintext files and block direct reads of secret paths, especially .env, SSH keys, and other high-value developer artifacts.
• Audit managed settings for drift Review the configuration regularly because a safe terminal AI setup can become unsafe when new servers, hooks, or directories are added over time.

Key takeaways

• Agentic coding tools can turn a developer terminal into a privileged execution environment, which expands the attack surface beyond ordinary IDE usage.
• The main risk is not just prompt abuse but overbroad runtime authority through files, commands, hooks, and MCP servers.
• Security teams should enforce tight permissions, isolate the runtime, and audit tool settings as part of identity governance for developer workflows.

Key terms

• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
• Managed Settings: A persistent configuration layer that defines what an AI coding tool may do, what it must ask about, and what it cannot touch. For identity teams, this becomes the policy boundary that governs command execution, tool use, and exposure to sensitive paths.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.