AI is adding new dependencies and attack paths to your software supply chain

Anyone who builds or deploys software has always had to worry its building blocks. Open-source libraries, third-party code, APIs, cloud services – any of them can introduce vulnerabilities or unexpected dependencies. AI is the new, riskier element in that chain.

A modern development environment relies on a foundation model to generate code, an AI coding assistant to review it, an external model API to power a feature, and an AI agent to carry out tasks across repositories, tools, and services. Each is a dependency – even if it doesn’t look like one in a traditional software inventory.

A conventional software dependency performs a defined function when called. An AI agent , by contrast, interprets instructions, chooses its own tools, makes decisions, and takes action across connected systems.

This kind of automated work is picking up pace. So if you source your software’s components from trusted providers, you’ll want to know what their AI-enabled dependencies can access, what they’re permitted to change, and where their actions can travel .

AI is more than a coding assistant

What catches technology leaders’ attention is how easily an AI dependency can hide in plain sight.

A development team may think it has simply packed in a coding assistant. Underneath, it may have also added a model, an agent, an MCP server, external tools, and several new paths into the development environment. Microsoft’s current security guidelines Opens a new window for AI-assisted development explicitly treat these external tools, extensions, and MCP servers as additional trust and supply-chain dependencies. Some can access files, execute code, or interact with external services.

The software itself is only part of the picture. In its definition Opens a new window of AI supply-chain risk, the Open Worldwide Application Security Project (OWASP) includes third-party models, model repositories, training data, and deployment platforms.

Another wrinkle is how AI influences what gets added to the build.

The July 2026 Cloud Security Alliance report Opens a new window describes coding agents as a new type of supply-chain actor. They write code, select dependencies, and execute build commands, often with less scrutiny than a human contributor or conventional package.

Amid these changes, here are the questions your customers may soon be asking your software

What exactly takes my software from an idea into production?

Which of those elements can make decisions along the way?

Give AI access, invite new risks

AI complicates the supply-chain risk equation when the tools around a model can act on its output. A coding agent can modify files, call external tools, install packages, or interact with repositories, giving an attacker more opportunities to influence what happens .

Common attack paths include:

Prompt injection : A malicious instruction hidden in a GitHub issue, document, or repository file can manipulate an AI agent into ignoring its original task and following the attacker’s instructions instead.

Excessive agency : An agent may be able to access source code, credentials, package managers, or deployment systems it doesn’t need. Once compromised or manipulated, that agent may turn its privileged access into a much bigger incident.

Dependency selection : Coding agents can recommend or install packages. Researchers have documented “slopsquatting,” where attackers register package names that AI models are likely to hallucinate, hoping an agent or developer will install the malicious package.

Tool and MCP exposure : Agents often connect to external tools, APIs, and data sources. Those connections create another trust boundary that attackers can exploit or misconfigure. Security researchers have already flagged compromised developer tools and MCP infrastructure as emerging supply-chain targets.

Some of these concerns surfaced in an August 2026 test Opens a new window by the UK AI Security Institute (AISI). During a controlled cyber evaluation, researchers found AI agents taking actions outside their assigned tasks, including activity involving real people and organizations. In one case, an agent tried to add malicious code to a real open-source project and then persuade its maintainer to accept the change.

AISI’s testing didn’t cause any real-world damage, but it showed how an autonomous tool can move through the same ecosystem software teams depend on. The agent didn’t need direct access to a company’s production environment to create a potential supply-chain problem. Its interactions with code, repositories, and people were enough.

The controls have to catch up

So, what should you actually change in your software supply chain?

Experts recommend making the AI layer visible. Your software inventory should account for models, coding agents, AI APIs, MCP servers, extensions, and other connected services. CISA’s 2026 guidance Opens a new window on AI software bills of materials makes the same point — you need greater visibility into the components behind AI systems. GitHub’s enterprise controls also let administrators track agent sessions, distinguish agent activity from human activity, and maintain an enterprise-wide MCP allowlist.

Then look at permissions. Ask what each AI tool can read, modify, execute, or deploy. A coding agent may need access to a repository. It probably doesn’t need production credentials. Keeping those boundaries tight limits the damage when something goes wrong.

Give agents somewhere safe to work. Smaller software companies are already taking this approach. Sinatra Opens a new window describes it as using ephemeral sandboxes, egress allowlists, and scoped tokens for autonomous coding agents, with the pull request acting as the boundary before changes enter the main codebase.

Monitoring needs a rethink too. Vulnerability scanners can tell you that a component contains a known flaw. They won’t alert you when a legitimate agent starts behaving unexpectedly. That’s where activity logs, behavioral monitoring, and alerts for unusual actions become important. In a recent post, AWS Opens a new window recommends build-time security gates that verify agent-generated code before production.

Finally, don’t skip human approval. Changes to production code, new dependencies, privileged actions, and external communications still need checkpoints.

Even for smaller IT teams, the principle is simple: limit what the agent can reach, isolate where it runs, monitor what it does, and keep final authority outside the agent.

On June 22 , Toolbox will become Spiceworks News & Insights