Code Provenance for AI-Generated Code: Evaluating Origin, Licence and Security Context Evidence

What provenance means for AI-written code

Provenance is often treated as a synonym for logging. For an auditor the two are different. A log says that something happened. A provenance record lets a third party verify where an artefact came from and what controls applied to it, without relying on the word of the team that produced it.

For AI-written code, we suggest five evidence elements. Origin identifies the assistant, the interaction and the context that produced the code. Licence identifies the licence terms that attach to the output. Security context records the conditions in force at that moment, such as the sensitivity of the project and whether credentials or personal data were present in the prompt context. The policy applied records which rules were evaluated. The action taken records whether the output was allowed, redacted, blocked or escalated, with a timestamp and any human approval.

The enterprise problem is that most organisations can reconstruct some of these elements for some code. Few can produce all of them, tied to a single event, in a form that has not been edited since. That gap becomes visible when a regulator or auditor asks where a specific block of code came from and what was checked before it was accepted.

What each tool category can and cannot evidence

Six categories are commonly presented as answers to this question. The table describes what each is structurally able to capture, based on where it sits in the workflow. Individual products vary, so test every claim against the five evidence elements.

• Source control and commit attribution: Records who committed code and when. It sits downstream of generation, so it generally cannot show that an assistant wrote the code, what context was sent, or which policy applied.
• Software composition analysis and licence scanners: Identifies dependencies and licence terms in code that exists. It evaluates artefacts after the fact and does not record the generation event or the security context at that time.
• Assistant admin and telemetry: Shows usage, such as who used the assistant and how often. It typically does not provide per-output licence or policy evidence, and the vendor usually controls the retention and format of the data.
• AI observability: Captures traces and behaviour of AI systems for diagnosis. Observability data is built for engineers, not for tamper-evident audit use, and it observes rather than enforces.
• Governance and GRC platforms: Hold policies, attestations and control mappings. The evidence they hold is usually entered or imported, so it describes intended controls more than what happened on a given interaction.
• Runtime policy enforcement: Sits in the execution path and evaluates policy before output reaches the developer. Evidence is created by the enforcement decision itself, though its depth depends on which fields the tool records.

Capture at generation versus reconstruction after commit

The central architectural choice is when the record is created. Reconstruction starts from the commit, the pull request and whatever logs survive, and infers origin and context backwards. Inference is weak evidence. A developer may have pasted code from several sources, edited it, or squashed history. Review-based controls such as individual file review, CODEOWNERS rules for sensitive files and human review of generated test changes are sound practice, and OWASP recommends them. They are controls, though, not provenance records. They show that a person looked, not what the code's origin or licence context was.

Capture at generation places the evidence step in the path between assistant and developer. Each interaction is evaluated against policy, and the decision is recorded as it is made. The record exists because enforcement occurred, so there is no separate step that teams can skip under delivery pressure.

This approach has costs that a buyer should weigh. Assistants send code context, such as open files, project structure and terminal output, to the model provider's API. Evidence captured at that point therefore touches sensitive material. OWASP advises excluding or redacting credentials, personal data and sensitive source code before recording captured traffic, so the evidence store must not become a second copy of the data you are trying to protect. OWASP also recommends self-hosted or air-gapped tooling for regulated or highly sensitive code, which makes the deployment location, retention and residency of the evidence store part of the evaluation, not an afterthought.

Mapping evidence to frameworks and escalation

Framework mapping is only as good as the evidence underneath it. A mapping to the EU AI Act, NIST or NYDFS is a statement about how recorded events relate to a framework, so ask to see the underlying event record, not just a coverage chart.

Treat the legal timeline as a moving target. The EU AI Act was amended by the AI Omnibus, which the European Commission reported as in force on 27 July 2026. As of October 2026, compliance mappings should cite the current consolidated text and not earlier published dates. Enforcement is also shared between the AI Office, the European Data Protection Supervisor and national competent authorities, so different bodies may ask for evidence.

Escalation deserves its own scrutiny. NIST's agent identity guidance describes organisations defining risk thresholds that trigger human review, with technology components able to route escalation to the correct authority. Applied to coding assistants, this means a policy can hold a high-risk change for approval, and the approval becomes part of the record. OWASP's advice to flag AI-generated changes that add network access, download external resources or run shell commands in build and deploy configuration is a sound candidate for that threshold.

One example of the runtime approach

Trussed is one example of runtime enforcement for coding assistants. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Policy outcomes are allow, redact, block, rate limit or escalate for human approval, and code provenance covers the origin, licence and security context of code. Enforced at runtime, not reviewed after the fact, each decision generates audit-ready evidence that is mapped to NYDFS, the EU AI Act and NIST, among other frameworks.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for more than 18 months, at 99.95% uptime on live production traffic, and generates more than 30 GB of audit evidence per day. This page makes no claim about model provenance or dataset provenance, and Trussed does not trace entire agentic workflows end to end.

Apply the same criteria above to any tool, including this one.