Coding agent security depends on the laptop, not just the model

Editorial analysis by NHI Mgmt Group, based on content published by Identra.ai: “What security teams miss about coding agents”.

At a glance

What this is: This article says coding agent risk is determined by the real machine context, not by the vendor approval list alone.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern what agents can reach on endpoints, not just what the model or product is allowed to do.

Context

Coding agents are local execution tools, not just chat interfaces. They run under a developer’s account, can read files, invoke shell commands, install packages, and interact with whatever credentials are present on the endpoint.

That creates a governance gap for NHI and developer access control: the security question is not only whether Claude Code or Codex is trusted, but what the task can touch on a real laptop, in a real session, with real secrets nearby.

Key questions

Q: What breaks when a coding agent can reach developer secrets on a laptop?

A: The failure is that task-level intent no longer limits execution. If the agent can read .env files, cloud CLI sessions, or credential stores, a routine code change can become a path into environments it never needed. The right boundary is the endpoint workload and its reachable secrets, not the model label.

Q: Why do coding agents increase risk even when the model review looks fine?

A: Because the model review does not govern the local environment. Risk comes from the combination of shell access, logged-in tools, installed packages, and files already present on the machine. A safe model can still execute unsafe actions if the laptop exposes more authority than the task requires.

Q: How do security teams spot dangerous coding-agent workflows?

A: Look for workflows that mix untrusted text, installed helpers, and privileged credentials in the same session. A ticket comment, README, or package suggestion should never be able to trigger actions against cloud accounts, secret stores, or deployment targets without an explicit control point.

Q: Who should own coding-agent revocation and incident response?

A: Ownership should follow the systems the agent can touch. Endpoint security, IAM, cloud platform, and application teams may all need a role when a session goes wrong, because revoking the process alone does not revoke every token or remote grant it may have used.

Technical breakdown

Coding agents inherit endpoint context, not just prompt intent

A coding agent is constrained by the operating system, sandbox settings, command approvals, and local artefacts such as .env files, cloud CLI sessions, and credential stores. The model may be the same, but the reachable authority changes radically with the endpoint. That means the risk surface is not the vendor category alone, but the local identity and file system context in which the agent runs. A throwaway container, a locked-down workstation, and a staff engineer laptop are different security environments. The important distinction is reachability, not brand.

Practical implication: classify coding agents by the endpoint permissions and secrets they can actually reach.

MCP servers and plugins expand authority through delegated tools

The article shows that added MCP servers, skills, plugins, and packages can turn a routine task into a broader execution chain. These components do not merely extend convenience. They introduce new authenticated tool paths, new install scripts, and new opportunities for indirect control through repositories, tickets, or marketplaces. In practice, the agent’s authority becomes the sum of its local access plus every delegated tool it can call. A server that only reads tickets is materially different from one that can edit Terraform state or trigger deployments. Governance has to track those differences explicitly.

Practical implication: inventory every delegated tool and tie it to an owner, purpose, and permission set.

Indirect prompt injection works by converting text into authority

The article’s core mechanism is indirect prompt injection: text in READMEs, issue comments, or tool output can steer the agent once the workflow allows that text to trigger actions. The failure is not that the text is malicious by itself, but that the agent is allowed to treat untrusted content as an instruction source. This is why system prompts are insufficient on their own. The control boundary has to sit around files, commands, outbound destinations, and approvals. Once the task can read and act on attacker-controlled text, the environment has already granted too much leverage.

Practical implication: separate explanatory text from actionable authority and block sensitive operations unless the workflow explicitly requires them.

Threat narrative

Attacker objective: The attacker wants the coding agent to execute attacker-influenced actions while using the developer’s existing access and local credentials.

1. Entry occurs when the agent is allowed to read local files, shell output, ticket comments, or other untrusted content inside the developer workflow.
2. Credential access follows when the task touches exposed secrets such as .env files, cloud CLI sessions, or logged-in developer credentials on the machine.
3. Escalation happens when a package, MCP server, or instruction embedded in text expands the agent’s ability to call tools or reach higher-impact resources.
4. Impact is the unintended execution of code, access to environment credentials, or movement into repositories and services that the task did not legitimately require.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

NHI Mgmt Group analysis

