🧾 Traceability: Who (or What) Wrote This Line of Code? (7/10)

When AI agents write, review, and ship code, “who wrote this” is the wrong question. The right one is what produced this, under what authority, with what evidence.

Article 7 of 10 — AI Governance in an AI-Native Software Development Company

There is a question your audit logs are about to start failing.

“Who wrote this?” 😳

For two decades, the answer has been a person. A commit signature, a PR author, a reviewer. The provenance question collapsed neatly into an identity question, and identity systems were good enough to carry the weight.

That answer is now wrong by default.

When an agent opens the PR, another agent reviews it, a third agent deploys it, and the human in the loop only approved the category of change rather than the change itself, “who wrote this” stops being a useful question.

The useful question becomes:

*“What produced this, from what inputs, under what policy, on whose authority, at what time?”*

That is not an authorship question. It is a provenance question. And the systems that answer authorship cleanly answer provenance badly.

*In an AI-native pipeline, identity is not authorship. Authorship is a chain.*

The first six articles in this series built controls that act in real time. 🔗 Article 1 (🏛️ You Think You Have AI Governance. You Don’t.) separated governance from safety. The articles that followed turned the 🔗 human-agent relationship into a contract, made policy executable, enforced it at runtime, and 🔗 contained the blast when enforcement was not enough. Every one of those layers works forward, in the moment, deciding what should happen and stopping what should not.

Provenance is different. It operates after the fact.

It is the first governance control whose primary job is reconstruction rather than prevention. Everything before it tried to stop the wrong action, enforce the right one, or contain the fallout when neither held. Provenance does not try to change what happens. It exists to explain what actually did.

It is the layer that makes the previous six provable. A policy you enforced but cannot reconstruct is a claim. A blast you contained but cannot trace is an anecdote. Containment answers *“can we stop it?”* Provenance answers *“can we prove what happened?”* Without that proof, every control before it is something you believe, not something you can demonstrate.

🔗 Article 6 (🛑 AI Governance Fails Without Containment) was about containing the blast when the agent acts. This article is about reconstructing, after the fact, exactly what happened and why, and the audit backbone that makes that reconstruction possible.

🧱 The Authorship Question Is Now a Provenance Question

The old model was simple.

A human committed. The commit had a signed identity. The identity mapped to a person. The person could be asked what they were thinking.

The new model has more actors and looser causation.

A human gave an agent an intent. The agent pulled context from multiple sources, called a model, generated a change, ran some checks, possibly looped, and produced an artifact. Another agent reviewed the artifact against a policy bundle. A third agent promoted it. A fourth agent monitored the rollout and decided not to roll it back.

Every step is recoverable. None of them are recoverable by accident.

The audit question that matters now is not who.

It is:

• What intent triggered the work?
• What context did the agent operate on?
• What model and version produced the output?
• What prompt and skill were active?
• What tools did it call, with what arguments?
• What policy bundle evaluated the result?
• What evidence was emitted at each gate?
• What human authorized which step, and under what scope?
• What downstream effect did the change produce?

That is the provenance chain. It is not nine separate logs. It is one chain that has to hold together end to end, or it does not hold together at all.

A provenance chain with a missing link is not “mostly complete.” It is broken. The missing link is exactly where the contested incident will land.

🔗 The Chain of Custody for Agent Work

The shape of the chain is straightforward once you draw it.

🔗 The Chain of Custody for Agent Work

intent ──► context ──► model/prompt/skill ──► action ──► policy verdict ──► change artifact ──► deployment ──► runtime effect ──► evidence

Every arrow is a place the chain can break.

The disciplines that hold it together are familiar from distributed systems, applied to a new substrate.

• Stable correlation IDs. One ID per intent, propagated through every system that touches the work. If the ID is dropped at any boundary, the chain is broken there.
• Pinned versions at every step. Model version, prompt hash, skill version, tool schema version, policy bundle digest. “Latest” is not an audit answer.
• Inputs hashes, not inputs themselves. You usually cannot store everything the agent read. You can store cryptographic fingerprints of it, plus pointers to the source. Reproducibility comes from being able to ask was this the input? with certainty.
• Signed attestations at every gate. Each evaluator that touched the work emits a signed record: who I am, what I evaluated, what verdict I reached, against what policy version. Unsigned attestations are storytelling.
• Append-only evidence. Provenance records do not get edited. They get superseded, with both versions retained. Mutable audit logs are not audit logs.

