Who is accountable when unapproved AI dependencies ship into production?

Why This Matters for Security Teams

When unapproved AI dependencies reach production, accountability is not limited to the engineer who merged the code. It spans the release owner, the security approver, the model or platform owner, and the control functions that were supposed to prevent the dependency from entering the build. That matters because AI dependencies can introduce hidden data flows, license risk, insecure inference paths, model provenance gaps, and vendor drift long before anyone notices a functional issue.

The practical problem is governance failure, not just technical failure. Security teams need to know whether dependency intake checks, software bill of materials practices, and AI-specific approval gates were defined before deployment, then whether they were actually enforced. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of traceable control ownership, but the control framework only helps if the organisation assigns named owners and preserves evidence. In AI environments, the absence of a documented approval chain often becomes the real exposure.

In practice, many security teams encounter the accountability gap only after the dependency has already been promoted, rather than through intentional release governance.

How It Works in Practice

Effective accountability starts by separating operational responsibility from oversight responsibility. Product owners and engineering leads should be accountable for what enters the release, while security and risk functions are accountable for defining the gates, logging exceptions, and verifying that the gates were used. For AI-heavy systems, that scope should include model packages, embeddings libraries, orchestration tools, agent frameworks, and any external service that can influence prompts, outputs, or data retention.

A workable process usually includes four control points:

• Dependency discovery during build and release planning, including direct and transitive AI components.
• Approval criteria that cover provenance, licensing, data handling, and known security issues.
• Exception handling with explicit risk acceptance, expiry dates, and named approvers.
• Post-release evidence retention so auditors can reconstruct who approved what, when, and why.

This is where software supply chain discipline meets AI governance. The most useful reference point is NIST AI Risk Management Framework, which treats accountability as part of governance rather than a last-step compliance check. For production environments, the question is not whether an AI dependency is useful, but whether the organisation can prove it was reviewed against defined risk criteria before release. Where AI agents or orchestration layers are involved, the approval record should also show what execution rights the dependency receives and whether it can call tools, access secrets, or alter data paths.

That discipline usually requires coordination between CI/CD, procurement, architecture review, and incident response. These controls tend to break down when development teams can bypass the release path through ad hoc package installs or shadow AI services because the approval record no longer matches the production reality.

Common Variations and Edge Cases

Tighter dependency governance often increases release friction, requiring organisations to balance delivery speed against assurance depth. That tradeoff becomes more visible when teams rely on open-source AI libraries, managed model APIs, or fast-moving experimental tooling, because the security posture can change faster than the review process.

There is no universal standard for this yet, especially for agentic ai and rapidly evolving model ecosystems. Some organisations treat every AI dependency as a third-party risk item, while others tier review based on data sensitivity, execution authority, and external connectivity. The best practice is evolving toward risk-based classification rather than blanket approval rules, but the accountability principle stays the same: if a dependency can shape outputs, move data, or trigger actions, someone must be explicitly responsible for its approval and ongoing review.

This also intersects with identity governance when an AI component can use service credentials, assume workloads, or act on behalf of users. In those cases, the release record should show who authorised the identity behind the dependency, not just who accepted the code. For implementation detail, organisations often map this to OWASP Top 10 for Large Language Model Applications and ISO/IEC 42001, especially where oversight evidence must survive audit, incident review, or regulatory inquiry.

Related resources from NHI Mgmt Group

• What should organisations do before allowing AI-generated dependencies into production?
• Who is accountable when an AI guardrail fails in production?
• Who should be accountable when AI-assisted IT actions affect production systems?
• Who is accountable when an AI agent deletes production data?