Vulnerability prioritization is not a language problem. The safest agent architectures use models to interpret and explain, while deterministic systems traverse the evidence.

Ask a security team a simple question: Of the vulnerabilities your scanner reported this morning, which ones can actually be exploited in production?

The honest answer is often that nobody knows yet, and proving it can take hours or days. That makes it tempting to point an AI agent at the scanner output and ask for a prioritized list. The agent will respond immediately, in fluent prose, with a confident rationale.

But if the evidence required to determine exploitability is not in the input, the answer is still a guess. Better model quality does not solve missing data.

Exploitability Is a Property of a Path

Exploitability is not simply a property of a vulnerability record. In production, it depends on relationships.

To determine whether a vulnerable library matters, a team may need to establish that the package is a dependency of an artifact; the artifact is included in an image; the image is used to deploy an application; the application runs in an environment that matters; and a relevant code path can reach the vulnerable function.

Those relationships usually live in different systems: registries, build metadata, deployment records, SBOMs, runtime inventories and call graphs.

A model given only scanner output sees none of that. It sees package names, versions, severity scores and perhaps advisory text. It can summarize those inputs, but it cannot reliably infer relationships that were never provided.

That is a dangerous agent failure mode because the output can look exactly like successful analysis.

Build the Graph, Then Reason Over It

The alternative is to stop treating vulnerability prioritization as primarily a language problem.

Model the software supply chain explicitly as a typed graph. Nodes might represent packages, artifacts, builds, images, applications, environments, scans and policy exceptions. Edges capture relationships such as depends on, contains, produced by, deployed as, promoted by and calls.

Most organizations already possess much of this information. The problem is that it is distributed across systems that were never designed to answer a single end-to-end question.

Once those facts are joined, analysis can be implemented as testable code that traverses the graph.

Reachability becomes a computation rather than a judgment call. A vulnerable package may be present in a dependency tree but not reachable by the application. Another vulnerability may sit directly on an executed path in production. Those findings should not receive the same urgency.

The model can still participate in this workflow. It simply should not be asked to invent missing edges. Let deterministic tooling establish the path, then give the model the resulting evidence.

The same graph can support remediation. When a fix is available, the system can identify the target version, find affected consumers, determine which artifacts require rebuilding and generate a proposed upgrade and rollback plan.

Every Conclusion Should Cite Its Evidence

The strongest property of this architecture is inspectability.

When a traversal engine concludes that a vulnerability is reachable, it can return the path that produced the finding: package to artifact, artifact to image, image to application, application to environment, and executed code to the vulnerable symbol.

A reviewer can inspect every hop. If a relationship is incorrect, the team knows which underlying record needs to be fixed.

A model-generated explanation does not automatically provide the same guarantee. An LLM can produce a persuasive justification for a ranking, but unless that explanation is grounded in evidence returned by the analysis system, the prose is not proof of how the conclusion was reached.

That distinction matters when a finding triggers an emergency change, a production exception or an audit response.

A useful architecture test is simple: If the model provider were unavailable, could the system still produce the finding and its supporting evidence? With the same inputs and analysis version, could the result be reproduced?

If yes, the model is helping communicate an analysis. If no, the model may be performing reasoning that belongs in a deterministic tool.

Apply the Same Discipline to Queries

The principle extends to how agents access registries, catalogs and other operational systems.

Letting a model generate a native query directly is convenient for demos, but it gives model output too much expressive power. Inputs influenced by users, artifact metadata or external systems can also influence the generated query.

A safer design is to have the model produce a structured search intent with typed fields: repository scope, name pattern, package type, age threshold and result limit.

A deterministic query builder converts that intent into the platform’s query language while enforcing policy. It can restrict fields, intersect repository scope with the caller’s permissions, cap results, require pagination, remove sensitive fields and expose read-only operations by construction.

The security property is structural, not behavioral. Instead of prompting the model not to issue a destructive operation, the interface makes destructive operations impossible to express.

Use Models for Language; Use Tools for Evidence

None of this argues for removing the language model.

Models are excellent at interpreting vague requests, resolving conversational references, selecting the right analysis workflow and turning structured findings into explanations an on-call engineer can understand quickly.

The design mistake is asking the same component to infer relational facts it has not been given.

Use the model to route. Use the model to narrate. Use deterministic systems to establish the evidence.

The teams that get durable value from AI agents in the software supply chain will not be the ones with the cleverest prompts. They will be the ones that connect registry, build, deployment and runtime data into something traversable, then make every important conclusion show its path.

An agent on top of that foundation can be genuinely useful. An agent on top of raw scanner output is still guessing, no matter how convincing the prose sounds.