TL;DR: Supply chain attacks increasingly target registries, CI/CD pipelines, developer machines, and agentic toolchains rather than production apps, according to Aikido. The practical lesson is that lockfiles, token scope, workflow hardening, and sandboxing now define the attack surface, not just code quality.
At a glance
What this is: Aikido’s checklist argues that supply chain attacks are increasingly decided by registry, pipeline and agent controls rather than by production application security alone.
Why it matters: For engineering, IAM, and security teams, that means the trust model now extends into package publishing, CI/CD identities, and agent tool permissions before code ever ships.
Context
Supply chain attacks are no longer limited to malicious code landing in production. The control problem starts earlier, where packages are pulled from registries, credentials are used in pipelines, and developer tooling can be abused to move from trusted software inputs to executable compromise.
That shift matters because the modern software supply chain is an identity problem as much as a software integrity problem. Token scope, publishing privileges, workflow permissions, and agent tool authorisation now determine whether a compromised dependency is contained or becomes a path into the build system and related environments.
Key questions
Q: What breaks when registry, pipeline, and agent controls are not in place?
A: Compromised packages and workflow changes can move from trusted inputs into build and release systems because the same identities are allowed to install, publish, and execute too broadly. The result is a supply chain compromise that bypasses production-centric controls. The failure is not just malicious code, but over-trusted upstream identities and tool permissions.
Q: Why do broad CI/CD and agent permissions increase supply chain risk?
A: Broad permissions turn a single compromised package, token, or tool into a reusable path across publishing, deployment, and adjacent systems. When build identities are not task-scoped, attackers can alter artefacts or trigger actions that defenders never intended to expose. Narrowing scope limits how far one trusted input can travel.
Q: How can security teams measure whether supply chain controls are actually working?
A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.
Q: What is the difference between protecting production apps and protecting the software supply chain?
A: Production protection focuses on what runs after release, while supply chain protection focuses on the identities, registries, pipelines, and tools that decide what gets built and shipped. The first reduces runtime exposure, but the second prevents compromise before code reaches production. Modern attacks increasingly target the upstream layer because that is where trust is easiest to abuse.
Technical breakdown
Registry trust and package integrity
Package registries are now an entry point because attackers often target the dependency layer before code reaches the build system. The security issue is not only whether a package is malicious, but whether provenance, age, lockfile pinning, and continuous scanning can stop an unsafe version from being accepted as trusted software. In practice, registry trust depends on controls that evaluate package reputation, release freshness, and unexpected dependency changes before installation or promotion. That makes dependency governance a supply chain control, not a software hygiene task.
Practical implication: treat package ingestion as a security decision and enforce review, pinning, and scanning before dependencies enter builds.
Pipeline identity and token scope
CI/CD pipelines are attractive because they often hold the credentials needed to publish, deploy, or access internal systems. If those identities have broad scope, an attacker who compromises a package or workflow can reuse pipeline privileges to alter artifacts, inject code, or access protected services. Token scoping, phishing-resistant MFA, and tightly segmented publishing rights reduce that blast radius by making pipeline identity less reusable outside its intended task. The issue is not just pipeline hardening, but making pipeline credentials narrow enough to fail safely.
Practical implication: reduce pipeline credential scope to the minimum publish or deploy task and isolate release privileges from broader environment access.
Agentic toolchains and MCP server trust
Agentic toolchains expand the attack surface because AI agents and MCP servers can be granted real operational permissions. If those tools can call services, access files, or execute actions without strong verification and sandboxing, a compromised toolchain can turn trusted automation into an execution path. Permission scoping and server verification matter because they constrain which tools an agent can reach and what it can do once connected. This is an identity governance problem for software actors: who the agent is, what it may access, and how much damage a mistaken or malicious action can cause.
Practical implication: verify MCP servers, scope agent permissions tightly, and sandbox agent actions so tool misuse cannot escalate into system compromise.
Threat narrative
Attacker objective: The attacker’s objective is to convert trusted build and automation paths into code execution, artifact tampering, or downstream access that bypasses normal production defences.
- Entry begins when an attacker targets the software supply chain through a registry package, compromised workflow, or other trusted build input rather than the production application itself.
- Credential or privilege abuse follows when pipeline tokens, publishing rights, or agent permissions are broad enough to let the attacker alter artifacts or reach internal systems.
- Impact occurs when the compromised dependency, workflow, or agentic toolchain is allowed to influence production software or adjacent environments without containment.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.
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
Supply chain defence has become an identity governance problem. The article’s core signal is that the decisive trust boundary is no longer the production workload, but the registry, pipeline, and agent identities that feed it. That means software supply chain security now depends on who can publish, who can approve, and which machine or agent identity can act with authority. Practitioners should stop treating these controls as adjacent engineering details and govern them as first-class access paths.
Registry and pipeline controls now define the blast radius of compromise. Once a package, token, or workflow is trusted upstream, the resulting damage is usually determined by how broad the surrounding permissions are. Lockfiles, token scoping, and workflow hardening are therefore not isolated safeguards, but controls over whether a single compromised input can spread into release systems or developer environments. Teams should measure these controls as exposure reduction, not just compliance.
Agentic toolchains introduce a new class of software actor risk. MCP servers and AI agents are not merely tools they are delegated actors with permissions that can be over-scoped, misused, or inherited too broadly. That makes the governance question similar to NHI control: assign the least authority necessary, verify the endpoint before trust is extended, and limit what the actor can touch at runtime. Practitioners should treat agent permissions as an access governance domain, not a developer convenience.
Continuous verification beats one-time approval in modern supply chains. The article reinforces a broader market shift toward ongoing validation of dependencies, credentials, and tool permissions rather than static trust at install or release time. That is a practical acknowledgement that supply chain compromise often appears legitimate until the moment it executes. Practitioners should move from checklist-based trust to runtime-adjacent verification across the build path.
Named concept: supply chain trust drift. The article shows how trust shifts as software moves from registry to pipeline to runtime, often without a corresponding change in control strength. That drift creates a gap between the assumed security of a component and the actual permissions it holds at each stage. Practitioners should model trust separately at each hop, not as a single property of the package or tool.
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.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Supply chain trust drift: the main governance lesson is that trust changes as code moves from registry to pipeline to runtime, while many control frameworks still assume a single approval point. That mismatch is exactly why upstream identity and permission controls now matter as much as application hardening.
The reader-facing implication is straightforward: if dependencies, workflows, and AI toolchains can act with broad standing authority, the organisation has already lost the containment battle before production sees the package. Teams should map each trust hop to a specific control owner and verify that the scope of action narrows rather than expands as software progresses toward release.
For practitioners
- Enforce dependency admission controls Require lockfiles, package age review, and continuous scanning before new dependencies are allowed into build or deployment paths.
- Scope pipeline tokens to one task Separate publishing, deployment, and administrative credentials so a compromised workflow cannot reuse the same token across stages.
- Harden workflow and build permissions Pin workflows, restrict who can modify release logic, and audit any privilege that lets automation reach production-adjacent systems.
- Verify MCP servers before delegation Require server verification, permission scoping, and sandboxing for agentic toolchains so delegated actions stay inside a narrow trust boundary.
Key takeaways
- Modern supply chain attacks increasingly succeed by abusing the trusted path into software, not by attacking production applications directly.
- Registry trust, CI/CD identity scope, and agent permission boundaries are now the controls that determine whether compromise stays contained.
- Teams that govern packages, tokens, workflows, and MCP permissions as one trust chain are better positioned to reduce blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed tokens and trusted build inputs that let attackers reuse upstream access. |
| NHI-05 — Overprivileged NHI | Broad pipeline and agent permissions are the main way a small compromise becomes a wider incident. | |
| NHI-10 — Human Use of NHI | Developer and operator workflows depend on machine identities that people can accidentally over-trust or misuse. | |
| Recommendation — Scan registries, pipelines, and developer tooling for leaked credentials and revoke any exposed NHI secrets immediately. Reduce NHI privilege to the minimum task scope across publishing, deployment, and tool delegation. Separate human operator actions from machine identity use and require explicit approval for high-risk delegation. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern relies on abusing credentials and moving from trusted build paths into adjacent systems. |
| Recommendation — Map supply chain detections to credential abuse and lateral movement so upstream compromise is hunted earlier. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about permission scope across registries, pipelines, and agents. |
| Recommendation — Review and tighten entitlements on build, release, and tool identities so trust cannot expand unnoticed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and scope control are central to preventing compromise of CI/CD and agent identities. |
| Recommendation — Use account management controls to remove stale build access and keep release identities task-specific. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token scope and credential handling are core to the pipeline and agent risks discussed here. |
| Recommendation — Apply authenticator management to rotate, scope, and retire pipeline credentials on a strict lifecycle. | ||
Key terms
- Supply Chain Trust: Supply chain trust is the confidence that the people, software, hardware, and services used to build and run a system are authentic, intact, and behaving as expected. In security practice, it depends on verifying provenance, integrity, dependencies, and update paths across suppliers, build systems, and operational handoffs.
- Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
- Agentic toolchain: A set of tools and services that AI agents can call to inspect, modify, or trigger actions across software workflows. These systems need identity and permission controls because they can act across boundaries without a human approving every step.
- Dependency Admission Control: The process of deciding whether a package is allowed into a build or deployment path. Strong admission control looks at lockfiles, package age, provenance, and scan results before a dependency becomes part of the trusted software stack.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build stronger control models for the delegated identities that modern software supply chains rely on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org