These controls buy three properties: reproducibility, non-repudiation, and tamper evidence.

This is not glamorous infrastructure. It is the equivalent of structured logging for a system whose actors are no longer purely human. The same engineering instincts apply. The same shortcuts produce the same regrets.

*⚠️ An audit trail you cannot replay is a narrative, not a trail.*

✍️ AI Authorship Attribution as a First-Class Field

A lot of teams quietly treat “the AI wrote some of it” as a vibe rather than a fact.

That is fine until legal asks. Or compliance asks. Or a customer asks. Or a regulator asks.

The honest answer is multi-valued, and the system has to be capable of expressing it:

• Fully agent-authored, with human approval at the boundary
• Agent-drafted, human-edited, with the diff between draft and final preserved
• Human-authored with agent assistance, where the agent contributed suggestions but not the final text
• Agent-authored from a human specification, where the spec is human-authored and the implementation is not
• Fully human-authored, with no agent involvement

These are not philosophical distinctions. They have different implications for IP, for licensing, for warranty, for compliance with whatever sector-specific rules apply to your domain. A system that cannot distinguish them is a system that will eventually answer the question wrong.

The practical demand is small: an authorship field that is structured, signed, and produced by the system that did the work, not by a human checking a box after the fact.

The signed part matters. Self-reported authorship is what creates the audit gap, because the actor with the most incentive to misreport is the same actor producing the report.

This is also where reuse of governing standards from earlier in the program pays off. If your metadata layer already requires owner, version, and provenance fields on every artifact, the authorship field is one more discipline in a familiar pattern, not a new fight.

🧬 Signed Releases, Signed Behavior

For code, signed releases are a known practice. The artifact is built, hashed, signed, and that signature follows the artifact through the pipeline. At any point downstream, you can ask “is this the thing we built?” and get a deterministic answer.

That discipline has to extend to behavior.

What needs signing in an AI-native system:

• Skills. The skill artifact, with metadata, contract, and tests, signed at publish time.
• Rules. The rule bundle, with version and scope, signed at distribution.
• Prompts. The active prompt, by hash. A prompt change is a behavior change.
• Tool manifests. Declared, signed, scope-bound. The set of callable tools is a security boundary.
• Policy bundles. The signed set of policies pinned at the evaluator, as Article 4 described.
• Model pins. The exact model and version in use, with the responsibility for upgrades sitting in the change-management pipeline rather than at the model provider’s discretion.

⚠️ If any of these can change without a signature, the provenance chain has a gap there.

The most common failure is the prompt. The prompt file is editable, the change is silent, the runtime picks it up, and the “what produced this” answer now points to a prompt that no longer exists. The fix is structurally identical to signing a binary: pin by hash, sign at publish, refuse to load anything unsigned.

Software supply chain security already solved a version of this problem for code. You cannot trust an artifact you cannot trace to its source, so the industry learned to sign releases, attest dependencies, and keep a bill of materials that records what actually went into the thing it shipped.

AI-native systems now have a second supply chain. The dependencies are not libraries. They are models, prompts, skills, tool manifests, rules, and policy bundles, and each one shapes behavior the way a linked library shapes a binary. Each one can move under you, and when it does, the output moves with it.

AI Agents — 🧬 Signed Releases, Signed Behavior

What teams increasingly need is the behavior equivalent of that bill of materials: a record of the exact models, prompts, skills, rules, and policies that produced a given output, captured at the moment it was produced. This is not a checklist bolted on at the end. It is the same provenance discipline, applied to the dependencies that decide how an agent behaves.

The point of this is not security. It is traceability. Governance cannot govern an outcome it cannot trace back to the thing that produced it, and a behavior surface that changes without a signature is an outcome with no traceable source. Provenance is the mechanism that provides that traceability, the link that keeps every output joinable to the cause that shaped it.

*If the behavior surface can mutate without a signature, the audit chain ends there.*

