Claude Code security exposes the limits of traditional IAM

At a glance

What this is: Claude Code security is about protecting autonomous coding agents that can read code, run commands, call tools, and commit changes inside a single workflow.

Why it matters: It matters because IAM, PAM, and NHI governance now have to control agent actions, not just human access and static service credentials.

By the numbers:

• 95% of respondents use AI coding tools weekly or more.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Lasso Security's analysis of Claude Code security and autonomous coding agents

Context

Claude Code security is no longer a narrow developer productivity question. It is a governance problem for AI coding agents that can interpret instructions, access code, execute shell commands, and invoke external services during the same session.

The control gap is that many enterprise review processes still assume software changes are human-paced, bounded, and reviewable after the fact. Once an autonomous coding agent can expand scope, consume external content, and act without step-by-step approval, that assumption breaks for NHI and agent governance alike.

Key questions

Q: How should security teams govern autonomous coding agents in development workflows?

A: Security teams should govern autonomous coding agents with pre-execution boundaries, connector review, and runtime intent checks. The key shift is to treat the agent as an identity-bearing executor, not just a productivity tool. That means limiting tool reach, validating inbound content, and requiring explicit approval paths for sensitive code, pipeline, or infrastructure actions.

Q: Why do autonomous coding agents complicate least privilege and change control?

A: They complicate both because they can expand scope within a single session and touch more systems than the original request implied. Least privilege is harder to define when the task evolves at runtime, and change control is weaker when the action happens before a human can review the intermediate steps. Traditional review cadences are simply too slow.

Q: What do teams get wrong about securing AI coding assistants?

A: Teams often focus on code output and ignore the agent boundary, where file reads, tool outputs, and external content shape the next action. That misses the real control point. The right question is whether untrusted input can influence privileged behaviour before the code is even written or committed.

Q: What is the difference between code review and intent alignment for AI agents?

A: Code review evaluates the change after it exists. Intent alignment checks whether the agent should have been allowed to take that path at all. For autonomous coding agents, both matter, but intent alignment is the earlier and more decisive control because it can stop scope drift before it becomes a committed change.

Technical breakdown

Agent boundary security for AI coding agents

Claude Code sits at a boundary where files, web content, tool outputs, and shell commands all feed into the agent's decision layer. The risk is not only what code it writes, but what it ingests before deciding what to do next. If untrusted content enters the model context without validation, the agent can be steered by malicious instructions, poisoned documentation, or compromised tool output. This is why agent boundary security is different from static code scanning: the attack surface is the conversation, the tool chain, and the execution path at once.

Practical implication: scan and constrain every input and tool result before it reaches the agent's decision layer.

Intent alignment and scope drift in autonomous coding workflows

Intent alignment means checking whether the agent is still acting within the task the developer actually asked it to perform. That matters because autonomous coding agents can keep going after the original issue is solved, refactoring adjacent code, touching sensitive controls, or modifying configuration that was never explicitly in scope. This is not the same as malicious compromise. It is a behavioural failure mode created by broad permissions, ambiguous instructions, and no hard boundary on when the task ends.

Practical implication: treat scope drift as a policy violation and require explicit task boundaries for sensitive changes.

Tool poisoning and privileged MCP integrations

MCP-connected tools expand what the agent can see and do, but they also create a path for malicious or compromised external services to influence execution. A poisoned connector can feed altered responses, inject instructions, or trigger actions that look legitimate from inside the workflow. In practice, tool trust becomes identity trust: the agent is only as safe as the external service identities, permissions, and verification around each connector. That is an NHI governance problem, not just an application problem.

Practical implication: verify connected tools before granting execution rights and continuously monitor connector behaviour.

Threat narrative

Attacker objective: The objective is to redirect a trusted coding agent into making unauthorized changes or exfiltrating sensitive data through legitimate-looking actions.

1. Entry occurs when malicious instructions arrive through files, web content, comments, or MCP tool responses that the agent reads as part of normal work.
2. Credential or privilege access happens when the agent uses its granted environment access, shell execution, or connected services to act on those instructions.
3. Escalation follows when the agent expands beyond the original task, modifies sensitive code or pipeline controls, and carries the unintended change into committed work.
4. Impact lands in corrupted code, altered CI/CD controls, or data exfiltration through the agent's own trusted execution path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Autonomous coding agents collapse the assumption that software change is human-paced. Enterprise security review, access certification, and code approval processes were designed for changes that persist long enough to be observed and signed off. Claude Code can read, act, and commit inside a single session, so the review window is no longer the same shape as the execution window. The implication is that governance has to be defined around runtime behaviour, not post-hoc review alone.

