Most teams running coding agents cannot answer the only question a regulator, an auditor, or an angry customer will actually ask: which agent changed this, under whose authority, and what did it see when it decided?
They can answer it for humans. Git blame, a pull request, a reviewer's name. The moment an agent writes the code, the chain thins out to a commit authored by a token and a session that no longer exists.
This is a governance problem before it is a compliance problem, and it becomes expensive in that order.
Kill the default approach: treating agent logs as debugging output
The default is to log what the agent did so you can debug it when it goes wrong. Prompt in, tokens out, maybe the tool calls. That log is written for the engineer who is already looking, and it is discarded on a retention policy set by whoever configured the log drain.
It fails as evidence for three reasons.
It is not addressable. You cannot go from a line in main to the agent run that produced it, because nothing joins them. The commit knows nothing about the session and the session knows nothing about the commit.
It is not complete. Debug logs record the failure path well and the success path barely. Ninety-nine runs that worked leave less trace than the one that crashed, and it is the ninety-nine you will be asked about.
It does not survive. Retention is set for cost, not for obligation, and the window that matters is set by someone else.
What the obligation actually says
If you deploy a high-risk AI system in the EU, Article 26(6) of the AI Act requires you to keep the logs the system automatically generates, for at least six months, where those logs are under your control. Article 50's transparency obligations apply from 2 August 2026. (The Act itself entered into force in 2024; its obligations become applicable on staggered dates, and conflating the two is the most common error in writing about it.)
Two things worth being precise about, because most writing on this is not.
Most coding agents are not high-risk systems. The high-risk classification is about deployment context — the Annex III list, and safety components of regulated products — not about whether a model wrote the code. An agent refactoring your marketing site is not in scope. An agent writing code inside a medical device, a hiring pipeline, or credit scoring plausibly is, and the same agent stack serves both.
Verify this against the text before you act on it. I am an engineer, not your lawyer, and the classification question is exactly where a generic answer is worthless. What follows is the engineering that makes the answer cheap to produce, whichever way it goes.
The useful framing is not "am I obliged to". It is: if you were obliged to, could you? For most teams the honest answer is no, and it would take a quarter to change. That gap is the risk, not the regulation.
The record that answers the question
A traceability layer that works has four properties. None of them are exotic; the difficulty is that they have to be decided before the run, not after.
Addressable. Every artifact an agent produces carries the identifier of the run that produced it. In practice that means the run id reaches the commit trailer, so git log is the index into your agent history and you do not need a second system to join them.
Complete by construction. The record is written by the harness, not by the agent. An agent that can choose whether to log is an agent whose log is a claim rather than a record — and the run you most want is the one where its judgement was wrong.
Bounded in authority. The record states what the agent was permitted to do, not only what it did. "Wrote to src/" means nothing without "was allowed to write to src/ and nowhere else". Authority at the time of the run is the part reconstructed least reliably after the fact, because the config has moved on.
Durable past the tooling. Six months is longer than most teams keep a vendor. If the record only exists inside a product's dashboard, the obligation is now that vendor's uptime and pricing. Plain files in your own repository outlive the tool that wrote them.
What this looks like in a repository
Concretely, on a change an agent made:
- a run record with an id, a start and end, the model and version, and the authority boundary in force
- the commit trailer carrying that run id
- the gates that ran, their results, and whether any were skipped and by whom
- the human decision point, if there was one, and who made it
That is enough to answer the opening question in one command. It is also, not coincidentally, enough to answer the internal version — the one that arrives long before any regulator, when a change lands that nobody remembers approving and the reviewer has left.
The order to build it in
Do the addressability first. Run id into the commit trailer is an afternoon, and it is the piece everything else hangs off — without it the other three records exist but cannot be found from the thing you are looking at.
Do authority second, because it is the one that degrades. A record written today can be reconstructed from yesterday's logs; the boundary that was in force six weeks ago cannot be reconstructed from a config file that has changed nine times since.
Completeness and durability follow from where you put the writer. If the harness writes and the files live in the repository, you get both without deciding anything further.
What this does not solve
It does not make an agent's decisions good. It makes them reviewable, which is a different property and the only one you can engineer directly.
It does not establish whether you are in scope. That is a legal determination about what your software does, and the engineering above is worth doing at the point where you would rather not have to find out under time pressure.
And it does not survive an agent with write access to its own record. If the thing being audited can edit the audit, you have a log, not evidence. Keep the writer outside the agent's boundary — which is the same rule as every other audit trail, and the one most often broken here because the agent is so convenient a place to put it.