🔬 Evidence at the Boundary of Every Change

🔗 Article 4 (⚙️ The Executable Policy Layer: Why AI Governance Dies Before Runtime) made the case for evidence at every gate. This article is about evidence at the boundaries between gates, which is where most provenance chains actually break.

Boundaries are where one system hands work to another. They are also where context gets dropped, IDs get re-issued, versions get unmoored, and signatures get stripped because the next system did not know how to verify them.

For each boundary in the chain, a useful question:

• does the upstream emit the evidence the downstream needs?
• does the downstream verify it?
• does the boundary preserve the correlation ID?
• does the boundary preserve the policy version under which the upstream acted?
• if the boundary crosses a trust line, into an external tool, a model provider, a third-party API, is the policy context carried in a form the other side can verify?

That last one is the thread 🔗 Article 4 left dangling. Provenance is the place where it stops being abstract.

When the boundary is internal, you can usually fix this by tightening contracts between services. When the boundary is external, you have to design for the possibility that the other side will not preserve your evidence, will re-issue IDs, will silently retry, or will return responses that cannot be tied back to the specific request.

The discipline is the same in both cases. Treat the boundary as a place where evidence has to be re-established by the side that owns governance, not assumed to propagate.

👁️ Traceability Without Surveillance

A worry that always shows up at this point: *“are we building a surveillance system for our engineers?”*

It is a fair question, and the answer is no, if the design is deliberate.

Provenance for governance is not the same as keystroke logging. The chain you need does not require recording what an individual engineer typed at 2:47pm. It requires recording:

• the intent that triggered an agent action
• the artifacts and policies that shaped it
• the verdicts the system produced
• the changes that landed and the effects they had

The actor in that chain is more often “agent X under policy Y under intent Z” than “person P.” Where humans are involved, the relevant fact is the authorization boundary they crossed, not the keystrokes they used to cross it.

Two design principles keep the system on the right side of this line:

• Minimum sufficient evidence. Capture what you need to reconstruct decisions, not everything that could possibly be captured. More is not better. More is harder to defend and easier to misuse.
• Bounded retention. Provenance records have a retention policy, just like any other sensitive data. Indefinite retention is not a virtue.

The teams that get this right end up with audit systems their own engineers trust. The teams that overreach end up with audit systems their engineers route around, which is the worst of both outcomes.

*Provenance is for reconstruction, not observation.*

🧪 What Good Actually Looks Like

A real traceability layer is recognizable.

You know it is working when:

• any change in production can be traced back to the intent that produced it
• the model version, prompt hash, skill version, and policy bundle for any agent action are recoverable
• authorship is a structured, signed field, not a vibe
• the chain holds across internal service boundaries and is explicitly re-established across external ones
• evidence is append-only, signed, and pinned by digest
• the team can answer “what changed about this agent’s behavior in the last 30 days” with specifics
• the audit story is the same story the engineers already trust

And you know it is missing when:

• “who wrote this” produces a person’s name that does not match the actual chain of work
• prompt changes happen without a hash being recorded
• model upgrades land without a version pin moving in the audit log
• the system has logs but no chain
• legal asks once a quarter and gets a slightly different answer each time

That last one is the diagnostic.

*If the same question produces different answers depending on who you ask, you do not have provenance 🫤. You have stories.*

🚨 Failure Modes When the Chain Is Broken

The failures are repetitive.

ID amnesia. The correlation ID is generated, then dropped at the second system. Everything downstream is logged, but nothing downstream can be joined.

Version vapor. The system records that a change happened, but not the version of the model, prompt, or policy that produced it. Reconstruction is theoretical.

Mutable prompts. The prompt that produced the artifact has since been edited. The artifact is signed; the input is not. The chain ends at the artifact.

Authorship by default. Every change is attributed to whichever human approved it, regardless of how much of the change the agent produced. The legal exposure is silent.

External silence. The chain runs cleanly inside the org and stops at the first external tool. The action that mattered happened in the silence.

Audit by screenshot. The provenance evidence is reconstructed from human memory, chat history, and screenshots. It is partial, contestable, and biased toward the version the reconstructor prefers.

🚨 Failure Modes When the Chain Is Broken

