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.
Why the local machine changes the risk picture
Coding agents are not just model outputs, they are execution environments. If the agent can open shells, read files, call installed tools, or reuse an already logged-in session, the effective authority comes from the laptop or workstation, not from the quality of the model’s reasoning alone. That is why a clean-looking review can still hide dangerous real-world actions.
The practical issue is mismatch: the model may appear safe in isolation, but the surrounding environment can turn a harmless-seeming instruction into file deletion, secret exposure, or unauthorized network activity. In other words, the security boundary is the combination of model, tools, credentials, and host state, not the model review artifact.
One useful way to think about this is that the model is making decisions, while the local system is supplying privilege. If those privileges are broader than the task, the agent can cross from suggestion into action without ever “looking” malicious in review.
Which environmental factors most often create the hidden blast radius?
The largest risk multipliers are usually existing auth state and ambient trust: terminal access, cached browser sessions, developer tokens, mounted directories, package managers, cloud CLIs, and files already present on disk. These are not theoretical conveniences; they are direct pathways to data, code, and infrastructure that the model itself should not inherently control.
Installed packages and local tooling matter because they expand what the agent can invoke. A coding agent with access to a package manager, deployment tooling, or cloud client can transform a small prompt mistake into dependency poisoning, destructive commands, or environment-wide changes.
File presence matters too. If sensitive material already sits on the machine, then the agent does not need to “break” anything to reach it, it only needs to be allowed to read, copy, or upload it. The review can still look fine because the review does not always represent that ambient access path accurately.
Why “safe model” is not the same as “safe action”
A coding model can behave conservatively in a test prompt and still be unsafe when paired with over-scoped access. The risk is less about whether the model hallucinates and more about whether it is empowered to carry out a bad or ambiguous instruction through the local environment.
This is why the same prompt can be low-risk in a read-only sandbox and high-risk on a developer laptop. The task may appear ordinary, but once shell, file, and credential access are available, the agent can chain small steps into material impact.
That also means review quality has limits. Good review can reduce obvious prompt-level mistakes, but it cannot compensate for a host that already contains excessive authority. The control question is not only “Did the model judge the request correctly?” but also “What can it actually do if it is wrong?”
Risk and Threat Considerations
Coding agents create a wider attack surface because they can inherit authority from the environment and from the developer’s active sessions. When that authority is excessive, an attacker only needs to steer the agent into using legitimate tools in an unsafe sequence, which can lead to secret exposure, destructive commands, or unauthorized code and data access.
Failure mechanism: The agent follows a plausible instruction through local tooling, but the machine already has shell access, tokens, mounted files, or signed-in services that let the action cross trust boundaries without an obvious warning.
Impact: The result can be source-code leakage, secret theft, unintended deployment, data loss, or persistence through reused credentials and sessions, even when the model’s review output appeared acceptable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Coding agents inherit harmful power from over-scoped local access. |
| NHI-07 — Long-Lived Secrets | Local sessions and tokens on developer machines amplify agent misuse. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Agent-host combinations often expose cloud tooling through unsafe local setup. | |
| Recommendation — Reduce agent blast radius by removing excess privileges from attached credentials and tools. Replace durable secrets with short-lived credentials and rotate exposed tokens quickly. Harden local and cloud tool access so agents cannot reach unsafe deployment paths by default. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The core issue is agent action enabled by excess local privilege. |
| ASI02 — Tool Misuse | Shells, CLIs and installed tools become the dangerous execution path. | |
| ASI10 — Rogue Agents | A coding agent can act beyond intended bounds when host authority is broad. | |
| Recommendation — Constrain agent authority to the minimum task scope and require approval for high-impact actions. Restrict tool availability and validate every tool invocation that can change state. Detect and block agent actions that exceed the task boundary or approved execution context. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The answer centers on reducing ambient authority on the local machine. |
| IA-5 — Authenticator Management | Cached tokens and developer secrets on the host are key risk amplifiers. | |
| CM-7 — Least Functionality | Installed packages and reachable tools determine how far the agent can act. | |
| Recommendation — Limit each coding agent to the minimum permissions needed for the current task. Shorten authenticator lifetime and rotate credentials that the agent can reach. Remove unnecessary tooling from the agent workspace to shrink the attack surface. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Coding agents become risky when access is broader than the task requires. |
| Recommendation — Continuously review and revoke overbroad access granted to agent workflows. | ||
Practitioner Guidance
What to verify: Treat host authority as part of the control design. Verify which tools are reachable, which credentials are live, which directories are mounted, and whether the agent can reach production, cloud, or package-installation paths from the same session.
Decision rule: If the environment can perform a destructive or privileged action without a second approval step, assume the coding agent can too. Put the agent in a sandbox or task-scoped workspace before you trust model review as a meaningful safety signal.
What good looks like: The agent can complete the task with narrowly scoped access, short-lived credentials, and clear barriers between read, write, and execute operations. The safer pattern is bounded execution, not “trust the model more.”
Practitioner takeaway: For coding agents, risk is usually governed less by model quality than by the authority already present on the machine. If the host is over-privileged, even a well-reviewed model can still cause real damage.
Related resources from NHI Mgmt Group
- Why do AI agents increase non-human identity risk in existing IAM programmes?
- Why do AI agents increase non-human identity risk?
- Why do AI coding agents create security risk even when they use the same model?
- Why do AI coding agents increase software risk if organisations keep the same review process they used for human developers?