Who is accountable when an AI agent or automation system installs a malicious dependency?

The accountable team is the one that granted autonomous execution without a policy boundary. If a bot or AI agent can install third-party code, the organisation has created a delegated trust chain and should govern it like any other privileged non-human identity. Accountability sits with platform owners, security governance, and the workflow owner together.

Why This Matters for Security Teams

When an AI agent or automation system can fetch and install dependencies, the issue is no longer just software supply chain hygiene. It becomes a delegated trust problem with real privilege, because the system is acting on behalf of a team, service, or business process. The practical question is not only whether the package was malicious, but whether approval, containment, and review boundaries were defined before execution. That is why guidance such as the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework is useful: it pushes accountability toward the people who set the operating model, not just the code that executed it.

Security teams often miss this because automation makes the failure look technical, when the real gap is governance. If a workflow can reach package repositories, write to build systems, or promote artifacts without a human checkpoint, then that workflow has become a privileged non-human identity in practice. The accountable parties are usually platform owners, the workflow owner, and the security function that approved the trust boundary. In practice, many security teams encounter the accountability question only after a compromised dependency has already been pulled into production, rather than through intentional delegated-authority design.

How It Works in Practice

Accountability should follow the control point that allowed the install, not the last system that touched the package. If an AI agent or bot was permitted to install dependencies, then the organisation should treat that permission as privileged access with explicit ownership, logging, and revocation paths. The agent may execute the action, but it does not own the risk decision. That responsibility sits with the team that designed the workflow, the platform team that exposed the capability, and the governance function that defined acceptable use.

In operational terms, this means setting clear rules for when autonomous installation is allowed, what sources are approved, and which actions require human approval. Current guidance suggests that the following controls matter most:

• Restrict dependency installation to trusted registries and signed artifacts where possible.
• Separate build, test, and release permissions so an agent cannot move from recommendation to production change without review.
• Record provenance for every install action, including the actor, tool, repository, and approval path.
• Use policy boundaries for autonomous systems the same way privileged access is bounded for human administrators.
• Continuously monitor for anomalous package changes, repository drift, and unexpected network access.

That pattern aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, configuration management, audit logging, and supply chain protections. It also maps naturally to threat modelling guidance in the CSA MAESTRO agentic AI threat modeling framework and attack-pattern thinking in the MITRE ATLAS adversarial AI threat matrix, especially where prompt injection, tool abuse, or poisoned dependencies can alter agent behaviour. These controls tend to break down when the agent can self-modify its toolchain, because provenance and approval become indistinct after the first automated trust decision.

Common Variations and Edge Cases

Tighter control often increases engineering overhead, requiring organisations to balance speed of automation against auditability and blast-radius reduction. That tradeoff is especially visible in CI/CD pipelines, developer copilots, and agentic workflows that install packages as part of routine task completion.

There is no universal standard for this yet, but current guidance suggests a few practical distinctions. If the automation only recommends a dependency and a human approves the change, the human approver and the control owner remain accountable for that decision. If the agent is allowed to install dependencies autonomously within a bounded environment, accountability shifts to the team that authorised the boundary and failed to constrain the action. If the system pulls from external package ecosystems without pinning versions, validating signatures, or enforcing allowlists, then the risk expands from a single bad package to a broader supply chain exposure.

This is where identity governance intersects with AI security: an agent acting with tool access should be governed like a privileged non-human identity, with least privilege, separation of duties, and revocation procedures. In high-regulation environments, teams should also map these controls to the organisation’s incident response and resilience obligations, because dependency compromise can quickly become an operational continuity issue. The practical test is simple: if no one can answer who approved the autonomy, the accountability model is already too weak.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent installs a malicious skill?
• Who is accountable when an AI agent or build pipeline introduces malicious code?
• Who is accountable when an AI coding agent sends traffic to the wrong system?
• When should organisations treat an AI agent as a privileged system?