AI agent ecosystems turn software supply chain risk into a scaling problem

At a glance

What this is: Pluto Security says AI agent ecosystems are expanding software supply chain attack paths by letting autonomous tools fetch dependencies, invoke plugins, and execute code across development workflows.

Why it matters: This matters because security teams must govern AI agents as part of the software supply chain, not just defend repositories, packages, and CI/CD systems in isolation.

By the numbers:

• Pluto Security says the company is officially out of stealth with $42 million in total funding.

Context

AI agents now sit inside software delivery paths, which means supply chain security is no longer limited to code review, dependency scanning, and artifact signing. The governance gap is that autonomous systems can fetch, select, and execute software components before a human ever sees the decision.

That shift matters because a compromise in one external dependency can propagate through repositories, build systems, and downstream applications far faster than traditional software risk models assume. In practice, the problem is less about one bad package and more about uncontrolled machine-mediated trust across the pipeline.

Key questions

Q: What breaks when AI coding agents can install packages or call tools without approval?

A: The trust boundary breaks. If an agent can select dependencies or invoke tools on its own, a compromised package or malicious integration can reach build and runtime systems before anyone reviews the action. The practical failure is not just malware execution, but delegated trust that lets one compromised source influence many downstream systems at machine speed.

Q: When should organisations prioritise provenance checks over faster developer workflows?

A: Whenever the workflow lets autonomous systems fetch, select, or execute third-party components. Provenance checks become a first-order control when the same action can modify repositories, expose secrets, or trigger builds without human review. If a control reduces speed but protects high-trust paths, it should be prioritised before broadening agent autonomy.

Q: What should teams look for when assessing AI agent supply chain risk?

A: Teams should look for typosquatting, unexpected network behaviour, secret exfiltration patterns, and unusual response shaping. These are often earlier indicators than confirmed malware. A good assessment combines package provenance, runtime telemetry, and access scope so suspicious components can be isolated before they influence production workflows.

Q: How should teams govern AI coding agents alongside secrets and supply chain controls?

A: Treat agent settings, dependency trust, and secret exposure as one control surface. If a package can alter local execution and the same session can read cloud or publishing credentials, then the risk is multiplicative. Governance should therefore combine provenance checks, secrets reduction, and persistence monitoring.

Technical breakdown

How autonomous dependency retrieval changes supply chain exposure

AI coding agents often resolve missing dependencies by querying public registries or external sources without a human in the loop. That changes the trust model: the agent is no longer just suggesting code, it is also selecting and importing software artefacts. If the source is compromised, the agent can ingest malicious components into the build path before standard review or approval checkpoints activate. This is especially risky when the agent has permission to write code, alter manifests, or trigger builds. The core issue is not automation itself, but automation that inherits trust without provenance checks. See the AI Coding Agents Security Guide.

Practical implication: Treat dependency resolution by agents as a controlled action, not a convenience feature.

Why plugins and tool chains create a wider attack surface

Agent ecosystems rely on plugins, MCP servers, and other tools to read files, call APIs, and execute code. Each integration adds a new trust boundary, and the agent often cannot reliably distinguish a legitimate tool response from a malicious one that mimics expected output. That makes tool selection and tool execution separate security problems. A malicious tool can steer the agent toward exfiltration, code injection, or false outputs while appearing operationally normal. In this model, the attacker does not need to defeat the application directly; they only need to influence the agent's trusted tool path. See the MCP Security Guide.

Practical implication: Inventory every agent tool, gate its permissions, and validate what it is allowed to return.

Why provenance and behavioural controls matter more than static scanning

Traditional supply chain controls such as SBOMs, dependency scanners, and artifact signing are built for static components. They are weaker against agentic workflows because the risky behaviour happens at selection time, during orchestration, or inside a live tool chain. That is why provenance alone is not enough. Organisations need behavioural controls that watch maintainers, package relationships, repository interactions, and unusual execution patterns across the full pipeline. Static inspection still matters, but it has to be paired with runtime policy and trust decisions that reflect the agent's actual authority. See the Agentic AI Security Guide.

Practical implication: Combine provenance checks with runtime policy enforcement for agent-driven build and delivery paths.

Threat narrative

Attacker objective: The objective is to compromise one trusted software path and use the agent's own authority to spread access, code execution, or secret exposure across the development ecosystem.

1. Entry occurs when an AI agent autonomously retrieves a dependency, tool, or package from an external repository or registry that has been tampered with or impersonated.
2. Credential or code access follows when the agent executes the downloaded component inside a build, development, or orchestration workflow with elevated trust.
3. Escalation happens when the malicious component reaches repositories, APIs, or adjacent tools through the agent's delegated permissions and trusted integrations.
4. Impact is achieved when attackers use that trusted path to inject code, exfiltrate secrets, or propagate compromise across downstream systems.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

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

