AI Agents Bring Software Supply Chain Risk Beyond the Prompt

Ask an agent to clean up a CSV or edit a video, and an ordinary request can turn into downloading and running someone else's software before anyone treats it as a supply-chain event.

The agent decides it needs a library, installs it and its dependencies, writes a script, and runs it. You may approve a command along the way. For the employee, package selection is an implementation detail between the request and the result. For the security team, it is a decision about whose code gets to run and what that code can access.

Agent skills raise the same problem, with more baggage: a skill can bring its own scripts and dependencies, and it can be malicious on its own.

The prompt said "clean this CSV." What the agent installed to do it can skip the controls we built for software dependencies, because those controls are usually tied to repositories. They need to follow the task instead.

A task with dependencies, but no project to monitor

Imagine an operations employee asking an agent to reconcile two customer exports: normalize company names, remove duplicates, and explain which records changed. The agent installs a Python library for matching names, along with its dependencies, and produces the report. The entire task happens in a working folder on a laptop. There is no repository, pull request, or build pipeline. The same is true when an agent installs FFmpeg and a wrapper to cut webinar clips: the work is not a software project in the employee's mind, but it still introduces software.

The employee checks the report. The company names look right, the duplicates are gone, and the explanation is useful. Nothing about that result tells the employee where the library came from, whether its dependencies were checked, or what the installed code did beyond matching names.

Compare that with adding a dependency to a product. In an established development workflow, there is somewhere to record the dependency, a process that can check it, and a project that can receive alerts later. With the customer exports, the report gets shared and the implementation is forgotten. If the installed packages never enter a monitored inventory, the security workflow has nothing to act on.

Snyk scans local projects, and Dependabot alerts track dependencies in a repository's dependency graph. The gap is whether anyone invokes those checks for this task, in this folder, before the software runs. Having a scanner available does not put these downloads in its scope.

Even worse: Installation can already be execution

It is tempting to treat installation as preparation and the script as the thing that needs checking. That can be too late.

npm documents installation lifecycle scripts, including preinstall, install, and postinstall, that run during installation unless configured otherwise. pip's security documentation warns that installing distributions can involve running arbitrary code; building a package from a source distribution is one way that happens. A control that waits for the agent's script to run can miss earlier execution.

A temporary Python environment does not change this. A virtual environment separates package installations. It does not restrict the files a process can read or the network connections it can make, and deleting it afterward does not reverse what the code already did.

Once running, malicious code can use whatever permissions its process has, unless the environment restricts them. That can include the customer export, unrelated files, or credentials inherited through environment variables. The matching library could return an accurate result while malicious code in it or in a dependency copies the input elsewhere. The package does not need to reach production to access valuable data. The employee has already brought the data to it.

The controls need to follow the task

People have downloaded utilities for one-off work for years. Agents make that workflow available to people who would never choose a Python package themselves, and they compress selection, installation, and execution into a small part of completing a request.

Approvals and isolation can constrain that. But an employee approving a command may only understand that the agent needs it to finish the job. I would not make their packaging expertise the control we depend on. The controls belong around the task: before anything installs, while it runs, and after it is done.

Before installation. Approved tools and controlled sources reduce unfamiliar downloads for routine work. If the same reconciliation happens every week, a reviewed matching tool beats a fresh package choice each time. Check what does get installed before it runs. Known vulnerability checks catch flawed versions of legitimate software, such as a parser a crafted file can exploit, but they do not establish that an unfamiliar package is trustworthy. A clean scan is not proof of safety.

While it runs. Give the task what the reconciliation actually requires: the two input files and an output location. Keep unrelated files outside its reach, and make network access deliberate. Downloading a library does not mean the process needs unrestricted outbound access while it handles customer records, so separate those permissions rather than granting both for the whole task.

Credentials deserve particular attention, because a local process can inherit secrets the task never needed. As Ariel explains in Stop Giving AI Agents Direct Access to Secrets, access to an authorized action does not have to mean access to the credential behind it. This reconciliation needs no service credentials at all.

Afterward. Record which agent introduced which package or binary, from which source, at which version, with which dependencies: the versions actually installed, not the ones the agent said it planned to use. When a dependency is later identified as malicious or vulnerable, the security team needs to find the affected machines and tasks without asking employees to reconstruct their commands. At Autonomous, we scan these packages, libraries, and tools. Sometimes we find malicious packages, and when we do, we warn our customers.

A useful test is to have an agent complete an ordinary data task in your employee environment. Then ask your security team what it installed, what was checked, and what the process could access. If reconstructing that requires someone to remember a terminal session, you have found a gap worth addressing.

By the time a package has helped produce a perfectly good report, it may already have had access to the data you needed to protect.