Skip to content
AIAC AI ASSURANCE COUNCIL™

Agentic AI oversight

IMDA Agentic AI Framework v1.5 §2.3.3 — Continuous testing and monitoring

No instrument requires an AI agent to keep a trajectory. The EU AI Act’s record-keeping duty reaches high-risk systems and their providers, not agents as such, and the only text describing what an agent’s trail should hold is a framework nobody has to follow. It names three layers to monitor, and conventional observability captures two.

§ 1 — Who it binds

Which agents produce a trajectory

Deployer

Any agentic deployment the framework reaches — software planning and acting across multiple steps towards a user-defined goal — with no risk tier, sector or size gate. The question arrives earlier than most: an agent that only reads still produces a trajectory somebody will later need to reconstruct, and the monitoring recommendations do not wait for write access to be granted.

§ 2 — In practice

Three layers, and the one nobody captures

How long records must be kept, and by whom, is settled ground: Article 12 puts automatic logging on the provider of a high-risk system and answers the retention question, which is not reopened here. What no instrument answers is what an agent’s log has to contain. A duty drafted for systems that produce outputs does not describe software that plans, calls tools, hands work to another agent and revises itself mid-task. The text that does describe it is §2.3.3 of the IMDA Model AI Governance Framework for Agentic AI, version 1.5 (20 May 2026, updated 5 June 2026) — guidance that recommends, carries no reporting duty, and attaches nothing to being ignored.

The framework derives content from purpose, and names three purposes: intervene in real time; debug when incidents happen, where logging and tracing each step of an agent workflow and agent-to-agent interactions help to identify points of failure; and audit at regular intervals. From those it asks for monitoring on multiple layers — the user-agent interaction, agent-tool invocation, and model reasoning layers — integrated with existing observability, including standards like OpenTelemetry for tracing. The third layer is the gap that matters. A well-instrumented stack reconstructs what the agent did and not why it decided to, which is the only thing distinguishing an erroneous action from an unauthorised one. In the Google and Singapore Government sandbox, reading the reasoning trace showed the agent sometimes considered such information nevertheless relevant, or presumed that it needed to include all information given to it — unreachable from tool-call logs.

Capturing reasoning is not the same as trusting it, and the framework is unusually careful on the point. §2.2.2 states that chain-of-thought reasoning, sometimes used for explainability, is not analogous to human reasoning and may not be a faithful explanation of the agent’s actions, citing Anthropic’s work on reasoning models not always saying what they think. The consequence for a file is exact: a reasoning trace is behaviour to be corroborated against the calls and their results, not testimony about intent. An assessor who accepts a plausible-sounding rationale as the explanation of an action has accepted the least reliable artefact in the record.

Two properties turn a log into a trail. The first is stated and almost never implemented — ensure log immutability, maintaining complete audit trails by ensuring that problematic agent trajectories and failures cannot be deleted, preserving them for analysis and compliance purposes. Agent frameworks characteristically retain traces in the same mutable store the agent itself can reach, so for anything with filesystem or database write access the record sits inside the blast radius it documents. The second is easier to miss. The Terminal 3 case study records each step, including any blocked actions, on a hardware-attested ledger, and a trail holding only what happened cannot evidence that a control fired. Where the limits set by an action envelope are the control being relied on, the refusals are the evidence for it.

Volume is named as the failure mode rather than the solution: as agents execute multiple actions at machine speed, organisations face the issue of extracting meaningful insights from the voluminous logs generated by monitoring systems. That reframes the assessable question. Depth of capture is straightforward to buy and to demonstrate; what is hard is showing anything was ever produced from the trail — one incident reconstructed, one control failure found, one policy changed. The draft MAS Guidelines reach the same ground from the supervisory side, proposing at paragraph 4.17 that documentation be sufficiently detailed for an independent party, such as a reviewer or auditor, to understand and potentially replicate the implementation of the AI system or model and its results. That is a reperformance standard, and it is the one worth holding a trajectory to whether or not the paper is ever issued.

§ 3 — What discharges it

What the trail has to be able to show

