Singapore MAS AI Audit Evidence for Agentic Finance
Singapore MAS AI audit evidence for agentic finance should preserve three linked artifacts: an authorization decision record, proof that a defined human oversight trigger fired and reached an accountable reviewer, and a consequential decision record tied to the business outcome. This article turns the SAFR framing into a practical evidence package for authenticated HTTP traffic between financial-institution users or agents and LLM endpoints.

At 09:17 SGT, an operations agent proposes sending a customer's disputed-payment history to an LLM before drafting a case summary. The compliance reviewer sees a red queue badge six minutes later. During an audit, the firm must show the authorization decision made before transmission, the event that activated human oversight, and the record of the consequential decision that followed. Singapore MAS AI audit evidence becomes credible when those three records join through one stable correlation ID.
TL;DR
- MAS describes SAFR through authorization and activated human oversight, with records made at consequential decisions.
- Preserve each authorization evaluation as a dated, identity-bound decision record.
- Prove that an oversight trigger fired, entered a queue, reached an accountable reviewer, and received a disposition.
- Join the consequential decision record to the resulting business action, while keeping the HTTP control boundary explicit.
The MAS source sets three evidence questions
On 5 August 2026, the Monetary Authority of Singapore answered a parliamentary question on agentic AI in financial services. MAS Chairman Gan Kim Yong said the proposed Guidelines on Artificial Intelligence Risk Management apply to every AI use case at financial institutions, including agentic AI. MAS had published those proposed Guidelines for consultation in November 2025 and said they would be finalised soon.
The reply describes Safeguards for Agentic Finance at Runtime, or SAFR, as a potential approach to three runtime matters. The first is how agent actions are authorized. Human oversight activation is the second. SAFR also asks what gets recorded at every consequential decision. The SAFR publication page, dated 3 July 2026, uses the same structure and says the financial industry developed the framework under MAS' BuildFin.ai initiative.
That framing gives an audit team three evidence requirements. The package identifies the authority that permitted the proposed action. It preserves the condition that sent the action to a person. A final join connects the machine decision to its consequence. MAS calls SAFR a potential approach, so the package below is an implementation pattern rather than a claim about a prescribed MAS format.
Freeze the population before selecting evidence
Start the review period with a frozen population of agent-to-LLM HTTP requests. Preserve the extraction query and UTC time, the row count, the schema version, and a content hash. Record who performed the export. A reviewer should be able to select an item from the population instead of receiving examples selected by the control owner.
Reconcile that population against records outside the AI policy gateway. API management or application egress data should account for requests sent by in-scope applications. Provider usage should align with approved endpoints. Deployment records should explain every policy version observed during the period. IAM records should identify the principals or service identities attached to the calls.
Differences belong in the evidence package. A provider event absent from the routed population can indicate bypass. A shared service identity may prove the technical caller while leaving the originating employee or agent unresolved. The post-authentication gap appears when authentication succeeds but the request lacks enough context for a per-action authorization decision.
My view is blunt: a polished evidence binder built from handpicked successes deserves to be sent back. The denominator matters more than the cover page.
Artifact one: the authorization decision record
For each selected call, preserve the decision made before the request reached the LLM. The record should identify the authenticated user or agent supplied by the application and the proposed action. It should name the intended model endpoint. Include the applicable policy version and decision outcome, followed by the timestamp and correlation ID used across systems.
The authorization record needs the context that determined scope. For the 09:17 disputed-payment request, that might include the user's operations role and the case workflow, with the content classification applied to the customer history. If the application supplied only a shared credential, state that limitation in the record. A gateway can evaluate only the identity and business context it receives.
Preserve the rule or policy reference in force at decision time. A current screenshot proves today's configuration and says little about the rule applied on 5 August. Historical policy retrieval should reproduce the decision inputs and show who approved the version. AI audit log chain of custody covers the custody controls needed when exports move into an examination workroom.
Artifact two: human oversight trigger evidence
MAS uses the phrase "how human oversight is activated." An evidence package should therefore show the trigger as an operating event rather than a policy paragraph. Define each trigger before testing it. Examples can include restricted data, an unapproved destination, a high-impact workflow, or uncertainty that requires escalation under the institution's policy.
For a selected escalation, retain the triggering condition and the policy version that evaluated it. Show the event timestamp and queue destination. Identify when the assigned reviewer received it. Preserve the reviewer's authority and disposition, followed by any expiry or reauthorization condition. If a service-level target applies, calculate elapsed time from the machine event to the recorded human action and keep the source timestamps.
The 09:17 scene should be reconstructable without opening a slide deck. The event row shows the restricted classification. The queue receipt carries the same correlation ID. At 09:23, a named compliance reviewer denies the proposed route and records a reason. The application then receives the controlled outcome. That sequence proves activation and handling. A list of committee members proves neither.
Test the path under controlled failure as well. Remove required identity context or use an expired approval in a non-production environment. Record the expected escalation before the test, then retain the raw result and any defect ticket. A dated retest should close the loop.
Artifact three: the consequential decision record
A consequential decision record joins the runtime evaluation to the action that affected a customer, account, transaction, or regulated process. Keep the LLM request reference and destination, plus the policy outcome. Add the response reference and the application's handling of that response. Then connect the event to the financial institution's own business record, such as a case disposition, payment hold, advice approval, or investigation outcome.
This distinction prevents a gateway log from being presented as the whole audit story. HTTP evidence can show that an authenticated agent sent classified content to an approved LLM route under policy version 12. The business system must show how staff used the response and who approved the customer-facing result. Model-risk and compliance records, together with operations records, supply conclusions that traffic telemetry cannot.
Use data minimization without breaking reconstructability. A protected source location and a content fingerprint may reduce duplication of customer information in the evidence store. Document the normalization method, access approval, retention rule, and integrity test. Tamper-evident audit logs for AI explains the separate write path and verification pattern. Legal and records owners should approve the retained content for the relevant Singapore financial activity.
Assemble the package for reviewer selection
Build one control-to-evidence index for the MAS SAFR review. Each row should name the control owner and evidence owner. It should point to the source system, frozen population, retention rule, latest test, and open issue. Keep source exports beside the query definitions that produced them.
Give the reviewer the population manifest and data dictionary first. Preserve the selection method. A practical set includes a permitted call and an escalation, along with a denied request and one event under a changed policy. When the period contains a customer-impacting event, include it. For each item, follow the same correlation ID through the authorization record and oversight event, then into response handling and the consequential business record.
Test four properties explicitly: population completeness, historical retrieval, custody, and integrity. Record expected results before testing. Keep raw output and the tester's identity. Open an issue for each deviation and retain the original due date, remediation evidence, independent retest, and closure authority.
The package should also state coverage. It covers authenticated user or agent traffic routed over HTTP to an LLM through the selected enforcement point. Local inference and direct browser sessions on another route need records from their actual control owners, as do model calls hidden inside a vendor service. That boundary makes the evidence more defensible.
DeepInspect
DeepInspect sits on authenticated HTTP traffic between financial-institution users or agents and LLM endpoints. It evaluates application-supplied identity and workflow context against content and destination policy before the request proceeds. Each evaluation writes a signed, tamper-evident decision record with the active policy version, timestamp, route, classification, and outcome.
Those records can support the authorization population and the machine-side evidence for a human oversight trigger. Stable correlation IDs can connect them to application-owned review and consequential business records. The institution remains responsible for identity proofing, model governance, human decisions, route-completeness testing, and retention. Vendor-controlled calls and local inference require separate evidence. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does MAS prescribe these exact three record formats?
The cited MAS sources describe SAFR through authorization, human oversight activation, and recording at consequential decisions. They call it a potential approach. They do not prescribe the field list or evidence-package format presented here. Institutions should map their implementation to final MAS Guidelines, applicable notices, internal policy, and the risk of each use case.
- Is an agent activity log enough for a SAFR review?
An activity log can contribute timestamps and action descriptions. The reviewer still needs the authorization context and historical policy decision, plus evidence that any human trigger operated. A consequential outcome also needs a join into the institution's business process. Keep the agent's own log as one source, then reconcile it with independent route and business records.
- Who should select the evidence samples?
An independent review function or supervisor should select items from the frozen population. Control owners can explain the workflow and investigate differences. They should preserve failed samples and the original denominator, along with the selection method. This arrangement limits management curation and lets a reviewer follow an event without advance preparation by the development team.
- Can a gateway prove that human oversight was effective?
A gateway can prove that a routed HTTP request produced an escalation under a specific policy and reached the configured queue. Effectiveness also depends on the institution's records showing reviewer competence and timely disposition, followed by the resulting business action. Those records sit with compliance, operations, or another assigned function.