The risk that's new, not just faster
Pulling in the wrong open-source package isn't a new problem — supply chain security has been dealing with malicious and vulnerable dependencies for years. What's new is the speed and the missing checkpoint: an AI coding agent can propose, and a developer can accept, a new dependency in the time it used to take to write one function by hand — often without the pause where someone used to ask "do we actually trust this package."
Why static SBOMs aren't enough anymore
A Software Bill of Materials generated once at build time was already a snapshot going stale the moment a new dependency got added afterward. When new dependencies can be introduced by an agent mid-session, at whatever pace a developer accepts its suggestions, a point-in-time SBOM is describing a system that's already changed. The shift underway is toward living, continuously updated SBOMs integrated with real-time vulnerability intelligence — not a compliance document generated for an audit and forgotten.
A static SBOM process is like printing a map of a city where the roads change every day. It's accurate for the moment it's generated and increasingly wrong after that — which is a much bigger problem when the rate of change went up because an agent, not a human, is proposing new routes.
Treating agents as first-class, audited actors
- Non-human identity. The emerging practice — sometimes called MLSecOps, applying DevSecOps discipline to AI-assisted development — is assigning every AI agent its own tracked identity, the same way a service account gets one, rather than letting its actions blend anonymously into a human developer's activity log.
- Auditing what it pulls in. Every package or dependency an agent introduces gets logged and checked against policy — license, known vulnerabilities, maintenance status — the same gate a human's dependency addition would go through, not a lighter one.
- Model and weight provenance. If the AI models themselves are part of your product, they need documentation too — training data lineage, architecture decisions, safety benchmarks — tracked like any other dependency, because a model is one.
- Collapsing detection-to-fix time. The goal isn't to slow agents down with manual gates on every action — it's automated policy checks that catch a problem in minutes instead of a manual audit catching it weeks later, with a human approving the fix rather than rubber-stamping the check.
What this looks like in practice
| Old model | Emerging model |
|---|---|
| SBOM generated at release, treated as a compliance artifact | Continuously updated inventory integrated with live vulnerability feeds |
| Dependency additions reviewed when a human remembers to check | Every addition — human or agent-proposed — checked against policy automatically |
| AI agent activity blended into general developer logs | AI agents given tracked, auditable non-human identities |
| "What's in our software" answered by searching old documents | A queryable, immutable system of evidence answering it on demand |
Why this matters even for teams not selling security software
This isn't a concern reserved for defense contractors or regulated industries. Any team using AI coding assistants — which by 2026 is most teams — has already changed how dependencies enter their codebase, whether or not their supply-chain practices have caught up. The gap between "we use AI coding tools" and "we track what they introduce" is exactly the gap this trend is closing, and it's cheaper to close proactively than after an incident forces the question.
Know what's actually in your software
We build living SBOM practices and dependency governance that account for AI-assisted development, not just human commits.
Frequently asked questions
Do we need an SBOM if we're not selling to the government?
Increasingly, yes in practice — customers, insurers, and partners are starting to ask for one as standard due diligence, and having an accurate one is useful for your own incident response regardless of who's asking.
Can we just review every AI-suggested dependency manually?
At low volume, sure. Most teams using AI coding tools quickly exceed the volume a manual gate can realistically sustain, which is exactly why automated policy checks — not removing the human, but removing the human as the only checkpoint — become necessary.
What is SLSA and how does it relate to this?
SLSA (Supply-chain Levels for Software Artifacts) is a framework for verifying the integrity of the build process itself — where an artifact came from and how it was built — complementary to an SBOM, which documents what's in the artifact rather than how it got assembled.
Is this only about open-source packages?
No — the same tracked-provenance thinking extends to AI models and their weights if they're part of your product, and to any third-party API or service your system depends on. The common thread is treating every dependency as something you can answer questions about, not just something that works.