Supply chain attack defenses now depend on install and pipeline controls

At a glance

What this is: Aikido argues that modern supply chain attacks are exploiting install-time trust, mutable pipeline references, compromised maintainer accounts, and agentic toolchains before traditional controls can react.

Why it matters: This matters because engineering and IAM teams now have to govern trusted code, pipeline identities, and agent permissions as a single attack surface, not separate problems.

By the numbers:

• Open-source malware detections jumped 73% in 2025.

Context

Supply chain security fails when teams assume the install layer, build pipeline, and developer workstation are separate trust zones. In practice, an attacker only needs one trusted handoff to turn a package release, a GitHub Action, or a maintainer account into execution inside a software delivery path.

The identity angle is direct. Package publishers, CI tokens, bot accounts, and agent permissions all behave like non-human identities when they can act on behalf of the development process, so access scope, provenance, and auditability become governance controls rather than optional hardening steps.

Key questions

Q: What breaks when install-time trust is too permissive in supply chain security?

A: When install-time trust is too permissive, malicious packages can execute before review, validation, or telemetry has time to intervene. That turns publication speed into an attacker advantage. The practical failure is not just malware entering the environment, but code being allowed to run inside trusted build or developer workflows without a meaningful delay window.

Q: Why do mutable pipeline dependencies increase supply chain risk?

A: Mutable pipeline dependencies increase risk because the code your pipeline trusts can change after approval if it is referenced by a tag or moving pointer. That creates delegated authority without stable provenance. In practice, an attacker who controls the reference can swap benign code for malicious code while the pipeline still believes it is executing the approved dependency.

Q: How should security teams govern AI agent spend in CI/CD pipelines?

A: They should treat spend governance as a request-level control problem, not a billing review problem. The gateway should tag every call with owner metadata, track cumulative cost by repo and team, and enforce thresholds with clear alert and fail-closed behaviour. That makes cost overruns actionable and ties accountability to the workload that caused them.

Q: What should teams do after a supply chain dependency is compromised?

A: Teams should treat the compromise as a trust-reset event across the delivery path. That means revoking affected tokens, reviewing registry pushes and CI runs, checking for secret exposure, and replacing any mutable dependency references that may have inherited the same trust path. The goal is to contain propagation before the compromised component is reused elsewhere.

Technical breakdown

Why install-time trust is the first control boundary

Install-time trust is the moment a dependency crosses from external artifact to executed code. If a package can run postinstall scripts, if a registry release is accepted immediately, or if new versions are trusted by default, attackers only need to publish first and abuse the short delay before review catches up. That is why package age policies matter: they create a time buffer between publication and execution. The mechanism is simple but powerful. Delay reduces the probability that malicious releases can execute before detection, especially in fast-moving npm compromise campaigns.

Practical implication: enforce age-based install holds for newly published packages and treat install execution as a governed trust event.

Why mutable pipeline dependencies create identity risk

Pipeline actions, build tasks, and registry integrations are effectively code with delegated authority. When teams pin a GitHub Action or similar dependency to a tag instead of a commit SHA, they are trusting a moving pointer rather than an immutable artifact. That makes the pipeline identity dependent on whoever controls the tag or package release, which is exactly where supply chain attackers look. In NHI terms, this is delegated machine authority without strong binding to provenance. The control problem is not merely version drift. It is preventing pipeline identities from inheriting unbounded trust from third-party code.

Practical implication: pin pipeline dependencies to immutable references and scope the credentials those dependencies can reach.

How agentic toolchains widen the attack surface

Agentic tooling changes the meaning of input. In a normal workflow, a PR description or issue title is text. Once an AI agent reads that content into a prompt and can act on it, the same text becomes a possible instruction path. That is why prompt injection in CI is not just a model problem but a workflow trust problem. The agent sits at a high-privilege point, often with access to secrets, registries, or deployment steps. If its permissions are not tightly scoped, the attacker can convert untrusted content into actions that should never have been reachable from a user-generated field.

Practical implication: constrain agent permissions, isolate untrusted input, and log every action that an agent can trigger in the pipeline.

Threat narrative

Attacker objective: The attacker aims to convert one trusted dependency or account into broad execution and secret access across software delivery systems.

