Coding agents increase risk because they can pull dependencies at machine speed and with less human scrutiny. That expands the attack surface for malware, typosquatting, exploitable vulnerabilities, and unmaintained packages. If organisations do not enforce pre-installation checks, agents can introduce unsafe code paths into applications before developers notice the dependency choice or review the package source.
How coding agents change package trust decisions
Coding agents do more than suggest code. They can search for libraries, compare package names, install dependencies, and update manifests without the same review friction a person would apply. That changes package selection from a deliberate human decision into a delegated workflow, which is useful for speed but risky when the agent is operating in a weakly governed development environment. The main issue is not that agents are inherently malicious; it is that they can normalise low-friction dependency adoption before anyone validates provenance, maintainership, or release quality.
That matters because package abuse often succeeds by exploiting ordinary developer trust. Typosquatting, lookalike names, abandoned projects, and recently compromised maintainers all rely on the fact that a dependency can appear legitimate at the moment of installation. In agentic workflows, the decision window is shorter and the volume of candidate packages is larger, so shallow checks become easier to bypass. OWASP’s guidance on OWASP Top 10 for Agentic Applications 2026 is useful here because it frames delegated tool use as a governance problem, not just a code quality issue. In practice, many teams discover the dependency risk only after the agent has already written the import, not while the package choice is still being questioned.
Why machine-speed dependency selection is easier to abuse
Coding agents increase exposure because package abuse rarely depends on one dramatic failure. It usually depends on accumulated small misses: a plausible package name, a convincing README, a dependency tree that looks normal, and an installation action that happens before review. When an agent handles retrieval and installation, those misses can occur repeatedly and quickly, which raises the chance that one unsafe package gets through.
The practical mechanics are straightforward:
- An agent can search for a package that matches the task description, including packages that are new, obscure, or only superficially similar to the intended library.
- It can accept a package based on local relevance, such as a good name or useful synopsis, rather than on provenance, maintainer reputation, or release history.
- It can add dependencies directly into a codebase, which means the package may become part of build and runtime paths before a human notices.
- It can repeat that pattern across multiple tasks, which makes dependency sprawl harder to track than a one-off human install.
This is where supply-chain abuse becomes operational rather than theoretical. A malicious package does not need to be especially sophisticated if the surrounding workflow treats installation as a low-cost action. The same holds for vulnerable or abandoned packages: the danger is not only hidden malware, but also stale code paths that persist because the agent prefers whatever appears to solve the immediate task. For broader governance of model-driven systems, the NIST AI Risk Management Framework is relevant because it emphasises managing trustworthy operation, not just output quality. The key control question is whether the agent is allowed to make a dependency choice that a developer would still want to review manually.
Where this guidance breaks down is in environments that already enforce strict package allowlisting, provenance validation, and human approval for dependency changes, because the agent then has far less room to introduce unsafe code paths.
When package abuse risk is lower, and when it becomes severe
Tighter dependency controls often slow down agentic development, so organisations need to balance speed against the cost of reviewing more candidate packages. That tradeoff is real, but it is not the same everywhere. The risk is materially lower when agents work only from preapproved internal registries, pinned versions, and curated build pipelines. It becomes more severe when agents can query public registries directly, install transitive dependencies automatically, or modify manifests without a second set of checks.
There are also edge cases worth separating. A package can be safe to use in one context and unsafe in another if the version changes, the maintainer changes, or the package is only safe under a narrow trust model. Some teams assume that a popular package is automatically trustworthy; that is a consensus shortcut, not a guarantee. Popularity can reduce suspicion, but it does not remove the need to verify source integrity, version drift, and transitive risk. The same is true for “helper” libraries that appear small and harmless: agentic workflows often select them because they look convenient, yet convenience is exactly what can hide poor scrutiny.
For teams comparing broader security posture and dependency governance, NIST Cybersecurity Framework 2.0 is the better anchor for control ownership and lifecycle accountability than ad hoc developer judgement. In practice, the hardest failures appear when agents are trusted to optimise for task completion while no one is explicitly accountable for the dependency decision itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool and Action Misuse | Coding agents can misuse installation tools and actions to add unsafe dependencies. |
| Recommendation — Constrain agent tool use so dependency installation requires explicit approval. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | Package abuse can introduce code paths that access or expose embedded secrets. |
| Recommendation — Scan new dependencies for secret-access paths before allowing them into builds. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Typosquatting, malicious packages, and dependency abuse are supply-chain compromise patterns. |
| Recommendation — Map package-selection abuse to T1195 and hunt for compromised dependency insertion. | ||
| CIS Controls v8 | 5.1 — Account Management | Dependency installs should be limited to authorised workflows and accounts. |
| Recommendation — Restrict who and what can approve dependency changes in development pipelines. | ||
| NIST CSF 2.0 | PR.AC-3 — Access Enforcement | Agent-driven installs need enforced approval boundaries before code enters the build. |
| Recommendation — Enforce approval gates before agent-selected packages are added to software projects. | ||
Practitioner Guidance
What to prioritise: Treat dependency selection as a governed action, not a side effect of code generation. The first decision is whether the agent may propose packages at all, or whether it must stay inside an approved registry or curated mirror.
What to verify: Validate that the control actually blocks direct public-registry installs, not just manual developer installs. Teams often overestimate their protection because review exists in principle, while the agent can still write the dependency into the project before review starts.
Decision rule: If the agent can change manifests, resolve transitive dependencies, or trigger installs autonomously, require stronger pre-installation checks than you would for a human developer. If it cannot, the risk drops from direct abuse to support-tool misuse, which is a different governance problem.
What practitioners underestimate: The most dangerous failure is often not a single malicious package, but the repeated normalisation of low-quality dependency choices across many small tasks. That pattern creates compound exposure that is hard to spot in a code review because each individual addition looks minor.
Practitioner takeaway: The central control issue is not whether coding agents can write code, but whether they can also make dependency decisions that bypass the scrutiny your software supply chain depends on.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
