Your SBOM inventories packages, container layers, and transitive dependencies. It does not record which AI coding agent generated Tuesday’s 600-line PR, which model version it used, which MCP servers it called, or what system prompt shaped its output. That is not an edge case — in February 2026, CISA and six G7 partners released dedicated guidance acknowledging that standard SBOM formats were not designed to capture AI system components. Most engineering teams have not registered the gap yet.
What Standard SBOM Formats Were Built to Track
SPDX and CycloneDX solve one problem: what third-party software is in this artifact? They document packages, versions, licenses, and dependency graphs. The model works because traditional software is compositional and relatively static — you write code, build an artifact, and the artifact’s composition is fixed at that point. A scan at build time is a reasonably accurate snapshot of what you are shipping.
AI coding agents break that assumption at every layer. The agent itself is a dependency. So is the model it calls — which may be updated silently by the provider between Monday’s commit and Friday’s deploy. The system prompt that constrains the agent’s behavior is not tracked in any BOM format. Neither are the MCP servers the agent connects to at runtime, the context window contents that shaped a specific output, or the agentic skills invoked during code generation. A standard SPDX document captures none of these. What it produces is a precise inventory of everything except the thing that is actively writing your code.
What the G7 AI SBOM Framework Adds — And Where It Stops
The CISA and G7 AI SBOM guidance defines seven clusters an AI SBOM should document: metadata, models, key performance indicators, infrastructure, security properties, system-level properties, and dataset properties. Model provenance and dataset lineage are categories that legacy tooling ignores entirely. For teams deploying fine-tuned models or open-source model weights, this guidance gives procurement and security teams a meaningful checklist for the first time.
What the framework does not address is the runtime behavior of AI coding agents at the pull request level. As The Register reported in May 2026, the emerging AI-BOM concept goes further: it extends coverage to agentic skills, prompts, MCP server connections, and how AI components interact with each other and with production workflows. Even that expanded model has a structural blind spot. An AI-BOM tells you what tools exist in your environment. It does not tell you which tool generated which pull request, in what context, or with what risk profile attached to that specific change.
Three elements are currently absent from all BOM standards — existing and proposed:
Model version at commit time — not just whether AI coding is enabled, but which model version processed this specific PR, sourced from which API endpoint, and updated when
System prompt or agent configuration hash — a changed prompt is a changed tool; silent prompt drift is invisible without explicit tracking across commits, and attackers target this vector directly
MCP server connections active during the agent session — each connected server is a live data-exfiltration and prompt-injection surface; no existing SBOM scanner audits these connections today
Three Steps to Close the Gap Today
Extend your dependency inventory to include AI tooling explicitly. Log model name, version, provider, and API endpoint for every AI coding tool in active use. Treat silent model version updates as you would any upstream dependency version bump: they require review, not assumption. If you cannot enumerate your AI tools today, start with a shadow AI audit — the same exercise most teams ran for SaaS in 2019.
Add AI provenance metadata to every pull request generated with agent assistance. Capture, at minimum: which agent, which model version, and which MCP servers were active during the session. This data belongs in a machine-readable PR annotation or commit trailer — not reconstructed from memory after an incident. Teams that automate this step find it doubles as a useful debugging signal when an AI-generated commit introduces a regression.
Apply explicit risk scoring to AI-generated commits before merge. Research published in 2026 on SBOM-based vulnerability attack chains shows that cascading supply chain failures are increasingly predictable — but only when components are fully enumerated and their relationships are modeled. AI-generated code introduces a component your SBOM does not enumerate. Score it accordingly at the PR gate, before it reaches main.
Standard SBOM tooling closes the visibility gap on what software you are running. It was not built to close the governance gap on what your AI coding agents are doing inside your PR pipeline. Those are different problems with different tooling requirements, and the distance between them grows each quarter as agentic coding shifts from experiment to default workflow. If your team is merging AI-generated code without provenance tracking and risk scoring at the PR level, re-entry.ai was built for exactly this layer — governance that starts where your SBOM coverage ends and AI-generated code begins.