By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: AktoPublished April 15, 2026

TL;DR: Claude Code can read files, run shell commands, call APIs, and trigger workflows, but its protections are mostly model-level rather than runtime enforcement, according to Akto. That leaves engineering teams exposed to prompt injection, tool abuse, shadow deployments, and over-permissioned sessions that IAM and AppSec must govern more tightly.


At a glance

What this is: Claude Code security is about understanding the gap between a model that reasons over code and the runtime controls needed to govern agentic actions safely.

Why it matters: It matters because agentic tools can touch code, data, and deployment pipelines with minimal human input, creating identity and privilege risks that conventional review processes do not fully contain.

👉 Read Akto's analysis of Claude Code security, runtime guardrails, and agentic AI risk


Context

Claude Code security sits at the intersection of application security, IAM, and agentic AI governance. The core problem is simple: a tool that can write files, run commands, and call services is no longer just an assistant, it is an identity-bearing runtime actor that needs scoped permissions, auditability, and containment.

The article argues that the main failure mode is not weak code analysis, but the mismatch between static reasoning and live execution. That distinction matters for teams managing human access, non-human identities, and AI agents, because the same permission drift that creates NHI risk also creates agentic blast radius once a model can act on tools and pipelines.


Key questions

Q: What breaks when agentic code assistants are allowed to act without runtime controls?

A: The main failure is that static review cannot stop live misuse. A model may pass code analysis and still be manipulated at runtime into reading sensitive files, invoking the wrong tool, or pushing changes into deployment flows. Without execution-time controls, the agent's authority becomes the attack surface.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What do security teams get wrong about prompt injection in agentic workflows?

A: They often treat prompt injection as an input validation problem only. In reality, the risk appears when hostile context is converted into action, especially if the agent can run commands, call tools, or make network requests. The control objective is to prevent unsafe action, not just detect bad text.

Q: How should organisations govern AI assistants that can run local commands?

A: They should govern them like privileged machine identities with bounded authority, not like ordinary productivity software. That means defining who can enable execution mode, which repositories are eligible for tool use, and what evidence is required before an assistant can touch local credentials or system commands.


Technical breakdown

Permission model and dangerously-skip-permissions risk

Claude Code's permission model is built around explicit user approval for actions such as writing files, running commands, and making network calls. The problem is that the bypass path, exposed through a dangerously-skip-permissions flag, can collapse that control layer if it is used in automated or poorly governed environments. In agentic systems, the security question is not whether the model can ask for approval, but whether the surrounding workflow can enforce meaningful restraint when the agent is embedded in developer tooling, CI/CD, or local shells. That makes the permission boundary part of identity governance, not just developer convenience.

Practical implication: treat approval bypass as a privileged control exception and restrict it with documented policy, audit logging, and environment separation.

Why static reasoning is not runtime enforcement

Claude Code Security reasons over code structure and data flow, but it does not observe what an agent does after deployment. That means a clean static review can still miss runtime prompt injection, tool misuse, or data exfiltration when the agent is acting in a live environment. This is a classic governance gap in agentic AI security: discovery of risk is not the same as enforcement of policy. For practitioners, the important distinction is between analysis at pull request time and control at execution time, where the latter is what actually limits damage.

Practical implication: pair pre-deployment review with runtime guardrails that can block tool calls, network access, and data movement in production.

Shadow AI and missing session memory create blind spots

The article highlights a broader operational weakness: sessions start fresh, which means no native cross-session memory and no durable behavioural trail. In practice, that makes local use of agentic tools hard to govern because security teams may not know what was accessed, what commands ran, or whether a prior session revealed sensitive context. This is where the identity angle becomes concrete. An agent without persistent oversight still acts as a powerful non-human identity, but one that can disappear from view between sessions, leaving compliance, forensics, and privilege review incomplete.

Practical implication: instrument tool calls, session logs, and asset discovery so security teams can reconstruct agent activity across workflows.


Threat narrative

Attacker objective: The attacker aims to turn a coding assistant or AI agent into an exfiltration and execution path that can alter systems, leak secrets, or compromise production workflows.

  1. Entry occurs when a malicious prompt, file, or external content is fed into an agentic workflow that trusts its surrounding context too broadly.
  2. Escalation happens when the agent is allowed to invoke tools, run commands, or reach network resources without sufficient runtime constraints.
  3. Impact follows when the agent reads sensitive data, alters code, triggers deployment actions, or exposes credentials beyond its intended task scope.

