Notifications
Clear all
Topic starter
02/08/2026 11:46 am
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.
NHIMG editorial — based on content published by Akto: Claude Code Security: Risks, Limitations, and Best Practices for Agentic AI
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Akto's analysis of Claude Code security, runtime guardrails, and agentic AI risk →
Claude Code security limits: are your runtime controls keeping up?
Explore further
02/08/2026 12:56 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Claude Code security exposes the limits of model-level guardrails
