AI Audit Trail for Agents: The Six Questions Your Log Must Answer

An AI audit trail for agents is useful only if it answers six questions: who asked, which build acted, what it saw, what allowed it, who approved, and what changed. An API-only log answers an easier seventh question: which API was called. Making it immutable does not help; immutability preserves the gaps too. This is for the CTO and compliance lead signing off an agent before go-live: a field-level schema, a rule for which actions need it, the legal hooks with their real dates, and one test. Can someone reconstruct a decision from the log alone?

On 3 July 2026, MAS published, with industry partners, SAFR, the Safeguards for Agentic Finance at Runtime white paper, in which a tamper-evident audit log is one of four components. On 5 August, MAS told Parliament its AI risk guidelines covering agentic AI "will be finalised soon". This is general information, not legal advice.

Why isn't an immutable AI audit trail enough?

An immutable AI audit trail proves a record was not altered after it was written. It cannot prove the record holds the right facts. A tamper-evident line reading "service account called the refunds endpoint, 200 OK" is perfectly preserved and still useless to an investigator, because it says nothing about who asked, what the agent knew, or which rule let the call through.

Immutability is a storage property. Usefulness is a schema property. It is easy to buy the first and assume the second.

IMDA's Model AI Governance Framework for Agentic AI (version 1.5, published 20 May 2026, updated 5 June 2026) lists "ensure log immutability" as one practice among several. Before it, it says organisations should decide "what to log" by working back from their monitoring objectives. Decide what an investigation needs. Then lock it down.

The second problem is less obvious: an agent is an unreliable narrator of its own work. The same IMDA framework warns that chain-of-thought reasoning "may not be a faithful explanation of the agent's actions." SAFR goes further: the trace an agent submits with a proposed action is agent-declared; both "can be fabricated together by a sophisticated adversarial injection." So SAFR treats that package "as a document to be authenticated against its origin, not merely as a record of what the agent reported."

It is tempting to treat the reasoning trace as the "why" of an audit record. Keep it, label it agent-declared, and never let it be the only answer to a question. What the agent saw should come from the retrieval layer and the tools.

What six questions will an investigator ask about an agent?

An investigator reconstructing an agent action asks six things. Who asked, and on whose authority? Which agent, model, prompt and policy version was running? What did the agent actually see? What rule allowed the action? Who approved it, and what were they shown? What changed in the target system, and can it be reversed? Each answer belongs to a different system.

Your identity provider knows who asked. Your agent registry knows which build ran. Your retrieval layer and tool gateway know what data came back. Your policy engine knows which rule fired; your confirm step knows who approved; the target system knows what changed. The decision record joins those answers under one action ID at the moment of decision, so nobody stitches six systems together under deadline later.

IMDA's framework adds one detail. The capacity in which an agent acts, "independently or on behalf of a specified human user", should be "recorded for auditability". That is the on_behalf_of field, and it is separate from the service account the agent runs under.

SAFR's audit entry covers part of this. Each entry "should capture the essential elements of a governance decision: the governance envelope as submitted, the mandate against which the action was checked, the outcome produced by the Disposition Engine, the specific rules applied, the basis for that outcome, and the time elapsed at each stage." Mandate and rules answer "what allowed it".

The envelope is not an independent answer to "what did it see", though. SAFR defines it as the proposed action, an agent-declared trace of how the agent reached it, and context metadata such as agent identity, mandate and account state. It has no field for the human who asked, so add principal_id yourself. SAFR targets financial institutions; the six questions are the same for a clinic.

The EU AI Act does not prescribe this schema either. Article 12 lists minimum log fields only for remote biometric identification systems (Annex III point 1(a)). One of them is "the identification of the natural persons involved in the verification of the results", tied to the two-person check in Article 14(5). That is a narrow biometric safeguard, not a general duty to log approvers. Still, where the law lists fields, it asks for the human who checked.

Which agent actions need a full decision record?

An agent action needs a full decision record when it writes to a system of record, moves money, sends something outside the organisation or changes a permission. Read-only lookups can live in ordinary traces. IMDA's agentic framework (v1.5, May 2026) points the same way, telling organisations to prioritise monitoring for "updating database records or financial transactions".

Write the record before the action executes, and fail closed: if the record cannot be written, the action does not run. A record assembled afterwards by a pipeline that can drop events is a trace, not evidence.

Never sample. Tracing pipelines often keep a fraction of spans to save cost; a decision record for one refund in ten is worthless in a dispute about the other nine.

Log denials and escalations as well as approvals. SAFR's log captures the record and outcome "for every action regardless of result", and a run of denied attempts is exactly what you want to see when you suspect a prompt injection.

Give every step its own record. SAFR says an Auto-Execute or Observe outcome "at one step carries no authority into the next", so each consequential step is checked and logged separately, linked by a parent_action_id.

Then alert on gaps: any consequential record with an empty field for one of the six questions should page someone. A blank approver on a refund above the cap is an incident, not a data-quality issue.

Illustrative example: at 2 KB per record and 5,000 consequential actions a day, the decision record grows by about 10 MB a day, or roughly 3.7 GB a year. Storage is not the cost. Instrumenting the policy engine and the confirm step is.

What should an AI agent log? A field-by-field schema

An AI agent should log one decision record per consequential action. The record holds identifiers and hashes, not raw content: who asked, which versions ran, references to the inputs used, the rule that fired, the approver and the before-and-after state. Raw prompts and outputs go to a separate store with shorter retention.

Here is the schema we would hand an engineering team, with the question each field answers. Retention figures are design suggestions, not legal minimums.