NHI Mgmt Group analysis

Model-level guardrails are not a substitute for governance over agent runtime. The article makes a useful distinction between reasoning about code and controlling live behaviour. That distinction is central to agentic AI security because the security boundary moves from the model to the tools, sessions, and data sources it can touch. Practitioners should treat runtime enforcement as the primary control surface, not an optional add-on.

Claude Code should be understood as an identity-bearing tool, not just a productivity feature. Once a system can write files, run shell commands, and call external services, it begins to resemble a non-human identity with delegated authority. That means IAM, PAM, and NHI governance principles apply directly, especially around scope, duration, auditability, and the removal of standing access. The control question is who or what can act, for how long, and with what observable trace.

Shadow AI is an access governance problem as much as a discovery problem. The article's concern about local, invisible usage maps to the broader issue of unmanaged non-human identities. If teams cannot see where agentic tools are running or what they touched, they cannot review entitlement drift or prove control effectiveness. That creates a governance gap around discovery, ownership, and offboarding that identity teams should recognise immediately.

AI security programmes need a named runtime enforcement concept for agents: context-to-action containment. The article shows that the dangerous step is not input alone, but the conversion of untrusted context into tool execution. That is the failure mode practitioners need to govern with allowlists, scoped permissions, and monitored execution paths. The practical conclusion is that agentic AI security must be measured by what an agent is prevented from doing, not only by what it can explain.

What this signals

Context-to-action containment is the control problem this article points toward. Once an agent can turn untrusted context into tool execution, the programme needs runtime policy, not just model review, and that is where identity teams should align with AppSec and platform engineering.

The governance signal is straightforward: if you cannot inventory agent activity, you cannot govern agent identity. The article reinforces why discovery, session logging, and least-privilege tool access need to move into the same operational conversation as secrets management and CI/CD security.

Teams should expect agentic workflows to expand faster than their control coverage. The practical response is to align runtime guardrails with NIST AI Risk Management Framework and OWASP Agentic AI Top 10 before these tools become embedded in production paths.


For practitioners

  • Define approval bypass as a privileged exception Document every use of dangerously-skip-permissions, restrict it to controlled environments, and require audit trails that show who approved the exception and why.
  • Separate agent runtime from production write paths Run Claude Code in environments that do not have direct write access to production infrastructure, and limit task scope to the minimum required permissions.
  • Instrument tool calls and session activity Capture inputs, outputs, commands, file reads, and network calls so security teams can reconstruct what the agent accessed and when.
  • Add runtime guardrails for agent tool use Block or approve specific tool invocations, data categories, and external calls at execution time, especially where the agent can influence deployment or data movement.
  • Treat local agent use as shadow AI until proven visible Inventory where developers are running agentic tools, map those instances to owners, and tie them into existing identity and access review processes.

Key takeaways

  • Claude Code security is really about governing runtime authority, not just reviewing code for flaws.
  • Agentic tools create non-human identity risk when their permissions, sessions, and tool use are not tightly scoped and logged.
  • The right control model combines pre-deployment reasoning with runtime enforcement, because one without the other leaves production exposed.

Key terms

  • Agentic Runtime Protection: Controls that inspect and govern an agent while it is operating, including tool calls, context loading, memory writes, and inter-agent communication. This is different from static content filtering because it focuses on what the identity does, not just what it says.
  • Dangerously-skip-permissions: A bypass mode that allows an AI tool or agent to execute actions without the normal confirmation loop. In practice, it turns a guarded workflow into one with much broader effective authority, so it should be treated like a privileged exception with strict logging and approval.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Context-to-Action Containment: A governance pattern that prevents untrusted context from becoming unsafe execution. It focuses on stopping an agent from turning a malicious file, prompt, or tool output into a harmful command, network call, or data movement event.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

  • Step-by-step guidance on configuring Claude Code permissions for safer development workflows
  • Operational examples of runtime guardrails for AI agents, MCP servers, and GenAI apps
  • The vendor's threat model for shadow deployments, tool abuse, and production data exposure
  • Implementation context for integrating AI review outputs into existing AppSec pipelines

👉 Akto's full post covers the permission model, built-in protections, runtime threats, and production best practices in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It helps practitioners connect identity principles to the operational realities of AI agents, workloads, and privileged automation.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org