AI Agents Have Created A New Software Supply Chain

Companies spent years learning that a software dependency downloaded by one developer can create a security problem across an organisation.

An agent does not work only with the model its company selected. It uses tools, skills, plug-ins, connectors and Model Context Protocol servers to reach browsers, databases, code repositories, calendars and internal applications. Each component expands what the agent sees and what it is able to do.

Security investors have started treating those components as a software supply chain of their own. AI security company AIR emerged from stealth in September after raising $50 million across two seed rounds. Its product inventories corporate agents, checks the tools and components attached to them and blocks access to software or external services that fail security rules.

The size of an early funding round matters less than the problem investors believe needs a new product category. Companies often do not know how many agent components they are already running.

The model is only one dependency

Enterprise AI procurement often focuses on the model provider. Security teams review where prompts go, whether the provider trains on corporate data, how long information is retained and which certifications the service carries.

An agent changes the architecture after procurement. A user connects the approved model to an MCP server. The server provides access to a CRM. Another skill searches the web. A plug-in retrieves files. A browser tool logs into an external platform.

The company approved one AI service and ended up operating a chain of components from several suppliers.

Attackers do not need to compromise the model if a weaker component already possesses the permissions they want. The security review therefore has to follow the agent’s complete tool path.

MCP made integrations easier and increased the inventory problem

Model Context Protocol gives AI applications a standard way to connect with external data and tools. Developers no longer need to create a bespoke integration every time an agent needs access to a repository, database or business application.

Standardisation accelerates deployment. It also lowers the effort required to add another connection. An employee experimenting with an AI workflow might add a server because it solves a practical task in minutes. A development team installs another one for internal testing. A department connects a specialist agent to documents without registering the integration centrally.

Traditional software asset management already struggles with shadow IT. Agents introduce shadow permissions. Security teams therefore need to know more than which AI applications employees use. They need to know which systems each agent reaches and through which component.

A harmless-looking skill inherits the agent’s authority

A research agent restricted to public websites creates a smaller operational risk than an agent with access to customer records, source code and email. A compromised tool attached to the second agent operates in a richer environment.

Security teams have long applied least-privilege principles to human accounts. Agents need the same treatment. A sales agent retrieving CRM records does not require access to payroll. A coding agent does not require the chief executive’s mailbox. A document assistant does not need production database credentials merely because the underlying model is technically capable of using them.

Companies that give one general-purpose agent broad access create the same security problem as giving one employee administrator privileges across unrelated systems.

The convenience appears first. The blast radius appears later.

Component provenance now matters

Open-source software gave security teams the concept of the software bill of materials.

An organisation inventories libraries inside an application so that a newly discovered vulnerability tells the team where the affected component exists.

Agents need a comparable record.

The inventory includes the model, agent framework, skills, MCP servers, browser extensions, APIs, credentials and external services involved in a workflow.

Version information matters as well.

An MCP server that behaved safely when approved in June is not necessarily the same component after an update in September. A plug-in changes ownership. A vendor adds functionality. An agent receives new permissions because another workflow needed them.

Continuous discovery makes more sense than a one-time approval form.

Security teams need to test behaviour, not only configuration

An inventory tells a company what exists. Runtime monitoring shows what the agent actually does. An agent with permission to query a database might normally read ten records per task. Thousands of queries in several minutes deserve attention. A tool designed to access one corporate domain suddenly contacting an unrelated external service also deserves attention.

Behavioural controls become more useful as agents receive freedom to choose their own intermediate steps.

The company no longer specifies every API call in advance. It gives the agent a goal and lets the system decide how to complete part of the work.

Security architecture therefore needs boundaries around the decision-making space rather than relying entirely on prewritten workflow logic.

AI agents did not remove the software supply chain. They added another layer to it, one with access to the existing applications underneath.