Two fields do more work than their size suggests. The first is policy_version. When an agent misbehaves after weeks of good conduct, check what changed before blaming the model. That is a working hypothesis, not a measured base rate, and you cannot test it without versions in every record.

The second is shown_payload_hash. An approval proves little if the approver saw one version and the agent executed another. Hashing the exact payload shown at the confirm step and comparing it with the executed payload closes that gap.

Now the privacy tension. Singapore's PDPA section 25 requires an organisation to "cease to retain its documents containing personal data, or remove the means by which the personal data can be associated with particular individuals" as soon as it is reasonable to assume the original purpose is no longer served and retention "is no longer necessary for legal or business purposes." Because the section allows retention for a legal or business purpose, the answer is design: a lean decision record kept for a documented audit and dispute window, and raw transcripts on a much shorter clock.

Two cautions. A principal_id is still personal data, so the lean record stays in scope. And a hash de-identifies nothing while you still hold the transcript it came from; delete the raw store on schedule, or the hash is only a pointer. IMDA's framework flags a further risk in multi-agent setups, where sharing context between agents "increases the likelihood for sensitive data to be unintentionally logged".

What does the law require of AI agent logs in the EU and Singapore?

The EU AI Act will require automatic logging, kept for at least six months, for Annex III high-risk AI systems from 2 December 2027. Article 12 sets the logging duty; Articles 19 and 26(6) set retention for providers and deployers. Annex I systems follow from 2 August 2028. Singapore has no agent-logging statute that we found; MAS and IMDA guidance set expectations, and the PDPA limits retention.

The table separates binding law from guidance.

Three readings matter for a Singapore business. First, the EU dates moved. Regulation (EU) 2026/1744 defers Chapter III Sections 1 to 3, which hold Article 12 as well as Articles 19 and 26. EU-regulated financial institutions keep the logs with their financial-services records. The legal duty touches a Singapore firm only if it places high-risk systems on the EU market; the schema matters regardless.

Second, MAS has not made SAFR a rule. The 5 August 2026 parliamentary question asked whether MAS would move from SAFR towards mandatory supervisory requirements. The reply made no such commitment. It called SAFR "a potential approach to how agent actions are authorised, how human oversight is activated, and what is recorded at the point of every consequential decision", and said MAS would keep its supervisory expectations under review. Do not tell your board that supervisors have asked for this schema.

What already applies is narrower. The Technology Risk Management Guidelines are supervisory guidance, not statute. Paragraph 9.2.2 asks institutions to "manage and monitor the use of system and service accounts for suspicious or unauthorised activities." An agent acting through a service account falls inside that sentence. The paragraph says nothing about a decision record, a rule ID or an approver. That part is design.

Third, the tracing standard does not cover the audit questions. The OpenTelemetry GenAI semantic conventions were still at Development status in August 2026. They name agents, models, tools and conversations. We found no attribute for an approver or a policy-rule outcome. Adopt them for tracing, then add questions four and five yourself.

A worked investigation: the refund nobody approved

In the made-up case below, an API-only log lets the team confirm that a refund call happened and little else, so it blames the model. A decision record shows the actual causes directly: a policy change that shipped without review, and a tool output the agent misread. Neither is fixed by a prompt rewrite.

Illustrative example: an online retailer runs a customer-service agent that can issue refunds. Refunds up to SGD 500 auto-execute; anything larger needs a supervisor at the confirm step. On a Monday, finance spots a SGD 4,000 refund with no approval attached.

The API log shows one line: 14:02, service account svc-cs-agent, POST /refunds, 200 OK. The team suspects the model "hallucinated", plans a prompt rewrite and pauses the agent for a week.

The decision record tells a different story. The request came from an authenticated customer chat (who asked). The agent ran policy version 12 (which build). Its input refs point to the order record and a courier lookup; the courier tool output, stored by hash, said "delivered", while the agent's own summary said "not delivered" (what it saw). Rule refund.auto_cap fired with outcome Auto-Execute, because version 12 had raised the cap from SGD 500 to SGD 5,000 (what allowed it). No approval was requested, correctly under that rule. The order was refunded in full and is reversible within the payment provider's window. The change history shows version 12 went live two days earlier, with no reviewer.

Two findings, neither of them "the model went rogue": an unreviewed tenfold cap change, and a misread tool output. The fixes are change control on policy thresholds and a rule that delivery status comes from the tool, never from the agent's paraphrase.

Each role takes a different lesson. For the CTO, build the instrumentation before go-live, because retrofitting identifiers into a running system means a migration. For the compliance lead, the record turns "we have logs" into "we can show who approved what, under which rule", the kind of evidence SAFR and IMDA describe, though neither is binding. For the owner, the API-only log cost a week of a paused agent and a fix aimed at the wrong cause.

Where Origin Pi stands

We build the decision record before the agent, because the agent is the wrong author of its own log. SAFR (MAS, July 2026) aims for the same thing: every action reconstructable "without relying on the agent's own account of what occurred."

In the agent-ready layer we build, every consequential action passes a policy check and, where the risk warrants it, a confirm step, and each writes its own entry under the action ID. Permissions are bounded per agent, so "who asked" and "on whose authority" are recorded facts rather than inferences. That separation is our design choice; SAFR and IMDA describe the problem, not a product. Cerebrum, the governed record we have in build, treats the decision record as a core primitive, and the pattern carries across many agents in one governed brain.

It also settles the accountability question IMDA's framework raises: you cannot hold a person accountable for an approval you cannot show they gave.

Before go-live, pick a plausible failure, hand the log to someone who did not build the agent, and ask for the six answers within an hour. Whatever they cannot answer is your schema backlog.