AI Coding Agents Have a Software Supply Chain, Too

Guest contribution by Michael Kantor, President of HOL.

A coding agent can read a repository, call an MCP server, execute a plugin and write the result back to the codebase. The setup screen may show only a handful of connections. What it cannot tell the reviewer is how those connections will behave after approval. A plugin may be updated, a remote server may add a tool, or credentials may gain access to another repository. The original security decision needs to account for those changes.

Most teams already have a process for reviewing software dependencies. Coding agents extend that problem beyond packages and libraries. Their dependencies may include local executables, instruction files, agent skills and remote MCP servers. Each can influence what the agent does, which systems it reaches and where data ends up. A package update is comparatively easy to spot. Changes to a remote service may arrive without a new file on the developer's machine.

Teams need a way to identify each integration, limit its access and revisit the approval when its capabilities or provenance change. That can be done without treating every new tool as an emergency.

Map the code and permissions behind each tool

A package name and version are still useful, but they describe only part of an agent integration. A local plugin runs code under the machine's permissions. An instruction file can change how the agent chooses actions. A remote MCP server can expose several tools, each with its own input schema and description. The host chooses when to call them. The inventory has to capture the actual service or code behind each entry, not just its display name.

For each integration, a reviewer should be able to find its source, effective permissions, data access and evidence of the revision currently in use. If one of those fields is unknown, record the gap rather than treating an incomplete inventory as an approval.

MCP tool annotations make this distinction especially important. Fields such as readOnlyHint and destructiveHint describe intended behavior. They do not enforce it. An untrusted server's description cannot substitute for the permissions held by the host or for an approval step enforced outside the model. Those are separate controls, and the review should check them separately.

Sources: MCP Tools specification (2026-07-28); MCP schema / ToolAnnotations

Build an inventory that a reviewer can use

Start with one inventory entry per enabled integration. Where a server exposes several tools with materially different powers, track those capabilities separately. A version-controlled manifest with a named owner will do the job for many teams; it is easier to review than a list of installed plugin names.

The entry should include:

• Identity and source: canonical repository or vendor domain, package registry, verified publisher/maintainer identity, and any redirects or mirrors involved in installation.
• Artifact and revision: exact package version and digest, commit SHA, container digest or, for a remotely hosted tool, endpoint and the provider's release/change identifier if one exists. Remote endpoints without stable revision evidence should be called out as an assurance gap, not marked verified.
• Runtime and change path: who operates the executable, who can update it, whether it auto-updates, and whether the server can change the capabilities it advertises.
• Permissions: filesystem access, working directory, shell/process execution, repository write privileges, network destinations, credentials, email or cloud APIs, and ability to publish or deploy.
• Data scope: types of inputs the tool receives, sensitive repositories or files it can read, and what leaves the local environment.
• Approval owner: the person or team responsible for accepting and periodically reviewing the integration, plus the reason it is needed.
• Evidence and review date: the source review, provenance checks, notable risks, test results if actual tests were run, current authorization decision and next review condition.

Record what the credentials permit, not merely what the tool is called. A tool labeled “read_issue” could be configured with a token that also has repository write privileges. The label tells the reviewer very little about the exposure. The token scope and the control that authorizes each call tell them much more.

Check the artifact before trusting it

A familiar repository or popular listing gives you a place to begin checking, not proof of origin. Follow the integration back to its official repository or release, pin an immutable revision where the ecosystem allows it, and record the digest. If the publisher provides a signature or build attestation, verify it against the artifact in use. “Latest” is a moving target and a poor audit record.

SLSA provides a useful method for this work. Its build provenance links an artifact to a claimed source and build process. Verification still has to establish that the attestation belongs to the artifact and that the builder and source are ones the consumer intended to trust. Even a correctly verified build can contain dangerous functionality. Provenance answers where the artifact came from, not whether its behavior should be permitted.

OpenSSF Scorecard can add information about repository practices such as branch protection, dependency pinning and known vulnerabilities. Use those findings as supporting evidence. They cannot tell you whether a plugin should have a deployment credential or whether a remote tool needs access to production data.

Sources: SLSA v1.2 provenance; SLSA v1.2 artifact verification; OpenSSF Scorecard checks

Check what the host actually permits

