Why do coding agents increase the risk of open source package abuse?

Why This Matters for Security Teams

Coding agents change package risk because they remove the normal friction that slows unsafe dependency decisions. A human reviewer usually notices odd package names, suspicious maintainers, or version drift. An agent can resolve, install, and chain packages in seconds, which gives attackers a faster path to typosquatting, dependency confusion, malicious post-install scripts, and abandoned libraries. That is why package abuse is not just a software supply chain issue, but an identity and authorization problem.

The issue is amplified when agents operate with broad repository access or inherited build permissions. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework treats autonomous tool use as a governance boundary, not a convenience feature. NHIMG research shows the exposure is already widespread: 92% of organisations expose NHIs to third parties, which is a useful proxy for how easily machine identities can be overextended across supply chains. In practice, many security teams encounter package abuse only after a build system has already pulled the wrong dependency and propagated it into downstream artifacts.

How It Works in Practice

Package abuse becomes more likely when a coding agent has standing access to package registries, source control, and CI/CD secrets. The agent does not need malicious intent. It only needs the ability to choose and install dependencies based on task completion goals. That means the control point should be runtime authorisation, not only developer training or code review after the fact.

A stronger model uses workload identity plus just-in-time entitlement. The agent authenticates as a distinct workload, not as a shared human account, and receives only the permissions needed for the current task. In practice, teams combine short-lived tokens, policy-as-code, and package allowlists so each install request is checked in context. The key question is not simply “who is the agent?” but “what is it trying to do right now, and is that dependency permissible for this repo, environment, and risk tier?”

Operationally, that usually means:

• Restricting package install and publish rights to ephemeral, task-bound credentials.
• Validating package provenance, namespace ownership, and signature metadata before install.
• Blocking agents from using long-lived registry tokens in prompts, build logs, or config files.
• Evaluating policy at request time against repo sensitivity, network reach, and dependency source.
• Separating code generation from dependency approval so the agent cannot self-authorise new packages.

This aligns with the direction described in the OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize runtime controls for autonomous tool use. These controls tend to break down when agents can reach multiple registries, cached build artifacts, and unattended secrets in the same workflow because one approved action can cascade into unreviewed dependency expansion.

Common Variations and Edge Cases

Tighter dependency control often increases friction for developers, requiring organisations to balance speed against supply chain assurance. That tradeoff is especially visible in CI systems, local coding assistants, and multi-agent pipelines where one agent selects packages and another agent tests or deploys them.

There is no universal standard for how much autonomy a coding agent should have in package management, but current guidance suggests a tiered approach. Low-risk sandboxes may allow broader package experimentation, while production-bound repos should require explicit approval for new dependencies, major version changes, and registry scope expansion. A useful boundary is to treat dependency selection as an authorization decision, not just a build step. That matters because malicious packages often look legitimate until the agent resolves them.

Edge cases also include private registries and internal mirrors. They reduce exposure to public typosquatting, but they do not eliminate abuse if the agent can publish poisoned packages internally or reuse compromised tokens across environments. NHIMG’s Ultimate Guide to Non-Human Identities notes that 97% of NHIs carry excessive privileges, which explains why package abuse often becomes a privilege problem as much as a code problem. The lesson is simple: if the agent can install it, it can often amplify it.

Related resources from NHI Mgmt Group

• Why do standing publish privileges increase risk for package maintainers in open-source ecosystems?
• Why do AI coding agents increase supply-chain risk?
• Why do coding agents increase the risk of secret leakage?
• Why do AI coding agents increase insider risk so quickly?