The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.

  1. 01

    One reconstructed trajectory for a real incident

    Plan, every tool call with inputs and outputs, hand-offs between agents, the reasoning at each step and every human intervention, assembled end to end for a case that actually happened. A sample of well-formed log lines is not a substitute for one story told completely.

  2. 02

    A log-layer coverage matrix

    The three layers the framework names, against four columns: what is captured, where it is stored, which principals can write to that store, and for how long. The row usually empty is model reasoning; the column usually wrong is the third.

  3. 03

    Recorded refusals — a declined tool call, a failed authorisation, a rejected approval

    One sample of each, retrieved from the running system rather than described. A record holding only successful actions evidences what the agent did and nothing about whether the controls around it work, which is the more common question.

  4. 04

    The immutability control, tested

    Not the vendor’s claim. Which principals can delete or amend entries, evidence that the agent’s own credentials are not among them, and a test showing an attempted deletion failed and was itself written down.

  5. 05

    A correlation identifier surviving hand-offs

    A convention, applied, that lets one goal be followed across sub-agents, retries and tool boundaries. Where each component logs under its own identifier the trajectory exists in fragments, and nobody can assemble it without a person who remembers the architecture.

  6. 06

    A handling position for trajectories carrying personal data

    Reasoning traces quote the input verbatim, so an agent handling correspondence produces a personal-data store nobody designed as one. The artefact states where those records sit, who may read them, and what happens on a subject access request.

§ 4 — Worked example

Worked example — a complaint the trace cannot answer

A bank runs a customer-servicing agent that reads account data, drafts replies and raises fee-reversal requests against a core system. The platform emits structured traces — every prompt, every tool call with its arguments, every response — retained for two years in the observability stack the rest of the bank uses. A complaint arrives about a reversal that should not have been granted, and the team pulls the trace within minutes.

The bank can show exactly what the agent did. Is that an audit trail?

It is most of one, and the missing part is the part the complaint turns on. The trace establishes the sequence of calls and their arguments, which answers whether the reversal was executed and by what route. It does not answer why the agent concluded the customer qualified — and the difference between a model that misread an eligibility rule and a model steered by something in the customer’s own message is the difference between a defect and an incident. Three things would close it. Capture at the reasoning layer, treated as behaviour to corroborate rather than an explanation to accept. Evidence that refusals are recorded as well as actions: the reversals the agent proposed and the authorisation layer declined, without which the bank cannot show its limits ever operated. And a store the agent’s own credentials cannot reach, since traces held in the observability platform the agent queries are not immutable in any sense worth relying on. Retention, at two years, is the one question already answered.

§ 5 — What a weak answer looks like

The observability stack offered as an audit trail

An observability dashboard offered as the trail. Latency, token spend, error rates and a searchable stream of calls — good engineering, and precisely what a platform vendor ships. Two questions expose it. Ask for the trajectory of one specific decision, end to end, and the answer arrives in fragments that a person has to narrate. Then ask whether the agent’s own service credentials can write to the store those fragments live in. Where the answer is yes, the record documents a blast radius it sits inside, and nothing in it can be relied on to establish what happened on the day it matters.

§ 6 — Elsewhere

Where record-keeping is written down elsewhere

Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.

  • EU AI Act

    Article 12 requires automatic recording of events over the lifetime of a high-risk system and sets the purposive sufficiency test those logs must meet. Retention and the provider’s duty are answered there; this page addresses what an agent’s trajectory has to contain.

  • NIST AI RMF

    MEASURE 2.4 addresses monitoring a deployed system in production, including the mechanisms that record and analyse behaviour. It supplies the framing the three monitoring layers sit inside.

  • NIST AI RMF

    MANAGE 4.3 addresses documenting incidents and errors, and communicating them. The reconstructed trajectory is what makes that documentation possible for a system that acts over many steps.

  • MAS instruments

    The draft Guidelines, paragraph 4.23(a), would have reasoning processes, actions taken and tools used monitored across workflows, and paragraph 4.23(d) would have access to models, pipelines and configuration files logged. Both remain proposals in a consultation paper.

A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.

§ 7 — When it applies

A publication date, not a deadline

  1. 20 May 2026

    The date version 1.5 published, updated 5 June 2026. A publication date and not a deadline — the framework recommends, and nothing is owed from this or any other date. Version discipline matters here because sections were added between 1.0 and 1.5.

§ 8 — provenance

The provision itself

This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.

§ 9 — Also read

Also read

Certification

Assessed on the same standard of evidence

Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The free AI Literacy Certificate is open to any adult today, and the register lists what is open for enrolment.

FreeAIAC AI Literacy Certificate30 minutes · identity verified · on the register
Open now →The credentials open for enrolmentThe register →