The pattern underneath all of them is the same.

The chain was assumed to assemble itself from logs.

It did not.

⚙️ Provenance Is an Engineering Problem Now

Traditional audit was largely a compliance activity. Someone asked for records, and engineering produced them after the fact, usually by exporting logs and writing a narrative around them. The work was retrospective, and it mostly lived somewhere other than the pipeline.

AI-native systems break that model for a structural reason. The evidence a provenance chain needs does not exist unless it was emitted at the moment of action. You cannot reconstruct a model version, a prompt hash, or a correlation ID that nobody captured. There is no log to export, because the fact was never recorded.

That moves provenance out of compliance and into engineering. Correlation IDs, signatures, input hashes, signed attestations, append-only evidence, and replayability are not policy preferences. They are build-time decisions, made in code, by the people who build the pipeline.

The good news is that the primitives are familiar. Correlation IDs are tracing. Signed attestations are signed releases. Append-only evidence is an event log. Hashed inputs are content addressing. Treat provenance the way you already treat distributed tracing, structured logging, and reproducible builds: as a property you design in, not a report you assemble later.

*Provenance you did not design into the system does not exist.*

🛠️ Practical Build Order

Provenance is a long-running discipline. You will not retrofit it perfectly. You can establish a credible chain in a quarter if you sequence it.

1. Define the chain you actually need. Not the maximalist chain. The chain that answers the questions your business will be asked. Legal, compliance, customer, regulatory. Start from the questions and work backward.

2. Pick one high-value flow and instrument it end to end. Usually the agent-authored PR-and-deploy flow. It already has artifact discipline. Extend the chain from intent to runtime effect.

3. Establish correlation IDs as a first-class contract. Generated at the intent, propagated everywhere, verified at every boundary. Treat ID drops as defects, not curiosities.

4. Pin and sign behavior surfaces. Prompts by hash. Skills by version. Models by pin. Policy bundles by digest. If it shapes behavior, it gets signed.

5. Add structured authorship to artifacts. A signed authorship field with multi-valued semantics. Produced by the system, not the human. Required at publish time.

6. Make boundaries explicit. Internal boundaries get contracts. External boundaries get re-established evidence, and explicit acknowledgment of where the chain depends on a third party.

7. Test the chain by asking real questions. Pick a recent change. Ask “what produced this, on whose authority, under what policy.” If the answer takes more than a few minutes to assemble, the chain is not yet load-bearing.

That order is not glamorous.

It produces an audit backbone that can survive a real question from a serious party. Which is what governance has to do.

Closing

Audit used to be a paperwork problem.

In an AI-native pipeline, audit is an engineering capability.

It is not a document you produce under a deadline. It is a property you build into the pipeline, the same way you built tracing, signing, and reproducible builds. You do not write a chain of custody after the fact. You instrument for it before the first agent ships.

The chain of custody for a change is no longer a person-to-person chain. It is an intent-to-effect chain that runs through agents, prompts, models, skills, policies, gates, and runtimes, and the chain is only as strong as its weakest boundary.

The teams that get this right stop asking “who wrote this” and start asking “what produced this, under what authority, with what evidence.”

The first question is nostalgic. The second one is the one the next decade of audits is going to require.

*An AI-native system without provenance is not auditable. It is narratable.*

Provenance tells you what happened. It cannot tell you about a change the pipeline never saw. The model upgraded behind a stable name, the prompt edited in place, the skill that grew a tool over a weekend, none of those reach the chain unless capability change is itself a governed event. The audit backbone only records the changes the system was built to notice.

Successful governance was never about having the most policies. It is about being able to prove what happened when those policies met production. The org with the longest rulebook and no chain is not governed. It is hopeful. The one that can reconstruct any change, on demand, from intent to effect, is the one that earned the word.

*Next in the series: The Agent Change-Management Playbook. Once provenance exists, agent capability upgrades can be handled as production changes, with a registry, canary rollout, communication and rollback rather than silent capability drift.*

Originally published by Reza Arani on Medium on June 4, 2026. Adapted for Aipolix as Part 7 of the AI Governance in an AI-Native Software Development Company series.

Sources

• Original article by Reza Arani on Medium