The evidence file

24 artefacts appear across Agentic AI oversight. 0 of them are demanded by more than one obligation, which makes them the ones worth building first: the same document, properly made, discharges several duties at once. An artefact that is merely present does not discharge anything, so each entry records what makes it sufficient — that sentence is the part an assessor is testing.

What you will be asked for

• A correlation identifier surviving hand-offs

  One obligation

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

    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.

• A dated residual-risk acceptance with a named accepter

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    Nothing compels this, which is why its presence carries weight. Where the framework’s language has been adopted, the record names who accepted, on what date, and precisely what — a tier assignment over a named set of actions, not an overall posture.

• A handling position for trajectories carrying personal data

  One obligation

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

    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.

• A justification line against every write permission

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    One sentence per write, naming who needs it and for which task. Writes accumulate during development for debugging convenience and are almost never withdrawn, so the unjustifiable ones are found by asking rather than by scanning.

• A log entry showing a runtime constraint firing

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    One real instance of a rate limit, validation rule or re-gating check stopping something during execution. Runtime controls are the class most often described in policy and least often observable in a log.

• A log-layer coverage matrix

  One obligation

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

    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.

• A permission matrix at tool, verb and object granularity

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    Exported from running configuration rather than transcribed from a design note, with read-only entries enforced at the connector. A matrix listing tools alone has recorded the grant and omitted its shape.

• A privilege-drift reconciliation, approved against running

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    The approved set compared with what the runtime holds today, and the exception list that falls out. The exceptions are the finding: entitlements nobody approved, and credentials that outlived the task they were issued for.

• A re-scoping trigger tied to capability change

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    New tools, new MCP servers, new hand-off targets and model upgrades widen what an agent can do without amending anything. The artefact is the mechanism that reopens the determination, plus one occasion on which it fired.

• A register separating deterministic limits from prompt-layer ones

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    Every limit named, alongside where it is enforced: connector, tool layer, orchestration logic, or the system prompt. Each prompt-layer entry should carry the compensating monitoring or review, which is the framework’s own condition rather than an auditor’s embellishment.

• A reversal that was actually performed

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    One case, end to end, with elapsed time and an honest statement of what remained un-restored once it completed. A capability nobody has exercised establishes that somebody believed it would work.

• A reversibility determination per action type, with the mechanism named

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    Not a rating. For each action: what the compensating action is, how long the window to execute it lasts, who executes it, and what it cannot restore. The last column changes tier assignments, and it is the one most schemes do not have.

• A tool manifest exported from the runtime

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    Not the architecture diagram and not the vendor’s feature list — what the agent can call today, pulled from running configuration and reconciled line by line against the approved catalogue. The exceptions are the finding.

• An action catalogue with a tier assigned per action

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    A row for each action the agent can take, rather than one classification for the agent, with the tier it lands in and the reason. Where the catalogue was written from the design document it lists capabilities nobody has exercised and omits whatever was added last month.

• An MCP server register with a trust decision and an enforcement point

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    Every server the agent can reach, who decided it was trusted, and whether an unlisted server can be reached at all. A register that no mechanism enforces is an inventory of intentions.

• Gate configuration exported from the running system

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    Reconciled line by line against the determination. Where the two disagree the running configuration is the fact, and the distance between design intent and deployed behaviour is the finding rather than the document.

• Negative test results — disallowed actions attempted

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront

    The OpenClaw guidance says to attempt disallowed actions to ensure restrictions work. The artefact is the attempt and its outcome, per restriction, dated against a release. A restriction nobody has tried to breach is an assertion about software.

• One reconstructed trajectory for a real incident

  One obligation

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

    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.

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

  One obligation

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

    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.

• Segregation evidence between execution and reachable systems

  One obligation

  • Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

    Where code executes, what that environment can reach on the network, and what it cannot. Sandboxing is recommended for code execution and is frequently asserted at the process level while the environment sits inside the corporate network.

• The downstream-obligation test, applied

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    The framework’s own limit is that modifications may not be easily reversed where they trigger downstream obligations, such as entering into a contract or sale. The artefact is the list of actions creating an obligation to a third party, drawn up by someone able to recognise one.

• The immutability control, tested

  One obligation

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

    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.

• The list of action types barred entirely, and who decided

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    Dated and attributed. Its absence is informative: either the organisation concluded that none of its agent’s actions is consequential enough to prohibit, or the question was never put to anyone able to answer it.

• Time-window and rate constraints on consequential actions

  One obligation

  • IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions

    The Terminal 3 case study sets a ceiling amount for the consolidated bank transfer, at base salary plus a buffer margin and explicitly declared before each run. A constraint of that kind bounds what a gate failure can cost, and it is testable in a way an approval step is not.