An agent will encounter untrusted material while doing ordinary work: code comments, issue descriptions, web pages and responses from external tools. Some of that material may contain instructions designed to redirect the agent. Prompt injection is a different failure mode from a compromised package, but both become more serious when the agent has broad credentials and few checks on its actions.

OWASP's 2025 Excessive Agency guidance describes the harm that comes from combining too much functionality, access and autonomy. The response starts with credential scope. A repository triage agent should not hold a deployment token. Read-only tasks should use read-only credentials. Sending mail, merging changes, altering infrastructure and transferring sensitive data should each pass a decision point outside the agent's generated text.

At intake, inspect the host configuration and walk through a normal task. Look at what the agent can invoke without interruption, which calls require approval and who enforces that decision. A screenshot of a permission prompt is not evidence that the same check applies to every relevant call.

Sources: OWASP LLM06:2025 Excessive Agency

Review again when permissions or provenance change

Approval needs a condition for reopening the decision. A signed-off installation tells you what was accepted at one point in time. It says little about the permissions or tool list six months later. Tie the review to changes in capability, ownership or provenance instead of relying entirely on a calendar reminder.

Reopen the review when the maintainer or upstream source changes; the binary or a material dependency changes; release signing or provenance changes; new file, shell, network or write capabilities appear; a token gains scope; an MCP server advertises additional tools; an endpoint or data recipient moves; the integration gets access to a more sensitive repository; or a credible advisory identifies new risk. These events tell you more about changed exposure than the age of the approval.

An established policy can allow a routine patch release through when its provenance checks pass and its permissions remain unchanged. A new write capability deserves closer review and may justify pausing use. Define those thresholds before the update arrives, while there is time to make a considered decision.

A sample change-review record could say:

• Integration: code-review helper, revision A to B.
• Change: adds a tool that can write files and open pull requests.
• Previous approval: read-only access to one repository.
• New authority requested: repository write permission.
• Decision: keep revision A active; test B with reduced permissions; require a repository owner to approve any write scope before rollout.
• Evidence: signed release identity, source diff, tool schema comparison and scoped-token configuration.
• Status: pending, not yet approved.

This example is illustrative, not a reported deployment or product test.

Start with what you can enforce

The controls can be introduced in stages.

First, account for the integrations already in use. Record an owner and permission scope for each one. Where an official source ought to exist, do not accept an untraceable installation. Prioritize tools that can reach the shell, network, credentials or sensitive data. An inventory that people maintain is better than a comprehensive one that nobody checks.

Next, pin and verify releases where possible, separate credentials by workflow and put sensitive calls behind an independently enforced approval step. Make expanded permissions a change-review event. Test whether you can disable a connection and revoke its credentials without waiting for a plugin or server provider to act.

For integrations that can affect production systems or sensitive accounts, go further. Run untrusted components in a restricted environment, test updates before enabling them, compare tool and permission manifests, and verify build provenance in CI where available. Logs should make it possible to trace an action to the integration revision and identity that performed it. Without that link, incident review becomes guesswork.

The evidence will vary. A local binary may have an identifiable hash and build record. A remote service may offer only a provider name, endpoint and release notes. Record those limits plainly and decide whether the remaining uncertainty is acceptable for that service's access.

Document how to turn the integration off

Add removal instructions to the same record used for approval. Who can turn off the integration? Which credentials must be revoked? Are there local artifacts to remove and action logs to preserve? When an advisory arrives, those answers should already be available.

Stopping a local process does not invalidate credentials it used or stop a remote service from receiving requests elsewhere. Handle those separately. Keep the logs needed for investigation while limiting retention of sensitive inputs and outputs under the organization's applicable obligations.

Coding-agent dependencies can reach beyond a codebase into cloud accounts, communication tools, documents and deployment systems. Each integration therefore needs a source, a permission boundary, evidence for the approved revision and a clear path to removal. Where you cannot verify a property, the review should say what remains unknown.

A one-time installation review can only capture the day it happened. Keep the inventory and change policy current enough to support the next authorization decision.

For more on governing agents after approval, see why an AI agent's own audit trail is not enough and the BlueRadius AI Agent Incident Tracker.

Michael Kantor is President of HOL, an open-source organization working on standards and security tooling for AI agents.