How should teams govern AI agents that can install dependencies?

Why This Matters for Security Teams

An AI agent that can install dependencies is not just writing code, it is making supply chain decisions that can introduce new runtime behaviour, new transitive packages, and new trust relationships. That makes package installation a privileged action, especially when the agent also has access to build systems, source control, or secrets. Guidance in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points in the same direction: give the system only the authority it needs, then verify outputs before they reach production.

The real risk is not only malicious code. It is also accidental drift, where an agent installs a package to satisfy a prompt, upgrades a dependency without review, or reaches out to a public registry using credentials that were meant for a different workflow. Once that pattern exists, the agent can become a bridge between code generation, dependency trust, and environment compromise. In practice, many security teams encounter this only after an unexpected package change or secret exposure has already occurred, rather than through intentional dependency governance.

How It Works in Practice

Teams should treat dependency installation as a gated workflow, not a free-form capability. The cleanest pattern is to separate code generation from dependency changes, then require an approval step before any new package is installed or any lockfile is updated. Where possible, the agent should propose changes in a sandboxed environment with no standing access to production registries, signing keys, or long-lived tokens. That approach aligns with the control logic behind zero trust and agentic guardrails, and it maps well to the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework.

• Use allowlisted package sources and require checksum or signature verification where the ecosystem supports it.
• Run installs in ephemeral, isolated build environments with minimal filesystem and network access.
• Keep secrets out of the agent context unless a specific task truly requires them, and prefer short-lived credentials.
• Log prompt, tool call, package selection, and approval metadata so dependency changes are auditable.
• Block direct publish, deploy, or merge actions until a human or policy engine validates the package set.

This is especially important when the agent can generate install commands from natural language, because a plausible package name is not the same as a trusted dependency. Validation should include package provenance, maintainer reputation, and whether the dependency introduces unnecessary privilege or remote code execution risk. These controls tend to break down when build pipelines share credentials across jobs, because one agent action can then fan out into uncontrolled registry access.

Common Variations and Edge Cases

Tighter dependency controls often increase friction for developers, requiring organisations to balance delivery speed against supply chain assurance. That tradeoff is real, and current guidance suggests it should be handled with policy-based exceptions rather than ad hoc overrides. For internal packages, best practice is evolving around signed artefacts, repository mirroring, and controlled promotion paths, but there is no universal standard for every language ecosystem yet.

Some environments need stricter treatment than others. Regulated software delivery, production-facing agents, and systems that manage credentials should apply more restrictive controls than a local coding assistant that cannot reach external registries. For AI agents that interact with CI/CD or infrastructure tooling, the dependency decision becomes part of the system’s security boundary, not a developer convenience. The OWASP Top 10 for Agentic Applications 2026 is useful here because it reinforces the need to constrain tool use, while the NIST Cybersecurity Framework 2.0 helps teams map those restrictions to governance, identification, protection, detection, and response. The hardest cases are legacy build systems and shared runners, where the agent cannot be isolated cleanly and dependency governance becomes dependent on the surrounding pipeline design.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern AI agents that coordinate through signals?