1. Entry occurs when attackers abuse trust in a package release, maintainer account, or mutable pipeline dependency to land code in the software delivery path.
2. Credential access or delegated authority follows when valid tokens, bot accounts, or published dependencies are used as if they were trusted machine identities.
3. Escalation happens when that trusted access reaches CI/CD runners, registry pushes, or developer environments with broader permissions than the original entry point should have had.
4. Impact is malicious code execution in build and install workflows, secret exposure, and downstream propagation into thousands of pipelines or releases.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• axios npm compromise 2026: North Korea-linked UNC1069 hijacked an axios maintainer's npm account to ship a backdoor that bots pulled into public repos within minutes.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time trust has become a governance boundary, not a convenience layer. Supply chain defenders cannot rely on downstream scanning alone when malicious packages execute within hours of publication. The relevant control question is whether a package is allowed to run before it has earned trust. Practitioners should treat publication age, provenance, and execution delay as part of the control plane, not as operational preferences.

Pipeline dependencies now behave like non-human identities with delegated authority. A tag, action, or bot token can carry more real privilege than the human who approved it, and that privilege often persists invisibly through the build system. The important governance gap is not just compromised code, but uncontrolled delegation to code that can mutate beneath the team. Practitioners should re-evaluate whether their CI trust model still assumes static, reviewable dependencies.

Agentic toolchains create a new form of supply chain exposure because prompt inputs can become execution inputs. That shifts the threat from code provenance alone to intent injection inside the software delivery workflow. This is where identity governance meets AI governance: agent permissions, data sources, and action scopes need to be bound together. Practitioners should treat agents as privileged system participants and not as neutral automation.

Supply chain security is increasingly an identity problem expressed through software delivery. The repeated compromise pattern is not random malware sophistication but weak control over who or what is allowed to act on behalf of the pipeline. Frameworks such as OWASP-NHI and MITRE ATT&CK matter here because they map the machine-account abuse and credential-access stages that underpin these incidents. Practitioners should align supply chain controls to machine identity governance, not just application scanning.

Auditability is now a first-class containment control for delivery systems. The article’s emphasis on registry pushes, CI runs, and token usage reflects the reality that standard authentication logs can miss live-session abuse. The named concept is delivery-path trust leakage: trust granted at install or pipeline time spills into execution paths that teams do not routinely inspect. Practitioners should close that leak by making execution telemetry part of routine governance.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Delivery-path trust leakage: supply chain incidents are no longer just package problems. They expose a wider governance issue in which install-time trust, pipeline delegation, and agent permissions all create execution paths that standard reviews do not fully see.

Security teams should expect more attacks that look like ordinary dependency updates but behave like identity abuse. The control question is whether a package, action, or agent can act before it has earned durable trust, and that is where provenance, scoped access, and telemetry have to converge.

The scale of the problem is already visible: open-source malware detections jumped 73% in 2025, according to the State of Secrets Sprawl 2026. That trend supports a more aggressive posture on install delays, immutable references, and machine-identity governance in delivery pipelines.

For practitioners

• Implement package age controls Block installation of newly published dependencies until they have passed a minimum age window, especially for packages that can execute scripts during install.
• Pin pipeline dependencies to immutable SHAs Replace mutable tags with commit SHA references for GitHub Actions and similar pipeline components so trusted code cannot change silently.
• Scope agent permissions tightly Limit what AI agents can read, write, and invoke in CI workflows, and separate untrusted text inputs from privileged execution paths.
• Capture audit logs for delivery activity Log registry pushes, CI executions, token use, and other live-session actions so incident responders can reconstruct what happened beyond standard authentication records.
• Review third-party dependency trust Inventory third-party actions, package sources, and developer tools that implicitly inherit pipeline authority, then remove any that cannot justify their access scope.

Key takeaways

• Supply chain attacks now succeed by turning trusted install and pipeline paths into execution channels that teams rarely govern tightly enough.
• The core weakness is delegated authority to code, tokens, and agents that can mutate or act before the organisation can verify them.
• Practical defence means slowing installs, pinning immutable references, constraining machine permissions, and logging live-session activity across the delivery path.

Key terms

• Package Age Policy: A package age policy blocks or delays installation of newly published dependencies until they have existed long enough to be vetted. It reduces the chance that a malicious release can execute before defenders, maintainers, or threat intelligence can react.
• Workflow Dependency Pinning: Workflow dependency pinning means locking an external action or component to a specific version tag or commit SHA. This reduces the chance that a reference silently changes over time, and it helps teams keep CI/CD behavior predictable when they depend on third-party automation.
• Agent Permission Model: An agent permission model is the set of controls that decides what an AI agent may do before an action is executed. In this context, a useful model evaluates the request, the declared task, and the business blast radius, not only the command syntax or a broad integration grant.
• Delivery-Path Trust Leakage: Delivery-path trust leakage is the condition where trust granted at install, build, or agent runtime spills into parts of the software pipeline that are not routinely governed or observed. It is a control failure that turns routine automation into an attacker pathway.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern delivery pipelines. It helps security and identity practitioners connect access control decisions to real-world service, workload, and toolchain risk.