Establishing Provenance and Accountability for AI-Authored Code | G360 Technologies

A security team is investigating a defect discovered in production. The affected package has a valid software bill of materials, cryptographically signed build provenance, passing test results, and an approved pull request. The release can be traced back to a specific repository, workflow, and artifact digest.

What the investigation cannot immediately answer is a different question: was the underlying code written by a developer, generated by an AI system, heavily modified by an AI assistant, or produced through some combination of both?

That distinction is becoming increasingly important, yet current software provenance frameworks were not designed to answer it.

The Governance Gap

Enterprise software development is rapidly incorporating AI-generated and AI-assisted code, but the governance mechanisms needed to make that activity visible and auditable remain incomplete.

Recent developments highlight the gap from two directions. On June 10, 2026, the European Commission published its Code of Practice on Transparency of AI-Generated Content while companion Article 50 guidance proposed exempting source code from content-marking requirements. On the same day, OpenSSF published an analysis of the Mini Shai-Hulud supply-chain incident, arguing that build provenance alone cannot demonstrate how source code was created, reviewed, or approved.

Together, these developments point to a growing governance challenge. Organizations can often prove where software came from and how it was released. They often cannot prove whether AI materially contributed to the code itself.

What Existing Standards Cover

Modern software supply-chain frameworks already provide extensive evidence about source revisions, review processes, build systems, and released artifacts.

Frameworks such as SLSA, in-toto, SPDX, CycloneDX, software bills of materials, artifact attestations, and repository review workflows can establish who changed code, which controls ran, who approved a change, and how a release artifact was produced.

The central finding is surprisingly simple: no standardized field exists across SLSA, in-toto, SPDX, or CycloneDX to record that a source-code change was generated or materially modified by AI.

Organizations can create custom metadata to capture that information. The standards themselves do not provide a common way to represent it.

That gap matters because AI involvement extends far beyond fully generated application code. It can include code completion, refactoring, generated tests, generated documentation, infrastructure-as-code, deployment manifests, workflow files, and human-authored code that has been materially altered by an AI system.

The question is no longer whether organizations use AI in software development. The question is whether that involvement can be made visible, attributable, reviewable, and auditable across the software lifecycle.

How the Mechanism Works

The confusion comes from the fact that several different kinds of provenance are often discussed as though they are the same thing.

Most existing standards focus on one of two problems.

Artifact provenance answers: Where did this package come from? It links a released package, binary, or container to a build process, source revision, workflow, and signing identity.

Development-process provenance answers: Who changed the source code, who reviewed it, and what controls were applied before the change was accepted?

AI authorship fits cleanly into neither category.

Artifact provenance can prove that a package came from a particular build process. Development-process provenance can show who reviewed and approved a change. Neither necessarily records whether AI generated, completed, refactored, or materially modified the source code that entered the repository.

Other provenance layers exist as well. Content-provenance frameworks focus on AI-generated media, while model-provenance frameworks describe AI systems themselves. The governance gap around AI-authored code sits elsewhere, at the intersection of development-process provenance and human accountability.

Existing workflows already record source revisions, reviewers, approvals, test results, build provenance, and release evidence. The missing link is AI involvement. That information is captured only when organizations deliberately record it. Once it is absent, later stages of the software supply chain cannot reconstruct it.

Analysis: Why This Matters Now

The opening scenario is no longer hypothetical.

The Mini Shai-Hulud incident exposed a similar failure mode. Attackers published malicious npm packages carrying valid SLSA Build L3 attestations after compromising a legitimate build pipeline. The provenance records were real. The signatures were valid. Yet the attestations could not answer the question that mattered most: should the software be trusted?

The lesson extends beyond that incident. Provenance records can establish where software came from while still leaving important questions unanswered about how source code was created, reviewed, and approved.

That distinction becomes more important as AI systems participate in software development.

At the same time, transparency requirements for AI-generated content are becoming more formalized. Yet source code remains largely outside those content-marking efforts and continues to be governed through software supply-chain controls, repository policies, review workflows, and attestation systems.

The result is an unusual asymmetry. Organizations have increasingly mature ways to verify artifacts, releases, and build processes. They have far less consistency in how they record AI involvement in source-code creation.

Implications for Enterprises

For enterprise software teams, accountability remains human.

Existing repository policies, DCO-based workflows, review processes, and governance frameworks consistently place responsibility on human contributors, reviewers, and approvers rather than on AI systems themselves.

Visibility, however, increasingly becomes an evidence-management problem. Relevant records may exist in coding-agent sessions, commit metadata, pull requests, CI/CD systems, SBOMs, artifact attestations, and release records. No single system provides a complete picture.

Organizations that want visibility into AI-assisted development must define how that information will be captured. Potential evidence includes generating-system information, model versions, task references, code scope, reviewer approvals, test results, approval decisions, and artifact linkage. Many of these fields remain organization-defined rather than standardized.

As software provenance and AI governance converge, auditability depends on maintaining continuity between source creation, review, build, and deployment evidence.

Risks and Open Questions

There is no widely adopted threshold for determining when AI assistance becomes material enough to require disclosure.

There is no common standard for recording AI-generated source code across repositories, build systems, and supply-chain tooling.

Prompt retention creates tradeoffs between auditability and privacy.

Code authorship may become difficult or impossible to reconstruct after substantial human modification.

Existing standards support extensibility, but organization-specific metadata does not automatically create interoperability across tools and platforms.

Source integrity, review controls, artifact provenance, and human accountability are becoming increasingly standardized. AI authorship is not. As AI-generated and AI-assisted code become routine, the gap between what organizations can prove about software and what they can prove about its creation is likely to become more visible, not less.