A procurement lead at a fintech slides a contract over. "Before we wire the integration, prove what's actually inside your agent." You open the terminal. pip freeze returns 217 packages. Half of them are transitive, none declare a license, and one of them was yanked from PyPI in 2026. The agent itself sits on top of a fine-tuned model whose training data nobody can name — and whose weights hash nobody recorded.
That pause — the moment "trust me" stops working — is exactly why we built EVIDIQ Lineage. It's the deterministic supply-chain risk engine that turns "we used some stuff" into a signed AI supply chain SBOM your counterparty can actually re-run, byte for byte.
Why an Agent Needs an SBOM, Not Just a Dependency List
An AI supply chain SBOM is a machine-readable, signed inventory of every dependency, model, and data flow behind an autonomous agent — the same way a CycloneDX SBOM names every library in a build. EVIDIQ Lineage produces, signs, and anchors that artifact on 0G Storage so any counterparty can re-verify what your agent is actually running.
Here's the thing: a package.json or a requirements.txt is not provenance. It's a wish list. It tells you what someone intended to install on a Tuesday afternoon, not what shipped on Friday. And an agent is more than code — it's a model, a system prompt, a tool surface, retrieval data, and a runtime. None of that lives in a lockfile.
What you actually need is a CycloneDX SBOM for the code layer, a CycloneDX-AI (or SPDX-AI) AI supply chain SBOM for the model and data layer, and an audit trail that says "these exact bytes went out the door." That's the gap EVIDIQ Sentinel closes during the build, and that's what Lineage freezes into tamper-evident evidence your buyer can re-verify.
Concretely, the difference between a lockfile and a real SBOM looks like this:
package.jsonsays"lodash": "^4.17.20"— a range, not a pin.- A real SBOM says
lodash@4.17.21 / resolved sha512:… / license: MIT / purl: pkg:npm/lodash@4.17.21. - A real AI supply chain SBOM says and
gpt-4-turbo-2026-04-09 / weights: sha256:… / training-cutoff: 2026-12 / system-prompt-hash: …. - It also names the retrieval index, the embedding model, and every MCP tool the agent can reach.
If your agent can't produce that on demand, it's not production-grade. It's a demo.
The 14-Rule Risk Engine
We didn't want a vibes-based linter. So Lineage ships a deterministic, 14-rule engine behind scan_dependencies. Every rule has a fixed weight, and every run produces the same score from the same inputs. No randomness, no LLM-in-the-loop, no "we'll figure it out in v2." The verdict is auditable to the byte — and reproducible on any machine.
The fourteen rules, in the order they fire:
- Pinning integrity — fail if any direct dep is unpinned or uses a floating range like
^or~. - Lockfile presence — fail if there's no lockfile or it doesn't match the manifest hash.
- Deprecated packages — score penalty scaled by how long the package has been deprecated.
- Yanked packages — hard fail; this is the worst signal in npm, PyPI, crates, and Maven Central.
- Known-vulnerability posture — live OSV.dev match against current advisories for the pinned version.
- License compatibility — flags GPL/AGPL/LGPL in permissive projects, custom "BUSL" clauses, unknown SPDX expressions.
- License declared-vs-shipped — if the manifest says MIT but the tarball says Apache-2.0, that's a red flag.
- Typosquat / lookalike names — distance-1 and distance-2 checks on resolved package names.
- Maintainer count — single-maintainer packages carry more risk than multi-maintainer ones.
- Install-script execution — flags deps with preinstall/postinstall hooks that reach the network or shell out.
- Native build flags — flags packages that compile against system libs pulled at install time.
- Transitive depth — counts how deep your tree goes and weights depth vs surface area.
- Provenance attestation — checks for Sigstore/cosign signatures or npm provenance attestations.
- Drift since last scan — fail if your lockfile drifted from the artifact you actually deployed.
The output of scan_dependencies is a single JSON object: a per-rule pass/fail, a numeric score 0–100, and a top-three "remediation" list. Paste it into a CI gate, a procurement form, or a EVIDIQ Operator policy and the same input always gives the same output. That's the property regulators keep asking for, and it's the property most "AI risk" dashboards don't actually have.
From SBOM to AI-BOM
Code is half the story. An agent that calls a fine-tuned model is shipping a second dependency graph: weights, tokenizer, system prompt, retrieval corpus, tools, MCP servers. That's why we split Lineage into two paired generators — generate_sbom and generate_aibom — plus two auditing tools that act on the results.
The pipeline looks like this:
generate_sbom— emits a CycloneDX 1.6 JSON or SPDX 2.3 tag-value file for the code dependency graph. Includes purl, hashes, supplier, and download location per component.generate_aibom— emits a CycloneDX-AI document for the agent layer. The "components" here are models (with hashes of the weights file you actually loaded), datasets (with hashes of any snapshots used for retrieval or fine-tuning), prompts (with hashes), and the MCP/tool surface the agent exposes.audit_licenses— takes either SBOM and runs a license-policy pass: compatible, incompatible, copyleft-trigger, unknown. Output is a per-component verdict plus a project-level rollup you can ship to legal.verify_package_claim— live cross-check. For every component in the SBOM, we resolve the published package, hit the OSV.dev advisory API, and confirm there are no open advisories for the pinned version. We also re-fetch the artifact's digest and compare it to what the SBOM claims.
The live OSV check is the part most teams skip, and it's the part that bites you in production. A package can be clean on Monday and have a CVE by Wednesday. Our verifier runs on every scan and fails the score the moment a new advisory lands. Pair that with audit_licenses and a single dependency bump in your Cargo.toml can drop your supply-chain score by twenty points — which is exactly the signal a procurement reviewer needs before wiring funds through your agent.
If you're already running an agent in production, generate both documents, run both audits, and ship the bundle. Don't regenerate it by hand when someone asks — let the tool do it, every time, deterministically.
A Supply-Chain Report You Can Re-Verify
A report that says "trust me, we scanned it" is not a report. It's a press release. So every Lineage report is built to be re-verified by anyone with a copy of EVIDIQ Notary docs and the report hash.
The flow:
- The
scan_dependenciesoutput is canonicalized (sorted, deduped, hashed). - The keccak256 of the canonical report is anchored to 0G Storage mainnet with an on-chain transaction.
- The report itself is signed with the EVIDIQ signing key using EIP-191.
- Two read-only tools,
verify_lineage_reportandget_artifact, let a counterparty re-fetch the evidence, re-hash it, and recover the signer.
That means a buyer doesn't need to call you and ask "is this real?" They pull the report hash, look up the tx on 0G, recover the signer, and verify the signature locally. The verdict is reproducible — same inputs, same score, same conclusion — which is the property regulators and procurement teams keep asking for, and which most "AI risk" vendors quietly can't deliver.
For agent-to-agent flows, this matters even more. When one agent hands off a task to another, the receiving agent can ask for a Lineage report the same way it asks for a trust score via verify_agent. The two compose cleanly: the trust score says "this agent is who it claims," and Lineage says "this agent is built on what it claims." That's the difference between trusting an identity and trusting a build.