Intent deviation is a named governance failure mode, not a side effect. The article's strongest signal is that an agent can be perfectly well-intentioned and still cross a control boundary by doing more than the user asked. That is different from malware, because the trust failure originates inside the operating model, not outside it. Practitioners should treat this as a distinct policy class that sits between access control and change control.

Agent boundary security should be read as NHI governance for the execution layer. Once Claude Code can ingest external content and call tools, the relevant question becomes which identities, connectors, and runtime inputs are allowed to influence action. OWASP-NHI and ZT-NIST-207 are the right lenses for that problem because the agent behaves like a privileged non-human identity with dynamic reach. Teams should stop treating it like a smarter editor and start treating it like an identity-bearing executor.

Secure I/O is the right named concept for this category. The article shows that the vulnerable point is not only the model output, but every file read, web fetch, tool result, and command response that enters the agent's decision path. That expands NHI governance from secret storage to content provenance and execution trust. The practitioner conclusion is simple: if input can steer action, it must be governed like an identity signal.

Compliance logging alone does not solve autonomous agent risk. Audit trails are necessary, but they only explain what happened after the agent has already acted. In a Claude Code environment, the key governance question is whether the action should have been executable at all given the task, connector, and context. Practitioners need pre-execution control points, not just better records of the breach.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• That mismatch between exposure speed and remediation speed makes The State of Secrets in AppSec a useful forward reference for agent boundary governance.

What this signals

Secure I/O is becoming the practical control plane for AI coding agents. Once a coding agent can ingest external content and take actions on it, the programme needs provenance checks, connector ownership, and execution policy at the boundary. That is where NHI governance and agent governance converge in day-to-day operations, especially for teams using Analysis of Claude Code Security as a category reference.

With 43% of security professionals already worried about AI systems learning and reproducing sensitive information patterns from codebases, the concern is no longer theoretical. The governance gap is that traditional security review assumes the risky thing is the output, while agentic workflows make the risky thing the input-to-action chain itself.

Intent deviation: this is the concept practitioners should track in code-agent programmes because it captures behaviour that is technically permitted but operationally out of bounds. That means change boards, platform teams, and identity teams need a shared threshold for when an agent crosses from helpful execution into unauthorized expansion of scope.

For practitioners

• Define agent execution boundaries before deployment Restrict which file paths, shell commands, repositories, and external services the coding agent can touch for each task class. Separate harmless refactoring workflows from privileged release and infrastructure workflows so one policy does not cover both.
• Scan every inbound content source before the agent sees it Treat documentation fetches, repository comments, tool results, and API outputs as untrusted inputs. Validate and filter them before they enter the agent's context window so malicious instructions cannot influence execution.
• Review MCP connectors as privileged identities Inventory each connected service, confirm its trust chain, and approve it the same way you would approve a service account with write access. If a connector can cause action, it needs lifecycle ownership and periodic revalidation.
• Separate intent checks from post-change code review Require a runtime control that compares the current agent action against the original task description before sensitive edits, commits, or pipeline changes execute. Do not rely on pull request review to catch scope drift after the fact.

Key takeaways

• Claude Code security exposes a broader governance problem: autonomous coding agents can act inside the same session in which they are given trust.
• The most important failure mode is not code generation itself, but input-to-action trust across files, tools, web content, and shell commands.
• Teams need runtime intent checks and connector governance, because post-change review alone cannot contain scope drift in agentic workflows.

Key terms

• Autonomous Coding Agent: A software agent that can decide, sequence, and execute development tasks with minimal human intervention. In practice, it reads code, invokes tools, and changes files in runtime, so governance must focus on its permissions, inputs, and action boundaries rather than only on the resulting code.
• Intent Alignment: A control concept that checks whether an agent is still acting within the task it was given. For autonomous coding workflows, intent alignment matters because a system can behave correctly at a technical level while still crossing a policy boundary by doing more than the operator intended.
• Agent Boundary: The point where external content, tool outputs, and environment data enter an agent's decision-making path. This is where validation, filtering, and authorization need to happen, because anything admitted at the boundary can shape the agent's next action and expand the attack surface.
• Tool Poisoning: A failure mode in which a connected tool or service returns malicious, altered, or misleading output that steers an agent into unsafe action. It matters because the trust problem shifts from source code alone to the identities and responses of every integrated connector.

Deepen your knowledge

Claude Code security and autonomous coding agent governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic development workflows, it is worth exploring.

This post draws on content published by Lasso Security: Claude Code Security: Autonomous Coding Agents Need a New Security Layer. Read the original.