--- slug: agent-provenance type: pattern summary: "Record which agent, model, harness, instructions, permissions, and human prompt produced an artifact, at creation, so authorship is queryable rather than reconstructed after an incident." created: 2026-06-09 updated: 2026-06-09 related: agent-registry: relation: uses note: "Provenance references the stable agent identities the registry catalogs." agent-trace: relation: uses note: "Provenance is the durable summary that points back into the per-run trace." shadow-agent: relation: prevents note: "An artifact with recorded provenance cannot have come from an agent nobody registered." agent-sprawl: relation: mitigates note: "Provenance turns an uncatalogued population into one you can query by who produced what." delegation-chain: relation: complements note: "Both depend on verifiable agent identity, and provenance records which link in the chain acted." agentic-payments: relation: complements note: "Both depend on binding an action to a verifiable agent identity." approval-policy: relation: supports note: "Approval decisions become auditable when each gated artifact carries its authorship record." agentops: relation: complements note: "Provenance is the authorship slice of the same telemetry AgentOps treats as first-class." architecture-decision-record: relation: complements note: "An ADR records why a decision was made; provenance records what configuration produced the artifact that implements it." --- # Agent Provenance > **Pattern** > > A named solution to a recurring problem. *Record which agent, model, harness, instruction file, permission mode, tool set, and human prompt produced an artifact, captured at the moment of creation while the record is still accurate, so authorship is queryable rather than reconstructed forensically after something breaks.* *Also known as: Agent Attribution, Authorship Provenance* Provenance, from the French *provenir*, "to come from," is the word art dealers and archivists use for an object's documented chain of custody: who made it, who owned it, where it has been. A painting with clean provenance is one you can trust because its origin is recorded, not guessed. The same idea, applied to a commit or a generated file, asks a narrower question: what produced this, exactly? For an artifact a human typed, the answer used to be obvious. For an artifact an agent generated, it's obvious only if someone wrote it down. ## Understand This First - [Agent Registry](agent-registry.md) — the catalog of agent identities that provenance records point at. - [Agent Trace](agent-trace.md) — the per-run record that provenance summarizes and links back to. - [Shadow Agent](shadow-agent.md) — the trap that provenance, recorded at creation, closes. ## Context A team is shipping code that humans and agents co-author. A pull request lands with forty changed files. Some were typed by an engineer, some were generated by a coding agent running in an IDE, some were produced by a background agent triaging a backlog overnight. To the version-control system, they're all just commits with an author line, and that author line says whatever the agent's git config said, which is usually the human whose credentials the agent borrowed. This pattern is operational, and it sits one layer below most of the governance in this section. [Bounded Autonomy](bounded-autonomy.md), [Approval Policy](approval-policy.md), and [Least Privilege](least-privilege.md) all decide what an agent is allowed to do. Provenance records what an agent actually did, and which configuration did it. It applies the moment an agent's output starts mixing with human output in a shared artifact stream, which for most teams is the day they adopt their first coding agent. The pressure to record it is not theoretical. Researchers have shown that agent authorship leaves detectable signatures: a 2026 study fingerprinted five coding agents across more than thirty thousand pull requests and identified which agent produced a PR with 97.2% accuracy, using only features visible in the commit and diff. The traces exist whether a team acknowledges them or not. The choice is between recording them deliberately, where they are accurate, or reconstructing them later, where they are a guess. ## Problem When an artifact can come from a human, an agent, or a blend of both, the question *what produced this?* stops having a free answer. Git's author field lies by default, because the agent runs under a human's identity. The model version, the system prompt, the instruction file, the permission mode, and the prompt that triggered the work are nowhere in the artifact. They lived in a session that has ended. So the questions that matter at the worst possible moment have no answer. *Which model version wrote the function that just caused a production regression?* *Which instruction-file revision told the agent to skip the validation step?* *Was this database migration human-reviewed or agent-approved?* *Did a contractor's agent, running with the wrong permissions, touch this file?* Each is answerable in principle from the session that produced the artifact. None is answerable from the artifact itself, and the session is gone. ## Forces - **Record at creation versus reconstruct after.** Provenance captured when the artifact is produced is accurate and cheap. Provenance reconstructed after an incident is a forensic project, and fingerprinting gets you the agent but not the prompt, the instruction version, or the human in the loop. - **Completeness versus noise.** A full record names model, harness, instructions, permissions, tools, memory, and prompt. But a provenance stamp on every line of every file is unreadable. The record has to be complete enough to answer the questions and sparse enough that nobody drowns in it. - **Attribution versus blame.** Teams resist provenance when it reads as a system for assigning fault to whoever ran the agent. The record is most useful, and most adopted, when it is framed as debugging and audit infrastructure, not a disciplinary trail. - **Honest authorship versus tidy history.** Recording that an agent wrote something makes the history messier and the human's contribution look smaller. The temptation is to let the agent commit as the human and keep the log clean. That tidiness is exactly the information provenance exists to preserve. - **Verifiable versus self-reported.** An agent can claim any identity in a metadata field. Provenance that matters binds to a credential the runtime actually presents, so the record can be trusted by someone who didn't generate it. ## Solution **Stamp each artifact with its full authorship record at the point of creation, bound to a verifiable agent identity, and make the record queryable.** Treat provenance as metadata the production pipeline emits automatically, not as something a well-meaning engineer remembers to add. Capture enough to answer the questions an incident responder or auditor asks first: - **Agent identity.** Which agent produced this, referenced against the [Agent Registry](agent-registry.md) rather than a free-text name. - **Model and version.** The exact model and build, because "an AI wrote it" and "this specific model version wrote it" are different facts when you're chasing a regression. - **Harness and scaffold.** The framework the agent ran inside, which shapes its behavior as much as the model does. - **Instruction context.** The instruction file or system prompt revision in force, so a behavior change traces to a configuration change. - **Permission mode and tools.** What the agent was allowed to do and which tools it had, which tells you whether an action was sanctioned. - **Human prompt and reviewer.** The request that triggered the work, and the human who approved the result, if any. The cross-cutting rule is *record where it is true*. The only place all of this is accurate and complete is the running session, so the production harness emits the record, not a later analysis pass. Bind the record to identity: a self-reported model field is a courtesy, but a provenance entry tied to a credential the agent's runtime presents is evidence. Surface the record where the questions get asked, which usually means the commit trailer, the PR metadata, and a queryable store, so "which model wrote this?" is a query, not an excavation. ```mermaid flowchart LR H[Human prompt] --> A[Agent run] R[Registry identity] --> A M[Model + harness] --> A I[Instruction revision] --> A A --> X[Artifact: commit / PR / file] A --> P[Provenance record] P -. references .-> X ``` Provenance is not the same as a trace. The [Agent Trace](agent-trace.md) is the full mechanical record of one run, every tool call and intermediate step. Provenance is the durable summary attached to the artifact that points back into that trace. The trace answers *how did this run unfold?*; provenance answers *what produced this thing in front of me?* Keep them distinct, because the trace is voluminous and session-scoped, while provenance is small and travels with the artifact. ## How It Plays Out A regression ships on a Thursday. A search endpoint starts returning stale results, and the bisect lands on a commit from three weeks ago. The author line names a senior engineer, but the commit trailer carries a provenance record: the change came from a coding agent running a model version that was rolled back days later for exactly this class of off-by-one error, under an instruction file revision that had since been corrected. What would have been an afternoon of confused git-blame becomes a five-minute lookup. The fix is already known, because the failure is already attributed to a configuration the team had stopped using. A platform team runs a security review after a contractor's engagement ends. They need to know what the contractor's agent touched and whether it ran with the right permissions. Without provenance, this is an unanswerable question dressed up as an audit. With it, they query the provenance store for every artifact bound to that contractor's registered agent identity, see the permission mode each ran under, and find two files the agent modified with broader scope than policy allowed. The records don't assign blame so much as bound the investigation: the team knows exactly what to re-review, and exactly what they can leave alone. A company adopts a disclosure policy for AI-generated code, and the engineers hate it, because the first version asks them to manually tag their agent-authored changes. Compliance is spotty and the tags are unreliable, which is worse than nothing because it implies the untagged changes are human when some are not. The team rebuilds the policy around the harness: the agent's runtime emits the provenance trailer automatically on every commit it makes, bound to its registry identity, with no engineer in the loop. Disclosure stops being a chore and becomes a property of the pipeline. The lesson repeats one from the registry: a record that depends on human diligence at creation time loses to the path of least resistance, so the production system has to emit it. > **💡 Tip** > > Before designing a provenance schema, run the fire drill. Pick a real artifact an agent produced last week and try to answer, from the artifact alone, which model version, which instruction revision, and which human prompt produced it. The questions you cannot answer are exactly the fields your provenance record needs. The ones you can answer from git already are fields you can skip. ## Consequences **Benefits.** Authorship becomes a fact instead of an inference. Debugging gains a new axis: a regression traces not just to a commit but to the model and instruction version that produced it, so a bad configuration is found and rolled back as a unit. Audits and compliance reviews answer "what did this agent produce, under what permissions?" with a query rather than a forensic reconstruction. Security incident response scopes faster, because every artifact an agent touched is bound to its identity. Trust compounds: a co-authored history that is honest about which contributions were agent-generated is one teammates and downstream consumers can actually rely on. **Liabilities.** Every artifact now carries a provenance tail, and the production pipeline has to emit it without friction or it will not be emitted at all. The record is only as trustworthy as the identity it binds to, so provenance without [Agent Registry](agent-registry.md) entries and verifiable credentials degrades into self-reported metadata an attacker can forge. There is a real privacy and culture cost: a record of exactly which human prompted which agent can be read as surveillance, and a team that frames it that way will route around it. And provenance records accumulate, so they need the same retention and storage discipline as any other operational data, including a policy for when an old artifact's full authorship record can age out. **Failure modes to name.** - *Provenance as honor system.* Engineers are asked to tag agent-authored work by hand. Compliance is partial, which makes the untagged remainder a lie of omission. The fix is to move emission into the harness. - *Provenance without identity.* The record names a model and an agent in free text, bound to nothing the runtime presents. An auditor can read it but cannot trust it. The fix is a verifiable credential tied to a registry entry. - *Provenance as blame ledger.* The record is introduced as a way to find who to fault when an agent breaks something. Teams hide their agents from it, and it goes the way of the [Shadow Agent](shadow-agent.md) it was meant to prevent. The fix is framing and scope: debugging and audit, not discipline. - *Provenance sprawl.* Every line of every file gets stamped, the records dwarf the artifacts, and nobody reads any of them. The fix is granularity: record at the artifact level the questions are actually asked at, usually the commit or PR, not the token. ## Sources The strongest empirical argument for recording provenance is that agent authorship is already detectable. The 2026 study [*Fingerprinting AI Coding Agents on GitHub*](https://arxiv.org/abs/2601.17406) trained classifiers on more than thirty thousand pull requests from five coding agents and identified the producing agent with 97.2% accuracy from commit and diff features alone. Authorship signatures exist whether or not a team records them, so they are better recorded deliberately, where they are accurate. The companion [*AIDev*](https://arxiv.org/abs/2602.09185) corpus assembled a large dataset of agent-authored pull requests that grounds the broader study of how agent and human contributions differ in practice. The identity primitives provenance binds to come from the surrounding governance work. The agent-card schema and identity-bound entries described in this section's [Agent Registry](agent-registry.md) supply the stable references a provenance record points at, and W3C [*Verifiable Credentials*](https://www.w3.org/TR/vc-data-model-2.0/) supply the trust primitive that lets a provenance entry be checked by someone who did not produce it. The practice of recording machine-readable decision records (the Agent Decision Record idea now circulating in the practitioner community, a descendant of the [Architecture Decision Record](architecture-decision-record.md)) is the decision-level sibling of artifact-level provenance: one records why a choice was made, the other records what configuration produced the result. Treating authorship metadata as load-bearing audit infrastructure, rather than incidental commit decoration, follows a broader move toward treating agent activity as first-class telemetry. That is the same impulse behind [AgentOps](agentops.md) and the supply-chain provenance work (SLSA, in-toto), which established the principle that an artifact should carry a verifiable record of how it was built. ## Further Reading - [*Fingerprinting AI Coding Agents on GitHub*](https://arxiv.org/abs/2601.17406) — the fingerprinting study; read it for the concrete evidence that agent authorship is detectable from commit features even when undocumented. - [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) — the standard for credentials a provenance record can bind to so the authorship claim is verifiable. - [SLSA: Supply-chain Levels for Software Artifacts](https://slsa.dev/) — the build-provenance framework whose "an artifact should carry a verifiable record of how it was produced" principle generalizes cleanly to agent authorship. --- - [Next: Approval Fatigue](approval-fatigue.md) - [Previous: Agent Registry](agent-registry.md)