Evidence for Auditors: Logging, Oversight, Documentation

Evidence for Auditors: Logging, Oversight, Documentation is the chapter that converts everything already built into something a third party can check. The controls in Chapters 4 through 11 all produce records as a side effect, and the work here is to collect them deliberately rather than to invent a compliance programme alongside the engineering.

Key takeaways

• Three artifacts answer almost every question asked: a log that reconstructs what the agent did and why, an oversight mechanism with a working stop control, and documentation that matches the running system.
• A log that the agent could edit is not evidence. Write it to a store the agent's identity cannot modify, append-only, with integrity that can be demonstrated rather than asserted.
• A stop control that halts the orchestrator while subagents keep running is not a stop. Test it under load, on a schedule, and measure how long it takes to be complete.
• Documentation is generated from the repository or it is fiction within a quarter. The authority records, tool inventories and runtime bills of materials from earlier chapters are the inputs.
• The EU AI Act's implementation timeline puts most of the Act into application on 2 August 2026, except Article 6(1). This is a date, not legal advice, and for teams in scope it moves the deadline outside the organisation.

Read this alongside every earlier chapter, since each one produces one of these inputs. Chapter 5's authority records, Chapter 6's decision logs, Chapter 8's egress logs, Chapter 9's memory provenance and Chapter 11's runtime inventory are the raw material, and none of them was built for this purpose.

Someone from outside asks a question that sounds simple. Show me every action this agent took on this account last month, what it was responding to, and who approved the two that moved money.

The team has logs. They have application logs with request identifiers, model call logs with token counts, and a trace viewer that retains a week.

Answering takes eleven days. It produces a spreadsheet with gaps in it, which is a worse outcome than the answer being no.

Three artifacts, and they are not new work

The vocabulary around AI governance makes this sound like a separate discipline. It is three artifacts. Each is a byproduct of controls already argued for.

The record is a log that lets somebody reconstruct what the agent did, in what order, on whose behalf, under what authority, and on the basis of what information. The oversight mechanism is the ability for a person to observe, intervene and stop, with the stop actually working. The documentation is a description of what the system is permitted to do and who decided, matching the deployed reality.

Every one of those has an engineering justification independent of any regulation. The record is what makes an incident investigable, which is the difference between a postmortem and a story. The stop control is what turns a compromise into a contained event. The documentation is what a security review asks for before it approves anything.

So the framing to adopt internally is not compliance. It is that these are the artifacts you already wanted, and one of them now has a date attached for some teams.

What the log has to answer

Designing a log by listing fields produces a log that answers no questions. Design it backwards. Start from the questions that get asked.

Four questions cover most of it. What did this agent do, in order, with timestamps and outcomes. Why did it do each thing, meaning what request it was serving, which retrieved content informed it and which prior step it followed. Under what authority, meaning the identity from Chapter 5, the delegated user context, the policy decision from Chapter 6 and any approval. And what did it see, meaning references to the inputs, since without those a sequence of actions has no explanation.

That last one is where implementations usually stop short, and it is the one an investigation needs most. Log references to inputs rather than the inputs themselves, meaning content hashes and pointers into a separately governed store, which keeps sensitive material out of a log that is widely readable while preserving the ability to reconstruct.

Two records deserve special handling. Denied and failed attempts, because the pattern of what an agent tried and was refused is a better detection surface than the record of what it was allowed to do. And the runtime inventory reference from Chapter 11, so the question of what version did this becomes answerable.

OWASP's excessive agency guidance names logging alongside rate limiting as a mitigation pair, and pairing them is deliberate. A log tells you it happened, and a rate limit decides how many times.

Tamper-evident, and outside the agent's reach

An agent that can edit the record of what it did has turned your evidence into its account of itself. Most implementations get this wrong. It is straightforward to get right.