AI agents are becoming supply chain amplifiers, not just consumers of code. The governance problem is that an autonomous system can fetch, evaluate, and execute software components faster than human control points can intervene. That changes the supply chain from a linear approval process into a machine-mediated trust graph. Practitioners should treat agent activity as part of the software delivery attack surface, not as a separate automation layer.

Tool trust is now a policy problem, not a parsing problem. A malicious MCP server or plugin does not need to break the agent's logic if it can shape the agent's trusted inputs and outputs. That means the relevant control is delegated authority, not merely content inspection. MCP security becomes important because the risky event is tool invocation under assumed trust, not just tool installation. Practitioners should govern which tools an agent may call and what evidence they must present before execution.

Static supply chain controls are necessary but no longer sufficient on their own. Dependency scanning, SBOMs, and signing still reduce baseline risk, but they do not fully address behaviour inside autonomous workflows. The new failure mode is selective trust in runtime actions, especially when an agent can amplify a single compromised dependency into multiple downstream systems. Security programmes should add behavioural monitoring, provenance enforcement, and explicit task-scoped permissions to their software supply chain model.

Behavioural provenance gap: the central weakness is not just unverified packages, but the absence of controls that tie agent actions back to a trusted source, purpose, and approval context. When provenance and authorisation are disconnected, an attacker only needs one weak link to influence many systems. Practitioners should close the gap by binding agent identity, tool identity, and package provenance together in policy.

Identity governance now extends into the software supply chain itself. When AI agents can act on behalf of developers, build systems, and automation pipelines, identity and privilege controls become supply chain controls. That is why access scope, delegation, and revocation must apply to agents as much as to human operators. The identity layer is no longer adjacent to supply chain security; it is part of the control plane.

From our research library:

• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: AI Coding Agents Security Guide

What this signals

Agent-driven supply chain attacks create a new governance class: delegated software trust. The problem is not just malicious packages, but autonomous systems that can choose, fetch, and execute them before a human can intervene. Security teams should measure whether agent permissions are bound to approved sources and whether build paths can be traced back to a specific trust decision.

The rise of agentic workflows makes provenance, identity, and runtime policy inseparable. If an agent can act on behalf of the pipeline, the pipeline needs controls that limit where it can go, what it can run, and how far a compromised component can spread.

CI/CD runners are already a high-value target in supply chain compromise, with 59% of compromised machines in a major 2025 supply chain attack being CI/CD runners rather than personal workstations. That is a signal to move agent governance and pipeline containment closer to the build system itself, not leave them at the endpoint layer.

For practitioners

• Restrict agent permissions to task-scoped access Limit each coding or orchestration agent to the minimum repository, package, and API rights needed for the current task, then expire those rights when the task ends. See the AI Agent Authorisation Guide.
• Require provenance checks before agent-driven installs Block agent-triggered dependency resolution unless the package source, maintainer identity, and artefact provenance are verified against approved policy.
• Treat plugins and MCP servers as high-risk integrations Review every agent tool for read, write, execute, and network capabilities, and remove any integration that can exfiltrate data or return untrusted instructions.
• Add behavioural monitoring to supply chain controls Monitor repository activity, dependency selection, maintainer changes, and unusual build behaviour so a compromised package or tool is detected after invocation as well as before.
• Separate human approval from autonomous execution Force step-up approval for high-impact actions such as publishing code, changing dependencies, or invoking external tools that can alter build artefacts or secrets exposure.

Key takeaways

• AI agents expand supply chain risk because they can select and execute dependencies with machine speed and delegated trust.
• The main evidence is not a single bad package but a new control gap around provenance, tool trust, and runtime authority.
• The strongest response is to bind agent permissions, dependency approval, and behavioural monitoring into one governance model.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI Agent Authorisation Guide · Agentic AI Security Guide · MCP Security Guide

Key terms

• AI Agent Supply Chain: The set of repositories, registries, tools, and build steps that an AI agent can touch while completing a task. It becomes a supply chain risk when the agent can fetch or execute external components with delegated trust and limited human review.
• Provenance-Aware Enforcement: Provenance-aware enforcement means applying security policy using knowledge of a data item’s origin and journey, not just its current location or label. It is useful when content is copied, renamed, or repackaged across collaboration tools, endpoints, and AI workflows.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• Tool Boundary: The tool boundary is the point where an agent's model output becomes an enforced action. In agentic systems, this boundary acts like a permission layer because tool names, schemas, and implementations determine what the agent can actually do, not just what it appears able to request.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, workload identity, and secrets management. It helps practitioners connect identity controls to the broader security programmes that now depend on autonomous systems.