AI agents can take over repetitive supply chain work such as triaging findings, matching advisories to your inventory and drafting dependency updates. They cannot replace the controls that decide what is trusted: provenance, signing, policy gates and a human who approves risky changes.
What is supply chain work an agent is good at?
Most of the daily load is sorting. A mid-size company can have thousands of open findings across hundreds of repositories, and nearly all of them are noise for any single service. Agents suit three kinds of task:
- Matching. Reading a new advisory and checking it against your component inventory.
- Context. Asking whether the vulnerable function is actually called, which is the question reachability analysis answers.
- Drafting. Preparing a version bump, running the tests and writing the pull request description.
Prioritization data helps an agent do this well. The CISA Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation, and EPSS publishes a daily 0 to 1 probability that a CVE will be exploited in the next 30 days. Feed both in, and the agent's queue is ordered by evidence, not by severity score alone.
Where should an agent not decide alone?
Anywhere the cost of a wrong call is high or hard to undo. Merging to a release branch, widening a production permission, disabling a gate and publishing a package all belong behind a human.
The reason is structural. An agent reads untrusted text all day: issue comments, package descriptions, changelogs. OWASP's Top 10 for Agentic Applications for 2026 exists because agents that plan and act across workflows create risks that ordinary applications do not. Treat an agent as a junior engineer with fast hands and no instinct for being fooled.
What stays deterministic?
The trust decisions. SLSA describes build levels by what they protect against: Build L1 means provenance exists, L2 means signed provenance from a hosted build platform, L3 means a hardened build platform. Checking that an artifact's provenance matches expectations is a rule, not a judgment, and should run the same way every time whether an agent is involved or not.
The NIST Secure Software Development Framework is similarly outcome-based. It tells you what to achieve, and leaves the means to you. An agent can help produce the evidence; it should not be the only thing standing between a build and production.
What does a sensible setup look like?
Constructed example: a platform team lets an agent open pull requests that bump vulnerable dependencies, but only for packages with a published fix and only when reachability shows the flaw is called. The agent cannot merge. A policy gate requires passing tests, a clean provenance check and one human approval for any major version change. Patch-level bumps for non-reachable findings are batched weekly.
The agent speeds up the boring 80 percent. The gates make sure that speed cannot turn into an incident.
What goes wrong when teams automate too fast?
The common failure is trusting the agent's summary instead of the evidence behind it. An agent says a finding is not reachable, the team closes it, and nobody checks the call graph. Another is giving the agent broad repository write access on day one because the pilot went well on a small project.
A slower start pays off. Run the agent beside your current process for a month and compare its triage against what your engineers decided. Count disagreements and read each one. If the agent is wrong in a pattern, you learn where to add a rule or a human check. If it is right, you have the data to widen its permissions with confidence.
What to do
- List the supply chain tasks your team repeats weekly and mark each as matching, context or drafting.
- Start agents on read-only tasks first: triage and summaries.
- Allow agent-authored pull requests only after a human review rule and policy gates are in place.
- Keep provenance and signature checks as fixed rules outside the agent.
- Give the agent its own identity with minimal scope, and log every tool call.
- Measure outcomes: time to fix reachable flaws, share of agent pull requests merged unchanged, and reverts.
Safeguard offers reachability analysis, autonomous remediation with fix pull requests that are off by default, policies and gates, and an MCP Guardrail for agents that call tools.
Quick check
Should agents be allowed to merge their own fixes?
Not without a gate. A common pattern is agent opens, tests and policy check, human approves. Loosen it only for low-risk change classes after you have review data.
Does an agent replace an SBOM or provenance?
No. Those are evidence an agent can read and produce, not something it can substitute for.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- SLSA specification v1.0: levels and tracks
- NIST SP 800-218, Secure Software Development Framework
- OWASP Top 10 for Agentic Applications for 2026
Last reviewed: 18 October 2026.
