Why does AI make software supply chain risk harder to control?

Why This Matters for Security Teams

AI changes software supply chain risk because it compresses review time while increasing the volume and variability of changes that enter the pipeline. That makes commit-stage controls, provenance checks, and secret scanning more important, but also harder to keep effective. The issue is not only speed; it is that AI introduces non-human actors whose outputs can bypass the human assumptions embedded in old review models. NIST’s NIST Cybersecurity Framework 2.0 still applies, but the control problem now includes machine-generated code paths and machine-issued credentials.

NHIMG research shows how quickly this can become real-world exposure. In Reviewdog GitHub Action supply chain attack, secrets were exposed through the workflow itself, not just the application code. That pattern matters because AI-assisted development does not only increase code output; it also increases the chance that secrets, tokens, or unsafe dependencies move through build and review steps unnoticed. The underlying problem is that traditional governance was designed for identifiable developers, predictable commits, and relatively stable change rates.

In practice, many security teams encounter secret sprawl and unauthorized changes only after a pipeline event has already widened the blast radius, rather than through intentional review design.

How It Works in Practice

At a technical level, AI makes the supply chain harder to control because it accelerates the exact points where trust is usually assumed. Code assistants can create commits faster than reviewers can inspect them, while autonomous agents can chain tools, open pull requests, call internal APIs, and trigger builds with little human intervention. That means the security model has to shift from static trust in the developer to runtime trust in the workload. Current guidance suggests treating AI-generated activity as a separate identity class, with intent-based authorisation and short-lived access rather than standing permissions.

That is why workload identity and just-in-time credentialing matter. A strong model issues ephemeral secrets per task, binds them to the agent or job identity, and revokes them automatically when the task ends. This is more robust than long-lived tokens sitting in repositories, CI variables, or chat transcripts. The scale of the problem is visible in NHIMG data: Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack both show how quickly secrets can be harvested once a workflow is compromised. GitGuardian and CyberArk also report that the average time to remediate a leaked secret is 27 days, which is far too slow when an attacker can reuse that credential immediately.

• Use workload identity for the agent or CI job, not a shared human account.
• Issue JIT credentials with the narrowest possible scope and the shortest practical TTL.
• Evaluate policy at request time, based on intent, repo context, and action risk.
• Assume leaked secrets remain exploitable until revocation is confirmed, not merely detected.

These controls tend to break down in fast-moving CI/CD runners and shared automation environments because identity, review, and secret handling are often split across different teams and tools.

Common Variations and Edge Cases

Tighter AI-driven controls often increase operational overhead, requiring organisations to balance developer speed against the cost of runtime enforcement and revocation. There is no universal standard for this yet, especially for multi-agent pipelines and mixed human plus agent workflows. Some teams try to solve the problem with stronger RBAC, but that approach is limited when an agent’s next action depends on prompt context, tool output, or external data. In those cases, static roles do not express intent well enough.

One common edge case is repository privacy. Internal repositories are often treated as safer, yet NHIMG and vendor research show that secrets still surface there at high rates, and AI-related credential leaks are rising quickly. Another is non-code leakage: credentials can appear in Slack, Jira, or documentation, so the security model must extend beyond Git history. For deeper context on how identity failures compound across incidents, see The 52 NHI breaches Report and Top 10 NHI Issues. OWASP’s OWASP Non-Human Identity Top 10 is useful here because it frames the problem as governance of machine identities, not just code quality.

Where agent behaviour is highly autonomous, the practical limit is simple: if the system can decide, chain, and execute faster than humans can approve, then control has to move to ephemeral identity, policy-as-code, and continuous verification.

Related resources from NHI Mgmt Group

• Why do AI systems make NHI risk harder to control?
• How should teams reduce the risk of exposed AI credentials being abused?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do agentic AI systems make NHI risk harder to manage?