Your AI writes the code. Who attests to it?

For twenty years, “software supply chain security” meant vouching for the things your software was made of — the open-source packages, the build system, the signed artifact at the end. Then generative AI walked into the pipeline and started doing something new: it began writing and changing the code itself. The supply chain grew a link that none of the existing tooling was built to attest — the AI agent — and it grew it faster than the market could respond.

You don't have to take that framing from a vendor. KuppingerCole's 2026 Leadership Compass on Software Supply Chain Security reaches the same conclusion from the analyst side: code signing and attestation are the most underserved capabilities relative to how important they've become, AI-generated code is a new supply-chain risk “most vendors are only beginning to address,” and agentic AI — treating an AI agent as an identity with its own risk profile and audit trail — is the emerging frontier. In their words, attestation is the market's most critical gap. This is our read on why, and what closing it actually requires.

What the supply chain used to be

The classic chain is well mapped, and the tools that guard it are mature:

Source → Dependencies → Build → Artifact → Deploy

Software composition analysis (SCA) tells you which open-source components you pulled in and which carry known vulnerabilities. An SBOM records that inventory in a portable format. A package firewall blocks a malicious or typosquatted dependency before it reaches your registry. Build provenance and code signing let a consumer verify that the artifact they run is the one you actually built. Frameworks — SLSA, NIST SP 800-218, the EU Cyber Resilience Act, in-toto — turn what was informal practice into things you have to be able to prove. That whole stack answers one question: can I trust the ingredients and the kitchen?

The link the frameworks didn't anticipate

None of that machinery was designed for a supply chain where a non-human actor sits upstream of the source code, generating and editing it in real time. When an AI coding agent writes a function, adds a dependency, or runs a shell command, it introduces a provenance question the SBOM can't answer, because it happens before there is an artifact to attest:

Which agent made this change — and under whose identity and permissions?
What did it read to make it — a poisoned rules file, an untrusted web page, a prompt-injected document?
Which tools did it call and which destinations did it reach on the way?
Was that dependency it just added a real package, or a plausible hallucinated one an attacker has already registered?

An AI agent is, in effect, a non-human digital actor operating inside your build pipeline with a developer's access. SCA can tell you the dependency it added is malicious after it's in the tree. It cannot tell you the agent added it because a comment in a README told it to. That's not a dependency problem; it's an attestation problem — and it lives on the developer's machine, at the moment of the action, where no network scanner or registry proxy can see it.

Why AI-authored code breaks the old proof

Attestation has always meant a verifiable statement of who did what: this identity built this artifact from these inputs. AI-authored code doesn't remove that requirement — it moves it earlier and multiplies it. The interesting actor is no longer just the CI runner that produced the binary; it's the agent that wrote the change, the identity it acted under, and the chain of tool calls it made to get there. A signed artifact at the end of the pipeline tells you the build wasn't tampered with. It tells you nothing about whether the agent that authored the code was following your developer's intent or an attacker's injected instruction.

So the provenance record has to extend one link to the left:

Identity → Agent → Source → Dependencies → Build → Artifact

— and the agent link is exactly the one the market says almost no one attests yet. The platforms are racing to add it; most are doing so from the network or the registry, after the fact. The action itself happens in-process, on an endpoint, and often never touches the network at all.

The catch every framework leaves open: you have to store it

Here's the tension that keeps attestation on the “underserved” list. The frameworks want more evidence; every security team is already drowning in log-ingestion and retention costs. And AI evidence is the worst kind to keep, because the natural way to record what an agent did is to record its prompts, its file contents, and its tool arguments — high-volume, and full of exactly the sensitive data (source code, secrets, customer records) you least want sitting in a SIEM for years. The evidence requirement and the economics collide precisely on the content. So teams do the rational thing under budget pressure: they log less. And when the incident lands, the attestation isn't there.

Attestation you can afford — content-free

MoorAI resolves that collision by attesting the agent's actions and dropping the content. It runs on the developer's machine as a pre-execution hook inside the coding agent and a gateway in front of its tool servers. Before each tool call runs, it records a governance statement — which agent, under whose identity, which tool, which data class, what decision, what risk — plus a tenant-keyed one-way hash, and never the prompt, the output, the arguments, or the file path.

That record is built to be evidence, not just a log:

Signed & chained. Each record carries a per-record keyed authenticity hash and a keyless prev-hash chain link, so a deleted, reordered, or edited record breaks the chain and is detectable — the tamper-evidence attestation depends on.
Streamed as the durable copy. The chain streams off the device as OpenTelemetry — the same OTLP envelope your SIEM already ingests — and exports as a STIX 2.1 bundle for threat-intel interchange. The copy in your pipeline becomes the immutable record.
Mapped to the controls. The same content-free signals map to EU AI Act / NIST AI RMF / ISO 42001, so the compliance artifact is the enforcement record — and it contains no one's prompt.
Canaries, not content. Honeytokens let you plant a decoy value; if an agent ever touches it, that's a high-signal alert — and only its one-way hash is ever stored.

Because the payload is a hash, not a prompt, this is attestation a cost-pressured SOC can actually afford to keep: a fraction of the volume, none of the sensitive content, no data-residency problem. The rest of the field ships you the prompts. MoorAI ships you the proof.

the line that matters

The software supply chain grew a new link — the AI agent that writes your code — and the market's own analysts say attestation is the gap. MoorAI is the content-free attestation layer for that link: a signed, tamper-evident, on-device record of what each agent did, under whose identity, to which data — cheap enough to keep, and open source (AGPL-3.0), so “the content never leaves” is something you verify by reading the code.

On-device is the other half of the gap

There's a second weakness the analysts flag across this market: deployment. The SSCS leaders are overwhelmingly SaaS-only, and on-prem or air-gapped options are thin. But an AI coding agent's most sensitive actions — a local Bash command, a Read of a secrets file, a stdio MCP call to the local filesystem or database — generate no network traffic at all. A cloud inspection tier or a registry proxy never sees them. Attesting the agent link therefore has to happen where the action happens: on the device, in-process, whether or not anything ever crosses the wire. On-device isn't a deployment preference here; it's the only place the evidence exists.

Where MoorAI fits — next to the platforms, not against them

This is not a claim that MoorAI replaces an SCA platform or an SBOM tool. It doesn't scan your dependency tree, generate a CycloneDX SBOM, or run a package firewall — Sonatype, Veracode, Snyk, Socket, Endor, and Cycode do those things well, and you should run one. What none of them attests is the agent link: the non-human actor now sitting upstream of your source, making changes in-process on a laptop. MoorAI attests that link content-free and hands the signed evidence to the same SIEM and the same compliance program the rest of your supply-chain stack feeds. Two controls at two points in one chain — the platforms vouch for the ingredients, MoorAI vouches for the agent that reached for them.

Identity → Agent → Source → Deps → Build → Artifact → Attested, end to end

The old supply-chain question was “can I trust the ingredients?” The one the last two years added is “can I trust the actor that assembled them?” You can answer it the expensive way — capture every prompt and pay to store and protect it — or the content-free way. MoorAI is the second.

MoorAI is content-free, open-core (AGPL-3.0) security for AI agents — the attestation layer that runs on the developer's endpoint, not in a cloud that reads your prompts.

Sources

KuppingerCole, Leadership Compass: Software Supply Chain Security (2026) — market analysis; attestation and AI-code provenance named as the leading gaps.
SLSA & in-toto — supply-chain provenance and attestation frameworks.
NIST SP 800-218 (SSDF) and the EU Cyber Resilience Act.
OWASP Top 10 for Agentic Applications (2026).