Three requirements do most of the work. The log store is append-only, so entries cannot be modified or deleted through the normal write path. The agent's own identity has no write access beyond appending, and specifically no delete or update permission, which is Chapter 5's scoping applied to the one store people forget to scope. And integrity is demonstrable, meaning entries are chained or signed such that a removed or altered record is detectable rather than merely unlikely.

OWASP's vector and embedding entry recommends immutable logs of what was written to a store, and the same reasoning extends to the action log. The value of a log during an incident is proportional to your confidence that it is complete, and completeness you cannot demonstrate is completeness you will end up arguing about.

Retention is the fourth requirement. It usually gets set by accident. A seven-day default is a trace-debugging retention, and an investigation that begins with a question about last quarter needs considerably more. Set it deliberately, per class of record, and be aware that a long retention on a log containing sensitive material is its own liability, which is the argument for logging references rather than contents.

The stop control that actually stops

Every team says they can turn the agent off. The claim survives contact with reality far less often than teams expect. The gap is usually structural.

A stop control has to do four things to deserve the name. Halt work in progress, not just refuse new requests, because a long-running task holds credentials and will complete its current action otherwise. Reach every agent in a chain, which after Chapter 10 means subagents and delegated work rather than only the orchestrator. Revoke the credential rather than trusting the process to exit, since Chapter 5's short lifetimes are what make this fast. And be operable by whoever is on call at three in the morning, without a deployment, without a code change, and without the person who built it.

Two additional properties separate a real control from a documented one. It is tested on a schedule, under load, in production, with the time to complete stoppage measured and recorded, because an untested stop control is a belief. And it degrades gracefully, so stopping the agent leaves the product usable in a reduced form rather than taking a customer-facing surface down, since a stop that causes an outage is a stop nobody will pull.

The scope of the control matters too. Being able to stop one agent identity without stopping the others is the payoff for the identity work in Chapter 5, and it is what makes the decision to stop cheap enough to take early.

Human oversight beyond the approval queue

Chapter 6 covered approval for individual high-impact actions. Oversight is the broader capability, and it needs three things the approval queue does not provide.

Visibility into what the agent is doing now, meaning a view of active tasks with enough context to judge them, rather than a log to be read afterwards. Review of a sample of completed work, chosen at random rather than by exception, because reviewing only what was flagged tells you nothing about what was not flagged. And a route for the person doing that review to change the system, which usually means an owner, a standing agenda item and the authority to move the autonomy dial from Chapter 1 downward without a project.

The sampled review is the part most often skipped and the one that finds the interesting failures. Reviewing exceptions finds the cases your detection already catches. Reviewing a random sample finds the class of failure that produces no exception at all, which is where a confidently wrong agent lives.

Record the oversight itself. Who reviewed what, when, what they found, and what changed as a result. That record is both the evidence that oversight exists and the only way to tell whether it is working.

Documentation generated from the repository

Hand-written documentation of what a system does is accurate on the day it is written. Within a quarter it describes a system that no longer exists, and it is worse than nothing, because it produces confidence without accuracy.

Generate it instead, from sources the earlier chapters already require. The authority record per agent from Chapter 5 gives identity, permitted actions, data scope and the approving name. The tool inventory from Chapter 4 gives the capability surface with each tool's class. The policy configuration from Chapter 6 gives the enforced rules. The runtime bill of materials from Chapter 11 gives model versions, prompts, servers and skills. The trust boundary map from Chapter 2 gives the architecture, and it is the one piece that stays hand-drawn, which is acceptable if it is dated and reviewed.

Then add the two narrative sections that cannot be generated and that reviewers always want. What the system is for and what it is not for, which is a scope statement. And what could go wrong and what stops it, which is the threat model, and which is largely a summary of this book applied to your architecture.

The test of whether the generated documentation is real is simple. Change a tool's permissions and see whether the document changes without anybody editing it. If it does not, you have a document rather than a mechanism.

The evidence checklist

The following table is the compact form of everything above, and it is the artifact worth copying into a design review.

