TL;DR
Agentic AI is now embedded in most enterprise software, largely invisibly, and orchestrating compliance workflows on top of it does not fix what the underlying detection never saw. Most compliance failures trace back to incomplete SBOMs and manifest-only detection, not a lack of automation. Structural, code-level analysis is what makes automation trustworthy, particularly where AI-generated code is concerned.
How much of today’s software is already agent-written, and who’s watching it?
Gartner forecasts that 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025. McKinsey’s 2025 State of AI survey finds 88% of organisations already using AI in at least one business function, though only 23% are scaling agentic AI anywhere in the enterprise. Put together, this is an invisible hand: coding and workflow agents are moving from a small minority of applications to nearly half within a year, while structural visibility into what that code actually contains lags years behind.
Why doesn’t automation fix open source compliance on its own?
A separate category of agent is now being pitched as the answer to this exact gap: a compliance agent that orchestrates SBOM parsing, licence evaluation, and report generation automatically. But an agent is only as good as what it’s reading. It does not generate insight of its own, it inherits the accuracy of the detection data underneath it, and that data is typically incomplete, since licence obligations depend on how software is actually used, linked, modified, or distributed, not merely which component is nominally declared. A compliance agent can encode a policy rule perfectly and still act on a false premise if the component identification feeding it is wrong, including identification of what coding agents upstream have already written into the codebase. Automating a workflow on top of an incomplete inventory does not close that gap. It moves through it faster, with less human friction left to catch the error. The agent is not the differentiator here. The data is.
What does AI-generated code hide, and why is it scattered across so many blind spots?
Coding agents introduce a second, harder layer beyond undeclared dependencies: reused logic that isn’t copied verbatim at all. Generation tools produce code influenced by existing patterns, structures, and algorithms, not text pulled wholesale from a source. That surfaces as rewritten implementations of licensed code, cross-language transformations of the same algorithm, and logic carried over from training data with no declaration anywhere in the build.
The harder problem is that none of this is copied cleanly. Undeclared reuse, doesn’t show up as a clean match against a known file, because the code has been rewritten, partially reproduced, or reassembled from fragments. A textual or manifest-based check either matches a whole known component or it doesn’t; against partial, modified, or incomplete reuse, it simply returns nothing, and the risk becomes invisible.
Snippet and structural-level detection is what changes this. Because it matches at the level of fragments rather than whole-file text, it can still identify a component even when only part of it is present or the surrounding code has been altered.
Why does snippet-level detection go further than manifests?
Manifest-based checks are effective for declared, unmodified dependencies, but they say nothing about code that was copied, adapted, or generated without ever being declared. Snippet-level detection works from the code itself: it fingerprints fragments and matches them against a knowledge base, which means it can surface reuse even when a file has been modified or only partially reproduced, well beyond what a manifest was ever built to see. This was a recurring theme at the SCANOSS workshop in Athens, where practitioners operating at scale converged on the same observation from different directions: automation efforts hit the same wall regardless of pipeline design, and that wall is the quality of the underlying detection. A compliance agent depends on tools and datasets to extract anything meaningful from the code itself; it cannot substitute for them.
What does it look like in practice?
One global enterprise now checks AI-generated code at the point a coding agent writes it, before it ever reaches a repository or a review queue. A lightweight interception step catches the write, matches it against a knowledge base at the code level, and either allows it or flags it for review, with the decision and the evidence archived alongside it. No pilot, no separate platform: the check sits wherever the organisation’s developers already work.
The detail that matters here is what “sits wherever developers already work” means in practice. Reliable automation depends on accurate component identification and continuously updated licence and vulnerability data first, and an orchestration layer second — and that detection layer has to reach the code however it gets written, whether that’s a coding agent writing directly into a pipeline or a developer working through an interface with no pipeline involved at all. A compliance agent can only coordinate what the detection underneath it can actually see, regardless of where the code originated.
For compliance and engineering leaders exploring how to govern AI-assisted development with confidence, the starting point isn’t more automation. It’s structural visibility into what’s actually in the code, wherever it’s written. Read the full success case to see how this runs at 16,000-developer scale, or contact us to talk through what it would look like in your environment.
