Notifications
Clear all
Topic starter
06/07/2026 9:40 am
TL;DR: Claude Code can read files, run commands, install dependencies, and connect to APIs with the developer’s permissions, which means a poisoned prompt or unsafe setting can enable secrets leakage, destructive commands, or persistence, according to Backslash Security. Access review thinking is not enough when the tool can act inside the terminal with broad runtime freedom.
NHIMG editorial — based on content published by Backslash Security: Claude Code Security Best Practices
Questions worth separating out
Q: How should security teams govern AI coding assistants that can run commands and read files?
A: Treat the assistant as a governed non-human identity with scoped permissions, not as a harmless editor feature.
Q: Why do AI coding tools increase secrets exposure risk in developer environments?
A: They operate inside the same trust zone as source code, local configs, and terminal sessions, so any readable credential becomes immediately accessible to the assistant.
Q: What breaks when MCP servers are enabled too broadly in an AI coding environment?
A: Broad MCP access collapses tool governance because the assistant can reach services, data, and actions that were never intended for every session.
Practitioner guidance
- Constrain command execution by default Set allow, ask, and deny rules so the assistant can only run commands that are explicitly safe for the current project.
- Whitelabel MCP servers and disable unnecessary hooks Approve only the servers and hook paths you have reviewed, then remove any integration that can create persistence or hidden side effects after restart.
- Sandbox the assistant in a constrained environment Run the tool inside a VM, container, or similarly isolated workspace with filesystem restrictions and no root privileges.
What's in the full article
Backslash Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact managed-settings.json examples for controlling hooks, transcript retention, and command permissions
- Step-by-step examples of allow, ask, and deny rules for safer Claude Code operation
- Practical advice for sandboxing the assistant in Docker, Podman, or a VM
- Vendor-referenced configuration guidance for blocking risky MCP servers and sensitive filesystem paths
👉 Read Backslash Security's Claude Code security best practices guide →
Claude Code security: are your controls ready for agentic coding?
Explore further
06/07/2026 9:56 am
Claude Code security is really an NHI governance problem disguised as a developer ergonomics problem. Once an assistant can inspect files, run commands, and invoke tools, it is no longer just a user interface. It becomes a non-human identity with operational reach that must be scoped, monitored, and contained like any other privileged workload. Practitioners should stop treating coding assistants as harmless productivity layers and start treating them as governed runtime actors.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to GitGuardian and CyberArk.
A question worth separating out:
Q: Who should approve changes to managed settings for an agentic coding assistant?
A: The same teams that govern privileged infrastructure should own those changes, because managed settings define the assistant’s operational boundary. Security, IAM, and platform owners should review changes that expand tool access, filesystem visibility, or hook execution. If the settings drift, the identity boundary has drifted with them.
👉 Read our full editorial: Claude Code security best practices for agentic coding tools