Endpoint reach, not model approval, is the real security boundary for coding agents. The article is right to move the conversation from vendor review to the developer laptop, because the agent’s effective authority comes from local files, logged-in CLIs, and sandbox settings. That makes endpoint context the primary governance unit, not the model itself. Practitioners should stop treating AI coding tools as abstract services and govern them as execution-capable identities on managed endpoints.

Ephemeral task intent does not erase standing access. A CSV fix does not need staging admin, production tokens, or broad repository reach, yet many developer machines already carry all three. This is a classic least-privilege failure, but in coding agents it becomes more acute because the tool can actively consume those privileges during the task. Identity programmes need to distinguish between what the developer can do and what the task should be allowed to do.

Tool chaining creates a new identity blast radius. Packages, MCP servers, skills, and plugins turn one approved assistant into a mesh of delegated execution paths. Each added component widens the trust boundary, and each update can quietly change the agent’s capability set. The governance problem is no longer simple software approval. It is continuous control over who owns each delegate, what it can reach, and how it is revoked when the workflow changes.

Indirect prompt injection is an authority transfer problem, not a text filtering problem. READMEs and issue comments become dangerous only when they are allowed to shape actions that reach secrets, files, or external systems. That makes text-to-action translation the failure mode to govern. The implication is that endpoint policy, outbound control, and approval design matter more than polite system prompts or user discipline.

Prompt-to-action authority should be treated as a distinct named concept. In coding-agent environments, the critical asset is not the prompt itself but the point at which untrusted content becomes an executable instruction. Once that boundary is crossed, the agent can be coerced into using legitimate developer access for illegitimate purposes. Practitioners should design controls around that conversion point, because that is where the security model breaks.

From our research library:

• 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 Coding Agents Security Guide

What this signals

Identity blast radius: coding agents turn endpoint access into operational risk because the task can consume whatever the developer machine already exposes. That shifts governance from model approval to endpoint reach, which is a better fit for IAM, PAM, and NHI controls than policy statements about acceptable use.

A developer laptop with a cloud CLI, repository tokens, and writable tooling becomes a blended identity environment. Security teams should therefore treat coding agents as governed execution contexts, not as standalone applications, and measure them by the secrets, commands, and outbound paths they can actually use.

The pattern is visible in current telemetry: according to the State of Secrets Sprawl 2026, 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. That is a governance signal, not a tooling anomaly.

For practitioners

• Map the laptop trust boundary Document which files, credential stores, CLI sessions, and shell operations a coding agent can reach on representative developer endpoints. Separate harmless edit-and-test work from anything that can touch deployment tools, cloud accounts, or protected secrets.
• Scope approvals to the exact operation Require explicit approval for new packages, destructive shell commands, and any action that reaches outside the task’s intended repo or environment. A generic session approval should not authorize later uploads, installs, or admin changes.
• Inventory every delegated tool Record each MCP server, skill, plugin, and package with an owner, purpose, authentication method, and removal path. Treat additions as changes to the agent’s effective authority, not as harmless productivity extras.
• Test for indirect prompt injection Use a controlled repository or issue thread to see whether the agent will obey attacker-shaped text, print secrets, or attempt outbound exfiltration. Re-run the test after any tooling or permission change.
• Rehearse revocation before rollout Define who can stop the agent, revoke GitHub and cloud tokens, and preserve evidence when a session behaves unexpectedly. Make that process part of the first rollout, not an afterthought.

Key takeaways

• Coding agents become risky when endpoint access, local secrets, and delegated tools are treated as incidental rather than governed inputs to the task.
• The article shows that package installs, MCP servers, and untrusted text can widen a coding agent’s effective authority without changing the prompt.
• The practical control point is the laptop workflow: restrict reach, separate approval from convenience, and design revocation around the systems the agent can touch.

Key terms

• Coding Agent: A coding agent is a software system that can plan, generate, and modify code with limited human prompting. In governance terms, it is not just a tool but an actor whose permissions, tool access, and rollback path must be managed as part of the delivery process.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Prompt-to-Action Boundary: The prompt-to-action boundary is the point where informational content becomes an executable instruction. For coding agents, that boundary determines whether repository text, ticket comments, or tool output can trigger access to files, secrets, or external systems.
• Delegated Tool Authority: Delegated tool authority is the practical permission a model receives when it is allowed to invoke scanners, APIs, shells, or other operational tools. The security risk is not only misuse, but also overreach, because the model may chain actions beyond what a human operator explicitly intended.

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.