A background agent acts when no person is present to see it. Every incidental assurance mechanism an organisation relies on — a colleague noticing, a screen someone glances at, a session that ends when a human logs off — is absent by design. What closes that gap is not more supervision. It is a record specific enough that any single action can be reconstructed months later by somebody who was not there.
The test to run against your logs today. Take one agent action from four months ago and establish what triggered it, which identity performed it, which tools it called with which parameters, what changed as a result, and whether a human decided anything. If that takes longer than a few minutes, what you have is telemetry, not an audit trail.
Plain-English explainer · ISO/IEC 42001:2023 · 2017 TSC with revised 2022 points of focus · OWASP GenAI LLM Top 10, 2026 edition · Last reviewed August 2026
An agent action is investigable when the record answers six questions without anybody having to remember anything: what triggered it, which identity performed it and under whose authority, what it called and with what parameters, what it touched, what changed and whether the change succeeded, and whether a human was involved. Prompt-and-output logging answers almost none of those. Tool-call history answers most of them, which is why the tool-call record — not the transcript — is the load-bearing evidence. That distinction decides almost everything else on this page: what you capture, what you alert on, how long you keep it, how much of it a privacy officer can live with, and whether an assessor can test the control at all. It also decides what you have to do with agent identity, because a record that cannot be attributed to a distinct principal cannot be joined to anything downstream. What follows is the field list, a monitoring model that does not require reading employees’ prompts, the alerts that earn their noise, the retention arithmetic, and the evidence an assessor actually asks for.
Key Takeaways
- Tool calls are the load-bearing record, not prompts and completions. A transcript shows what the model said, while the tool-call history with parameters, targets and outcomes shows what the organisation actually did — and only the second can be tested.
- Twelve fields make an action investigable: the triggering event, the agent identity, the delegating principal, the model and version, the tool called and its source, the parameters, the resource touched, the action and outcome, errors and retries, human intervention, the terminal workflow status, and a correlation identifier that survives into downstream systems.
- Reading transcripts is the most privacy-invasive and least generalisable form of monitoring. Usage patterns, permission denials, retry storms, spend curves and downstream reconciliation produce better governance evidence at a fraction of the intrusion, and can be reviewed by people not entitled to read the content.
- Five alerts do most of the work: failed actions on write paths, escalating retries, permission denials, anomalous spend or volume, and activity outside the approved window. Everything after that is tuning.
- Retention has two floors and a ceiling. Deployers of high-risk systems under the EU AI Act keep automatically generated logs for at least six months under Article 26(6). An assessor asks about a whole observation or certification period plus the lag. And data minimisation pushes the other way on anything containing personal data. Split the event skeleton from the payload so you are not forced to choose.
- A distinct agent identity pays for itself at correlation time. If the agent’s writes land in the system of record under a shared service account, the agent log and the system log cannot be joined and the investigation stops at the boundary.
What disappears when nobody is present
It is worth being precise about what actually changes when work moves from a person to a background agent, because the answer is not that the work becomes riskier in the abstract. It is that five specific assurance mechanisms stop operating, and four of them were never written down as controls in the first place.
| The witness disappears | Most of what passes for control in an office is incidental observation — a colleague sees the screen, a manager notices the volume of emails going out, somebody asks why a payment run looks odd. An agent working at 02:00 has no observer at all, and no amount of policy restores one. The record has to do the work the room used to do. |
| The session ends, the authority does not | Human access is bounded by the working day and by logging off. An agent holds a credential continuously and can act the moment a trigger arrives, which means the window in which an unnoticed action can occur is the whole calendar rather than office hours. Anything that relies on someone being around has quietly stopped being a control. |
| The pace changes by two orders of magnitude | A person performs a handful of consequential actions an hour. An agent can perform more than seventy tool calls in nine minutes, and a loop can perform four thousand. Detection latency that was acceptable for human error — a weekly review, a monthly reconciliation — is now measured against a blast radius that grows while nobody is looking. |
| Hesitation is not available | A person who is unsure stops and asks. An agent that is unsure retries with different parameters, and each retry is a real action against a real system. The behaviour that most reliably precedes a bad outcome is therefore not silence but repetition, and it is invisible unless every attempt is logged separately from the one that eventually succeeded. |
| Every question is asked afterwards | Nobody investigates an agent in real time. The questions arrive weeks later, from a customer, an internal reviewer, an assessor or a regulator, and they are always retrospective and always specific. That is why the design problem is a record problem: the record is the only thing that will still exist when the questions arrive. |
None of that is an argument against background agents. It is an argument that the record has to be better than the record you kept for the human process, because the record is now carrying weight that was previously carried by presence. That is also the shape of the answer when a board asks what changed: not new categories of risk, but the removal of the informal detection that used to catch the old ones.
Prompts and outputs answer the wrong question
Most organisations that log AI activity at all log the conversation: the prompt in, the completion out. It is the obvious thing to capture, it is what the vendor consoles show, and it is nearly useless as an accountability record. The reason is simple. A completion is a proposal. A tool call is an act. The gap between them is where every interesting failure lives.
An agent can state that it has updated a record and not update it. It can update a record without saying so. It can say it will send one message and send eleven. It can succeed at the task it described and simultaneously write to a resource nobody expected it to touch. A transcript cannot distinguish any of those cases from a clean run, because the transcript is the model’s account of events and the model is not the authoritative narrator of its own effects. The tool-call history is.
The transcript is also the worst artefact to retain at volume. It is large, it frequently contains personal data belonging to employees and customers alike, it attracts employment and privacy obligations the moment it is read routinely, and it cannot be handed to the people who would most usefully review it. Every property you want from an evidence store — small, attributable, structured, low in sensitivity, safe to keep for a year — belongs to the tool-call record and not to the conversation.
There is a standards-shaped version of the same argument. Under the 2017 Trust Services Criteria, CC7.2 asks that the entity monitor system components and their operation for anomalies indicative of malicious acts, natural disasters and errors, and that anomalies be analysed to determine whether they represent security events. One of its points of focus asks for detection tools implemented on infrastructure and software, including “logging of unusual system activities”. An agent’s tool calls are system activity. Its conversation is not.
And the risk framing points the same way. OWASP moved Excessive Agency to LLM03 in the 2026 edition of its Top 10 for LLM Applications, up from LLM06 in 2025 — the largest upward move in the list, driven by production incidents in agentic systems. Excessive agency is a statement about what an agent was permitted to do and did, which is exactly the thing tool-call history records and exactly the thing a transcript obscures. If you are going to build one logging capability this year, build that one. Prompt injection reaching a tool call is the same story from the attacker’s side.
Twelve fields, and how each one goes missing
These are not a schema to copy verbatim. They are what the questions asked during a real investigation reduce to. Read the fourth column rather than the first — almost every organisation believes it captures these fields, and the fourth column is where the belief usually breaks.
| Field | What it has to contain | Why an investigator needs it | How it goes missing |
|---|---|---|---|
| Triggering event | What started this run — a schedule, a webhook, an inbound message or document, a ticket transition, a human request, or another agent — with the source identifier and its timestamp. | It is the first question in every investigation and the only field that lets you trace an instruction that arrived inside content back to where it entered. | Runs are logged as “scheduled” with no upstream reference, so an inbound document carrying an injected instruction cannot be tied to the run it influenced. |
| Agent identity and version | The distinct principal the agent authenticated as, its configuration or prompt version, and the deployment it ran in. | Without a distinct principal, every downstream record attributes the action to a shared integration account and the trail ends at the boundary. | Several automations share one service account, so the log can prove an action happened but not which agent performed it. |
| Delegating principal and authority | On whose behalf the run acted, the delegation record relied on, the scope that record grants, and its expiry. | Accountability is a person, not a process. This is also the field that shows whether the agent acted inside the authority it was given. | Only the engineer who first deployed the agent is captured, not the business owner on whose behalf this particular run acted. |
| Model, version and endpoint | The specific model identifier and version, the provider endpoint, and any routing decision made at request time. | When behaviour changes, the first hypothesis is that the model changed. You cannot test that hypothesis against a floating alias. | The log records a family name or an internal alias that silently re-pointed, so a behavioural shift cannot be correlated with a version change. |
| Tool called | The canonical tool name, the server or source that provided it — an MCP server, a plugin, an internal API — and the capability version in force at call time. | A tool name alone is ambiguous. The same name served by a different server is a different capability, and that substitution is a known attack path. | Tool names are logged without their source, so a tool definition that was re-pointed or silently expanded is undetectable after the fact. |
| Parameters | The actual arguments passed, with credentials and sensitive fields redacted field by field rather than the whole record suppressed. | Parameters are where intent becomes specific. “Searched for a purchase order” is not investigable, but the eleven parameter sets tried in sequence are. | Parameters are hashed, truncated or omitted for privacy reasons — or, at the other extreme, logged in full including secrets, which turns the log into a target. |
| Resource touched | The specific record, file, repository, mailbox, ticket or account, by stable system identifier rather than display name. | Scoping an incident means answering which customers, which records, which files. Display names are not unique and they change. | “Updated a customer record” with no identifier, which converts a five-minute scoping question into a full reconciliation of the target system. |
| Action and outcome | The verb — read, create, update, delete, send, pay — the result code, and for writes either a before-and-after or a reference to the version created. | Success and failure are not the interesting distinction. Queued, partially applied and applied are, because they leave different states behind. | A boolean success flag that does not distinguish “the message was sent” from “the message was accepted for sending” from “the first two of five records were written”. |
| Errors and retries | Every attempt as its own entry, with the attempt number, the error returned, the backoff applied, and whether the parameters changed between attempts. | Repetition is the most reliable early signal of an agent in trouble, and it is the signal that costs money fastest. | Only the successful attempt is retained, so eleven failures and a loosened parameter set collapse into one clean-looking success. |
| Human intervention | Who was asked, what they were shown, when they were asked, how long they took, and whether the outcome was approval, modification or rejection. | An oversight control that cannot be tested is not a control. This field is the entire evidence base for it. | An approved flag with no approver identity, no timestamp and no record of what was actually displayed at the moment of approval. |
| Workflow status | The run state and, crucially, its terminal state: completed, completed with exceptions, aborted, timed out, stopped by a circuit breaker, stopped by a human. | A run that stopped halfway leaves partial state somewhere. Without a terminal state you cannot tell an abandoned run from a finished one. | No terminal status is written at all, so runs that died are indistinguishable from runs that succeeded except by inference from the last entry. |
| Correlation identifier | A run identifier and a step identifier, propagated into every downstream system the agent writes to, in whatever field that system will carry. | It is the join key. Without it, the agent log and the system-of-record log are two accounts of the same night that cannot be reconciled. | The identifier is generated and stored locally but never propagated, so it exists on exactly one side of the join it was meant to enable. |
Three standards bear on this list, and it is worth knowing which says what. ISO/IEC 42001:2023 carries an Annex A control on recording AI system event logs (A.6.2.8) alongside one on AI system operation and monitoring (A.6.2.6). Neither enumerates fields — the standard asks you to determine when logging should be enabled and to operate and monitor the system, and leaves the design to you. In a SOC 2 examination, the same records serve monitoring under CC7.2, the evaluation of whether an event is an incident under CC7.3, and the response under CC7.4. And Article 12 of the EU AI Act — Regulation (EU) 2024/1689 — requires high-risk systems to be designed with automatic logging capability over their lifetime, which is a design obligation rather than an operational one and therefore lands on whoever builds the system.
One point of focus is worth quoting because it is the most useful description of a good log anybody has written down. Under CC2.1, the criterion on obtaining and using relevant, quality information, the point of focus on maintaining quality throughout processing asks that information systems produce information that is “timely, current, accurate, complete, accessible, protected, verifiable, and retained”. Every failure in the fourth column above is a failure of one of those eight words, and the list is a serviceable review checklist for a logging design before you build it.
You do not have to read every prompt
When a board asks how AI use is being monitored, the instinctive answer is content review, and it is the wrong instinct. Reading prompts is the most intrusive, most expensive and least generalisable thing you can do: it does not scale past a sample, it does not produce a control anybody can test, it draws employment-monitoring and privacy obligations that vary by jurisdiction, and it changes behaviour in ways that make the remaining signal worse. The layers below are ordered from cheapest and least intrusive to most, and the useful discipline is that routine monitoring lives in the first four.
| Signal layer | What it is | What it tells you | Privacy cost | Governance value |
|---|---|---|---|---|
| L1 · Volume and shape | Run counts, tool-call counts per run, run duration, token and API spend per agent per day, and the trend of each. | Loops, scope creep, dormant agents nobody decommissioned, and cost curves bending before the invoice arrives. | Negligible — no content, no personal data, safe to hand to a platform team or a finance owner. | High. It is the cheapest layer to build and the one that most often catches a problem while it is still small. |
| L2 · Capability and permission | Which tools each agent actually called, which calls an authorisation layer denied, and which newly available tools appeared in its reach. | Whether the operated capability set matches the approved one, and whether something is probing at the edges of what the agent may do. | Negligible — metadata about capability, not about content. | The highest governance value per unit of effort. It directly evidences that the approval you documented is the approval that is in force. |
| L3 · Outcome and exception | Failure and rollback rates, retry distributions, and the proportion of escalated actions that a human modified or rejected rather than approved. | Whether the agent is competent at its task and whether the human oversight in the design is real rather than ceremonial. | Low — outcomes and decisions, not the content of either. | High, and unusually persuasive to a buyer, because a modification rate above zero is evidence a reviewer is actually reading. |
| L4 · Downstream reconciliation | What changed in the system of record, seen from that system: records amended, transactions posted, messages sent, files written. | The difference between what the agent believes it did and what actually landed — the only layer that can settle that argument. | Medium — business data, and sometimes personal data, so scope it to counts and identifiers where you can. | Essential. Self-reported completion counts are an assertion. The target system is the evidence. |
| L5 · Content inspection | Reading prompts, retrieved context and model outputs — the transcript itself. | Why a particular decision was made. Nothing else can answer that question, and this can only answer it for cases you already have reason to open. | Highest. Frequently involves employee communications, customer data, or both, and attracts employment and privacy obligations. | Indispensable for investigation, poor as routine monitoring. It does not scale, it does not generalise, and standing access to it is difficult to justify. |
The rule that falls out of the table is worth stating as policy: content inspection is an investigative capability, not a standing practice. Give it a named authorisation path, restrict it by role, log the reads themselves, and tell people the capability exists and when it is used. Quality-assurance sampling of outputs is legitimate and often valuable, but define the sample, the purpose and the reviewer role in advance rather than granting a general entitlement to read.
The second-order benefit is organisational. Layers one to three can be reviewed by a platform or GRC team that has no business reading customer records or employee messages, which means monitoring can be assigned to someone with the time to do it rather than restricted to the small group cleared for the content. Monitoring that only one person is allowed to perform is monitoring that stops when that person is on holiday.
Five alerts that earn their noise
An alert nobody reads is worse than no alert, because it appears in a control description and then fails a test. These five cover the great majority of what actually goes wrong with unattended agents, and the fourth column is where each one is usually got wrong in practice.
| Alert | The condition to define | What it catches | Where it goes wrong |
|---|---|---|---|
| Failed actions on write paths | Any state-changing tool call that returns an error, evaluated per agent and per target system against a rolling baseline rather than a fixed count. | Partial completion, which is the worst state an automated run can leave behind, and integration breakage after an upstream change. | Alerting on read failures with the same weight, which produces enough volume that the write failures stop being read. |
| Escalating retries | The same tool against the same target attempted more than a stated number of times in a stated window, or backoff exceeding a ceiling. | Reasoning loops and unbounded tool calling — the behaviour OWASP groups under Unbounded Consumption in its 2026 LLM list, where the harm is a drained budget rather than an outage. | Counting retries per run instead of per target, so a loop that spans successive runs never crosses the threshold. |
| Permission denials | Any tool call refused by an authorisation layer, alerted individually for high-risk capabilities and as a rate for everything else. | Scope drift, stale delegations, and the probing that follows a successful prompt injection — Prompt Injection is LLM01 in the 2026 edition. | Denials are recorded only by the system that refused, never written back into the agent log, so the two halves of the event never meet. |
| Anomalous spend or volume | Token spend, API cost, call count or records touched per hour against a rolling baseline, with a hard ceiling that stops the run rather than only notifying. | Cost incidents and runaway scope, and it is the alert most likely to pay for the whole monitoring programme in its first year. | A monthly billing alert standing in for a per-agent hourly one. By the time the invoice moves, the spend has already happened. |
| Activity outside the approved window | Runs outside the schedule, hours or trigger sources the agent was approved to operate under, including any manual invocation. | Compromised or misconfigured triggers, forgotten test deployments still holding live credentials, and undocumented human re-runs. | Defining the window in one timezone for a service that follows the sun, which generates enough false positives to get the rule disabled. |
Two design rules make the difference between an alert set and a control. Every alert names an owner and a first action, so that the artefact produced is a decision rather than a notification. And any alert that has never fired in six months is either misconfigured or is itself evidence worth presenting — decide which, in writing, before an assessor asks. The chain the criteria expect runs from monitoring under CC7.2 to evaluating whether an event is an incident under CC7.3 to responding under CC7.4, so the record each alert leaves should be legible as a step in that chain rather than as a chat message that scrolled past. What counts as an incident in the first place is worth settling separately. See what counts as an AI incident. Where an alert should stop the agent rather than merely notify, the mechanism belongs with kill switches and circuit breakers, and the ceilings that make spend alerts meaningful are covered in spending and transaction limits.
Long enough to investigate, long enough to evidence
Retention is the detail most often decided by accident, because the platform default is mistaken for a policy. Six forces pull on the number, five of them upward and one down, and a defensible answer names all six rather than picking the largest.
| Driver | What it demands | The usual shortfall |
|---|---|---|
| The investigation window | Long enough to cover the realistic lag between a bad agent write and somebody noticing it, which is usually weeks and sometimes a quarter. | Orchestration platforms often retain tool-call history for days or weeks by default, and the default is treated as a decision. |
| SOC 2 Type 2 observation period | The whole period plus the lag before fieldwork asks — so a six-month period commonly needs nine months of retained records. | Month one of the period has aged out by the time the request list arrives, and no amount of goodwill recreates it. |
| ISO 42001 certification and surveillance | Evidence covering the period since the last visit, for a management system certified on a multi-year cycle with annual surveillance. | Retention set for engineering convenience, then a surveillance audit asks about a month that no longer exists. |
| EU AI Act, high-risk systems | Automatically generated logs kept for at least six months — Article 19 for providers, Article 26(6) for deployers — unless other Union or national law says otherwise. Financial institutions keep them within their existing regulatory documentation. | Teams read the six months as a target rather than a floor, and set retention to exactly six months with no allowance for the lag before anyone asks. |
| Sector record-keeping law | Whatever the underlying transaction requires. An agent that posts a journal entry inherits the retention rule of the journal entry. | The agent log is governed as telemetry while the record it created is governed as a book of account. |
| Data minimisation | The opposite. Prompts and retrieved context frequently contain personal data, and that data does not acquire a longer life by being copied into a log. | Skeleton and payload are held in one store with one retention rule, so the organisation is forced to choose between investigability and minimisation. |
The design that resolves the tension is to stop treating the log as one object. Split the event skeleton from the payload. The skeleton — identity, delegating principal, tool, resource identifier, outcome, timestamps, terminal status, correlation identifier — is small, structured, low in sensitivity and cheap to keep for a year or more. The payload — prompt text, retrieved document content, parameters carrying personal data — is large, sensitive and can be retained on a shorter clock or redacted field by field. Most organisations hold both in one store under one rule and are then forced to choose between investigability and minimisation, which is a choice nobody needs to make.
Two practical additions. Retention on agent platforms is usually a plan or tier setting rather than a property of the product, and vendors change these terms — check what yours retains today in current vendor documentation rather than assuming, and re-check it at renewal. And export daily to storage you control, with the agent identity excluded from the principals able to administer that store. The same reasoning that keeps administrators out of the security logs they generate applies here to a new class of actor.
Where a distinct identity pays for itself
The agent log says an invoice was amended at 02:14. The finance system says an invoice was amended at 02:14 by svc-integration. If forty automations share that account, those are two accounts of the same event that cannot be joined, and the investigation stops precisely where it becomes interesting. This is the moment at which the cost of giving each agent its own identity is repaid, and it is why identity is a logging decision as much as an access one.
There are three joins to engineer, and they fail in different ways. The identity join requires the agent’s principal to appear as the actor in the downstream record, which means resisting the convenience of a shared integration credential. The correlation join requires the run and step identifier to travel — in a request header, a commit trailer, an idempotency key, a ticket comment, or whatever field the target system will carry. The time join requires clock discipline: log in UTC, keep sources synchronised, and know whether the downstream timestamp means created, modified or replicated, because a two-second difference across a system boundary is the difference between a clean chain and an argument.
Some systems will not carry a custom identifier at all, and that is a solvable problem rather than a reason to give up. Put the run identifier in whatever human-readable field exists — reference, memo, description, comment — or write a mapping entry at the moment of the call, so that the join is materialised by you rather than discovered later. What does not work is reconstructing the association afterwards from timestamps alone, which is feasible for one agent and impossible for twenty.
The reason to build all three is that the downstream system is the only place the truth lives. An agent’s own summary of its night is an assertion. The system of record is evidence. Every serious question — what did it actually change, how many customers were affected, did the write land twice — is answered on the far side of that join. The identity side of the design is covered in agent identity and delegated authority, and where the tools themselves come from a third party, MCP server governance covers the source-of-tool question this record depends on.
More than seventy tool calls, nine minutes, one wrong match
An illustrative composite, not a client. A 240-person software company runs a finance-operations agent that reconciles supplier invoices to purchase orders every night. It holds its own identity, a delegation from the accounts-payable manager, five tools, a spend ceiling, and a rule that any match above $10,000 is escalated to a human. Read the timestamps in the middle column.
| Trigger | 12 June, 02:00 | The scheduled run opens as run r-20260612-0200 under the identity svc-agent-ap-recon, acting under a delegation from the accounts-payable manager. Sixty-three supplier invoices are waiting in the monitored folder. |
| Minute 2 | 02:02:14 | Thirty-eight invoices are matched to purchase orders and written to the ERP. Each write carries the run identifier in the ERP reference field, which is the only field that system will accept from an external caller. |
| Minute 4 | 02:04:51 | Invoice INV-4471 finds no purchase order. The agent calls the search tool eleven times in a hundred seconds with progressively looser parameters. Each attempt is logged separately with its error and its parameter set. |
| Minute 6 | 02:06:30 | The eleventh call returns a purchase order belonging to a different supplier with a similar name. The agent writes the match. The value is $8,940 — below the $10,000 threshold at which a human is asked — so nobody is asked. |
| Alert | 02:06:31 | The retry rule fires: same tool, same target, eleven attempts inside the window. It lands in the finance-engineering channel with the run identifier in the message. |
| Minute 9 | 02:09:12 | The run reaches a terminal state of completed and posts a summary: sixty-two matched, one unmatched. That summary is the agent’s own account of the night, and it is wrong. |
| Detection | 12 June, 09:20 | An analyst opens the alert at the start of the working day. Time from action to detection: six hours and fifty minutes, all of it outside working hours. |
| Reconstruction | 09:20 – 09:34 | Fourteen minutes from the tool-call history alone: the trigger, the eleven attempts, the parameter loosening, the write, the resource identifiers on both sides, and the absence of any human decision. |
| Correction | 12 June, 11:05 | The journal is reversed. The approval rule is changed so that any match reached after more than three search attempts requires a human regardless of value, and the change is recorded against the agent’s configuration version. |
What the record answered. Every question of fact, in fourteen minutes, without anybody being woken up: which invoice, which purchase order, which supplier, how the parameters were loosened across eleven attempts, that no human was consulted, that the value fell below the threshold, and — through the run identifier in the ERP reference field — exactly which downstream rows to reverse. None of that came from the transcript.
What it did not answer. Why the eleventh parameter set was chosen. That answer lived in the reasoning trace, which was retrieved under a documented investigation authorisation, read by one named person and logged as a read. This is the case content inspection is for: a specific open question, a bounded retrieval, a recorded access. It is not an argument for reading everything routinely, and the fourteen minutes of reconstruction that preceded it were what made the retrieval precise enough to be cheap.
The failure is also worth naming correctly, because the instinct is to blame monitoring and the instinct is wrong. The alert fired one second after the write. Detection worked. What failed was threshold design: approval was keyed to value when the risk signal in the data was the retry count. An $8,940 match reached on the first attempt and an $8,940 match reached on the eleventh are not the same event, and only one of them should have proceeded unattended.
Escalation thresholds should key on the risk signal, not only on the amount. The agent told you it was in trouble eleven times before it did the damage.
One last detail. The run’s own summary said sixty-two matched, one unmatched, and it was wrong — not because the agent was deceptive, but because it had no way to know its match was incorrect. Self-reported completion counts are an assertion about intent. The reconciliation against the finance system is the evidence, and it is the layer that organisations build last and need most.
Eight numbers management can act on
A monitoring programme becomes governance at the point where somebody senior looks at numbers and makes a decision. The fourth column is the part that matters: a metric with no decision attached to it is a chart, and a chart is not a control.
| Metric | How to define it | What a bad number means | The decision it drives |
|---|---|---|---|
| Active agents against registered agents | Distinct agent identities that made at least one tool call in the period, reconciled to the agent inventory. | Identities acting that are not in the register, or registered agents dormant for a quarter while still holding credentials. | Register it or decommission it. Dormant agents with live credentials are the cheapest risk to remove. |
| Tool-call volume per agent | Calls per agent per period, with the change on the previous period and the reason for any step change. | A material step change with no corresponding entry in the change record for that agent. | Investigate whether scope, prompt or model changed, and whether the change went through approval. |
| Capability drift | Tools called that sit outside the approved set, plus tools newly reachable by an agent but not yet reviewed. | Any non-zero figure in the first column. It means the approval record and the running system disagree. | Approve deliberately or block. This is the metric that keeps the tool-approval process honest. |
| Permission denial rate | Denials per thousand calls, broken down by agent and by tool, with the trend. | A rising trend, or a flat zero — which usually means the authorisation layer is not actually in the call path. | Tighten scope where denials cluster, and verify enforcement where the number is implausibly clean. |
| Escalation and modification rate | Proportion of actions escalated to a human, and of those escalations, the proportion modified or rejected rather than approved. | An approval rate at or very near one hundred per cent, which is the signature of rubber-stamping. | Change what the reviewer is shown, or reduce escalation volume so the remaining reviews get real attention. |
| Failed write and rollback rate | State-changing calls that errored or were reversed, as a proportion of state-changing calls. | A rising rate, or partial completions that never received a terminal status. | Fix idempotency and terminal-state handling. This is an engineering decision, not a prompt-tuning one. |
| Spend against ceiling | Cost per agent per unit of work, and peak hourly spend as a percentage of the hard ceiling. | Peaks routinely approaching the ceiling, which means the ceiling is now load-bearing rather than a backstop. | Raise the ceiling as a documented decision, or find the loop. Never raise it silently to stop an alert. |
| Time from agent action to detection | For incidents that involved an agent, the interval between the action and the first human awareness of it. | Anything measured in weeks, and any case where detection came from a customer rather than from your own signals. | Add a downstream reconciliation rather than another alert. Detection failures are usually coverage gaps, not tuning gaps. |
These are the numbers an ISO/IEC 42001 management system expects to be fed with, through its clauses on monitoring, measurement, analysis and evaluation and on management review, and they are equally the raw material for the ongoing and separate evaluations contemplated by CC4.1. In the NIST AI Risk Management Framework the same territory sits under MANAGE 4.1, which asks that post-deployment monitoring plans be implemented including mechanisms for capturing input, appeal and override, decommissioning, incident response, recovery and change management. Three of the eight rows above are the appeal-and-override and decommissioning halves of that sentence made countable.
Two practical notes on presentation. Give each metric a threshold before you first report it, so that the first bad number produces a decision rather than a discussion about whether it is bad. And report the same eight every time — the value of a management review comes almost entirely from the trend, and a metric set that is redesigned each quarter has no trend to show.
What the assessor actually requests
Teams expect to be asked for a screenshot of a dashboard. What arrives first is a request for a population — because a sample drawn from an incomplete list proves nothing about the list, and establishing that the information you produced is complete and accurate is a step in its own right before any testing starts.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| The population of agent runs for the period | A system-generated export of every run for every in-scope agent, with the query, filter, date range and record count visible, reconciled to the agent inventory. | A dashboard view. An export that begins where retention happened to begin. A list quietly missing agents somebody decided were out of scope without a documented scoping decision. |
| The population of high-risk actions | Every write, payment, send or delete performed under an agent identity during the period, drawn from the downstream systems and reconciled to the agent’s own log. | The agent’s self-reported completion counts. A population drawn only from the orchestration platform, which can show what was attempted but not what landed. |
| Evidence that the alerting operated | Rule definitions captured at two or more dates inside the period, the delivery target, and at least one alert actually delivered, matched to its underlying event and to the action taken. | A screenshot of the alert configuration taken during fieldwork. An alert routed to a channel with no reader. A rule that was disabled mid-period with no record of when. |
| Evidence the human-in-the-loop control operated | For each selection: what was escalated, what the reviewer was shown, who they were, when they decided, and what they decided — approval, modification or rejection. | An approved flag. An approval where the approver is the agent’s own service identity. An approval timestamped after the action it purports to have authorised. |
| Evidence of log integrity and completeness | Retention configuration captured inside the period, evidence the store is append-only or tightly restricted, and proof that the agent identity is not among the principals able to amend or delete its own record. | A log the agent can write to freely. A retention setting changed mid-period with no audit entry. Gaps in the sequence with no explanation. |
| The review management performed | A dated review record naming attendees, the metrics reviewed, the thresholds applied, the exceptions raised, and evidence that the raised items were closed. | A link to a live dashboard. A review held after period end for a control scheduled inside it. Minutes that record attendance but no decision. |
On sampling, the shape of the population matters more than the number. A daily-run agent produces a population roughly equal to the number of days in the period, from which a service auditor commonly selects around twenty-five. An event-driven agent produces a population you have to bound before any sample can be drawn, and bounding it is the work. Where a control operated only a handful of times, expect the whole population to be tested, because there is no sampling risk small enough to absorb a deviation. Neither the trust services criteria nor the attestation standards prescribe a sample size — AT-C 205 requires sufficient appropriate evidence and leaves the quantity to professional judgement. The general mechanics of this are set out in what auditors actually accept.
There is one trap specific to agents. Any export from the orchestration platform is information produced by the entity — the artefact class auditors shorten to IPE — and in this case it is information produced by the very system whose behaviour is in question. That is not disqualifying, but it is why the query, the filter, the date range and the record count have to be visible, and why the high-risk-action population is better drawn from the systems the agent wrote to. Where the two disagree, the disagreement is the finding.
A note on who does what, because it is asked on every engagement. Tranquility Cybersecurity designs the logging and monitoring, prepares and reconciles the populations, and coordinates the examination or certification. It does not test, attest or certify. A SOC 2 report is an attestation under AT-C 205 issued by a licensed CPA firm — there is no SOC 2 certificate — and an ISO/IEC 42001 certificate is issued by an accredited certification body.
The edge cases that generate the questions
The field list above covers the ordinary eighty per cent. These eight are where a sensible design meets an awkward reality, and where settling the answer before an assessment is worth several days.
The agent is a vendor’s, and so are the logs
When the agent runs inside somebody else’s product you are a deployer, not a builder, and the record you need may not be yours. Five questions settle it: is the log exportable, how long is it retained, which of the twelve fields does it carry, does it distinguish your tenant’s runs from anyone else’s, and can you obtain it after termination. Treat the answers as contract terms and verify them in current vendor documentation rather than in a sales deck, because retention and export behaviour change between plan tiers and between releases. Where the answers are thin, compensate on your own side of the boundary: whatever the agent writes into your systems is recorded by your systems, and that is the population an assessor can actually test.
One agent calls another
In a multi-agent workflow the second agent’s log frequently shows the first agent as the principal, which makes authority appear to originate at the wrong point. The fix is to propagate the original human principal and the run identifier through the whole chain, and to record the calling agent as the trigger source rather than as the authority. The distinction matters in exactly the situation where it is hardest to reconstruct: an action taken four hops from the person who authorised the workflow. Where a chain crosses an organisational boundary, you are also looking at a service-provider question, with all the description and reliance issues that brings.
The log contains the data you were protecting
Prompts, retrieved context and parameters routinely carry personal data, which means the log is itself a store of personal data and inherits the rules for it. Three practical consequences: (1) redact at field level rather than suppressing whole records, because a suppressed record destroys investigability while a redacted field does not, (2) restrict read access by role and log the reads themselves, and (3) set retention by data class rather than by file, which is the argument for splitting the event skeleton from the payload in the first place.
You cannot reproduce the action
An assessor or a customer may ask you to re-run the decision and show the same result. Often you cannot: the model version, the retrieved context, the sampling behaviour and the state of the target system have all moved on. Say so early rather than during fieldwork. What you can preserve is the input side — the exact context supplied, the parameters, the model and version — so the action is explicable even where it is not reproducible. Explicability, evidenced, is a defensible position, but a reproduction promise you cannot keep is not.
The agent only reads
Read-only agents attract almost no logging attention because they change nothing, and then the one question that arrives about them — what did it have access to see — cannot be answered. Read actions need resource identifiers for the same reason writes do. For a retrieval agent the population that matters is not what it changed but what it was able to reach, and that population is defined by the connector permissions rather than by the query history.
The run that was stopped
A run halted by a circuit breaker or a human is the hardest case to reconstruct, because the interesting state is what had already been written when the stop landed. If the log carries no terminal status and no record of completed steps, an operator has to reconcile the target system by hand at exactly the moment they are least able to. Terminal state and a per-step completion record are not tidiness. They are what makes a stop safe to use, which is why teams that skip them end up reluctant to pull the switch at all.
Agents running on developer laptops
Coding agents and locally installed tool servers frequently never touch a managed platform, so the record lives on one machine or nowhere. Two honest options: bring them onto a managed path where runs are recorded centrally, or accept that the governing control is the downstream one — branch protection, review by a non-author, deployment approval — and describe it that way rather than claiming agent-level logging you do not have.
Retained but not searchable
Retention and investigability are different properties. A cold archive that satisfies a six-month obligation but takes three weeks to query fails the only test that matters during an incident. A workable split is that the most recent ninety days are queryable in minutes by the people who respond, and everything beyond that is recoverable in days under a documented process. Write both numbers down. An assessor will ask about the second one and an incident will expose the first.
Where agents are numerous enough that per-agent design stops scaling, the answer is risk classes with inherited logging requirements rather than a bespoke decision for each one — the same move that keeps an AI system inventory maintainable once it passes a few dozen entries.
What a security team pushes back on and the answer
These seven come up in almost every enterprise review of a vendor running agents against customer data, and in most internal reviews too. The difference between a good answer and a defensive one is that a good answer offers a number.
“We need to see every prompt your agents receive.”
Ask what the underlying concern is, because it is almost always one of two things: injected instructions arriving inside content, or sensitive data leaving through the agent. Neither is best answered by transcript access. The trigger-source record shows where content entered, the permission-denial rate shows what was attempted and refused, the capability set shows what was possible at all, and the downstream reconciliation shows what actually moved. Offer content inspection as an investigative capability with a named authorisation path and its own access log, rather than as a standing entitlement. Prompt Injection sits at LLM01 in the 2026 OWASP list precisely because the defence is capability restriction and monitoring, not reading everything.
“Your agent runs at 2 a.m. with nobody watching.”
That is the design, and the honest answer is to move the conversation to the three numbers that bound it. What is the ceiling on what a single run can do — value, volume, and which capabilities are reachable at all. What is the measured time from an anomalous action to a human being aware of it. And what is the stop path, who can invoke it, and what state does it leave behind. A vendor who can give those three numbers with evidence is describing a governed system, while a vendor who offers reassurance about care and diligence is not.
“Show us that a human approves high-risk actions.”
This is a reasonable request and it is testable, so answer it with the population rather than the policy: the count of actions that crossed the escalation threshold, who reviewed each, what they were shown, and the proportion they modified or rejected. It is worth saying out loud that a one hundred per cent approval rate is a weaker answer than a ninety-two per cent one. A reviewer who never changes anything is either superfluous or not reading, and a security team that has run these reviews themselves will recognise that immediately.
“How do we know the agent has not deleted its own logs?”
By the identity boundary, and it is worth engineering deliberately because it is easy to get wrong. The agent principal should not appear among the principals able to amend, delete or reconfigure the store its own records land in, and the retention setting should itself be covered by a change log. The evidence is the permission definition captured at two dates inside the period, the append-only or write-once configuration of the store, and the platform audit entries for any change to retention. This is the same reasoning applied to administrator access to security logs, transposed to a new class of actor.
“Your logs only go back thirty days.”
If that is true, it is a finding rather than a debate, and the fastest route through it is to concede it and show the correction: the retention decision, the date it was made, the export job that now writes to storage you control, and the date from which the complete record exists. Do not argue that thirty days is proportionate while an assessor is looking at a six-month period. The teams that handle this well are the ones that discovered it themselves during readiness rather than during fieldwork.
“We want the agent’s reasoning for every decision.”
Reasoning traces are expensive to retain, frequently contain the sensitive content the rest of your design is trying to minimise, and are not a reliable account of cause — they are generated text about a decision, not the decision. The workable commitment is to retain the inputs, the model and version, the tool calls and the outcomes for everything, and to retain or reconstruct the reasoning trace for cases under investigation. State what is retained, for how long, and who can read it. That is a position you can hold for years, but blanket retention of reasoning usually is not.
“This is just observability. We already have that.”
Partly, and the overlap is worth using — but application performance monitoring is engineered for latency and error rates, which is a different question from accountability. Three differences bite. APM traces are usually sampled, and a one per cent sample cannot evidence that a control operated on a specific action. Retention is typically days or weeks, against an assessment window of months. And the fields that matter here — delegating principal, human intervention, terminal state, the correlation identifier as it appears in the system of record — are not fields an APM schema has any reason to carry. Extend the stack rather than buying a new one, but do not assume the coverage is already there.
The first fortnight, in order
None of this needs a platform purchase to begin, and the sequence matters more than the pace. The first two steps are diagnostic and cost an afternoon each.
- 01 List the agents that already act on your systems, and for each one write down the identity it authenticates as. The exercise usually finds two or three sharing a service account, which is the single highest-value fix on this page.
- 02 Take one real action from as far back as your logs go and try to reconstruct it against the twelve fields. Record which fields you could not fill. That list, not a maturity model, is your backlog.
- 03 Fix the correlation identifier before anything else, because it is the field that makes every later investigation cheap and the only one that has to be present at write time to be useful at all.
- 04 Turn on the five alerts with deliberately loose thresholds, route them somewhere a named person reads, and tighten over a month. An alert with no owner is a log entry with extra steps.
- 05 Make the retention decision explicitly: check what your orchestration platform actually retains today on your plan, split the event skeleton from the payload, and schedule a daily export to storage the agent identity cannot administer.
- 06 Put the eight metrics in front of whoever owns AI risk on a stated cadence, with a threshold beside each one. A metric without a threshold is a chart, but a metric with a threshold and a recorded decision is a control.
The sequencing rule that matters most is the same one that governs any control being prepared for examination: the logging has to be in place before the observation or certification period opens, not during it. A record that begins in week six of a twelve-week window did not cover the window, and no amount of subsequent diligence recovers the first five weeks.
Frequently Asked Questions
What should an AI agent audit log capture?
Is logging prompts and outputs enough?
How long should we keep AI agent logs?
Does ISO 42001 require agent logging?
Do we have to read what employees type into AI tools?
What alerts should we set for background agents?
How do we connect agent logs to changes in our other systems?
What will a SOC 2 auditor ask for about agent monitoring?
Can we just use our existing observability or SIEM stack?
What agent metrics should go to management or the board?
Related Reading
AI Supplier Due Diligence and Ongoing Review
The artefacts to obtain, why plan tier changes the answer, and what triggers re-review.
Read moreWhen a Model Changes, What Do You Reassess?
The material-change test, the detection problem, and regression testing at scale.
Read moreGoverning Hundreds of Agents
Risk classes and inheritance instead of hundreds of individual assessments.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more