Two columns matter more than the others in practice. The generated-from column, because an artifact with no source is a document somebody will have to write under pressure. And the fails-when column, because every entry there is a real failure mode rather than a hypothetical one.

The dates, stated as dates

This section states published dates and nothing more. It is not legal advice, this book does not offer any, and whether a given system falls in scope is a question for people qualified to answer it.

The EU AI Act's implementation timeline records the following. Prohibitions and AI literacy obligations applied from 2 February 2025. Obligations for general-purpose AI models, along with governance provisions and penalties, applied from 2 August 2025. The remainder of the Act starts to apply on 2 August 2026, with the exception of Article 6(1), and Member States must have at least one operational regulatory sandbox by that date. Article 6(1) applies from 2 August 2027, and providers of high-risk systems intended for use by public authorities have until 2 August 2030.

The engineering consequence is narrow and worth stating plainly. For systems in scope, the kinds of artifact a review will ask about are records, human oversight and documentation, which are the three things this chapter describes. None of them can be produced retroactively with any credibility, because a log that was not being written was not being written.

That is the whole reason this chapter exists at the end of the book rather than as an appendix. The evidence is a design output of Chapters 4 through 11, and a team that built those controls has most of it already.

The objection: we are not in scope

For many teams that is correct today, and the conclusion people draw from it is the mistake.

The artifacts have a second buyer, and that buyer arrives sooner. Enterprise procurement asks these questions now, in security questionnaires, and the answers decide whether a deal proceeds. So does an insurer, so does a customer's own auditor, and so does the internal review that stands between an agent and production credentials.

There is a cheaper argument still. Every artifact here pays for itself during the first incident. The action log is the difference between an eleven-day reconstruction and an afternoon. The stop control is the difference between contained and reported. The documentation is the difference between knowing what the agent could reach and guessing.

The scope question is also less stable than it looks. Systems acquire scope by growing into new markets, new customer segments and new use cases, and the retrofit is expensive precisely because logs cannot be backfilled. Building the evidence path while the system is small is an afternoon per artifact. Building it later is a project with an unmovable external date on it.

Chapter summary

Three artifacts answer almost every question a reviewer, auditor or incident asks: a record that reconstructs what the agent did and why, an oversight mechanism with a stop control that works, and documentation matching the running system, and all three are byproducts of controls the earlier chapters already required. Design the log backwards from four questions covering what it did, why, under what authority and what it saw, logging references and content hashes rather than raw inputs so sensitive material stays in a governed store, and recording denied attempts as well as successful ones because refusals are the better detection surface. The log must be append-only, outside the agent's write scope beyond appending, and integrity-checkable so that alteration is detectable, with retention set deliberately per record class rather than inherited from a tracing default. A stop control earns the name only when it halts work in progress, reaches every subagent in a chain, revokes credentials rather than trusting a process to exit, is operable by whoever is on call without a deployment, degrades without taking the product down, and is drilled in production with the time to complete stoppage measured. Oversight beyond the approval queue needs live visibility, review of a random sample rather than only exceptions, and a named person with the authority to reduce autonomy. Documentation should be generated from the authority records, tool inventory, policy configuration and runtime bill of materials, with only the scope statement, the threat model and the boundary map written by hand and dated. And the EU AI Act's implementation timeline puts the remainder of the Act into application on 2 August 2026 except Article 6(1), which for teams in scope turns all of this from good practice into artifacts somebody asks to see.

That is the book. Its argument in one line: an agent is a principal rather than a feature, prevention of injection is not available, so security comes from where the boundary is drawn, which means one identity per agent, a tool surface whose worst case is acceptable, authorization enforced at the destination, isolation matched to unreviewed code, egress denied by default, memory that cannot authorise anything, delegation that narrows, a supply chain you can name, and evidence produced as a side effect rather than assembled under deadline. The measure of whether it worked is not that no injection ever landed. It is that when one did, it produced a log line and a contained event rather than a phone call from a customer.