Singapore MAS FEAT AI Compliance Checklist: 8 Runtime Checks

A payment agent proposes a S$40,000 transfer. The time is 02:14. Before any instruction reaches the execution system, the production test should show the agent's registered identity and delegated authority, followed by the policy decision and final disposition. This Singapore MAS FEAT AI compliance checklist turns that moment into eight gradable checks. It uses MAS's 2026 Safeguards for Agentic Finance at Runtime (SAFR) paper as an industry reference, alongside MAS's stated supervisory direction for financial institutions. Each check returns pass or out of scope. An open action receives remediate.

TL;DR

• Grade eight checks against a named agentic use case. Record the owner and test date, then add an evidence link and remediation state for each result.
• Treat SAFR as an industry reference approach rather than binding guidance. MAS's proposed AI Risk Management Guidelines remain the broader supervisory source.
• Test identity and bounded authority on production-representative traffic. Exercise pre-execution disposition and human escalation, then inspect the decision record.
• Give an HTTP gateway credit only for user or agent traffic deliberately routed to an LLM endpoint. Execution systems need their own owners, as do model validation and board oversight.

Check 1: establish the source and applicability record

Owner: compliance with legal and the accountable AI risk owner.

Pass condition: the applicability record cites MAS's 5 August 2026 parliamentary reply and the SAFR publication dated 3 July 2026. It states that MAS's proposed AI Risk Management Guidelines apply across financial-institution AI use cases, including agentic AI, while labelling SAFR accurately as an industry reference approach, with no claim that the paper itself creates regulatory guidance or supervisory expectations.

Evidence: approved applicability memo and source register, plus the in-scope entity list and use-case decision.

Remediate when: the workbook calls SAFR a binding MAS rule or presents a future finalisation date. Also remediate when it turns the search phrase "FEAT checklist" into a statutory title.

Check 2: bind every proposed action to a registered agent

Owner: IAM and AI platform engineering.

Pass condition: each proposed action carries an agent identifier that resolves to the authoritative registry for that operating context. The registry entry identifies the owner and approved use, and it supplies status and credentials together with the applicable mandate reference. An unknown identity receives rejection before further evaluation. So do disabled and mismatched identities.

Evidence: registry record and identity-binding design, plus one accepted test and one rejection event. Preserve the lookup source and result. A shared service credential without the originating agent leaves the accountability chain incomplete.

Remediate when: the log names only payments-orchestrator-prod, while several agents and business purposes use that principal. The post-authentication gap explains why a valid session still needs action-level authorisation.

Check 3: encode delegated authority as machine-readable limits

Owner: the business principal with compliance and policy engineering.

Pass condition: the mandate states permitted action types and defined thresholds, including the validity period, escalation conditions, and authority that can amend or revoke it. The agent cannot extend these bounds through its own reasoning. Test both sides of the limit. An action below it proceeds to evaluation; another above it receives the configured restrictive disposition.

Evidence: approved mandate schema and current policy version, plus test inputs and resulting events. Confirm revocation works without relying on the model's explanation.

Remediate when: authority is expressed as assist with treasury operations, or a permanent credential silently supplies wider permission. I would fail vague delegation before reviewing model quality. Elegant reasoning cannot repair missing authority.

Check 4: require a governance envelope before execution

Owner: agent engineering with the action-system owner.

Pass condition: every in-scope action arrives at the governance checkpoint with its proposed action and parameters. The envelope also holds the action trace and relevant context metadata, including identity and mandate, while completeness and coherence checks run before execution. The design treats agent-declared content as a claim that needs origin authentication.

Evidence: versioned envelope schema and validation rules, plus an accepted envelope and a rejected malformed example. Preserve a sample showing the tools called and data retrieved.

Remediate when: the agent sends only a natural-language summary, or the action trace is reconstructed after settlement. An internally consistent envelope can still misstate the original instruction. The origin binding belongs in the test.

Check 5: produce a binding disposition before the action runs

Owner: policy engineering with the relevant product-control owner.

Pass condition: the runtime decision resolves every proposed action to a defined outcome before execution. SAFR describes Deny; Escalate; Auto-Execute; and Observe. The institution configures thresholds using factors suited to the action, such as reversibility and financial materiality, while preserving the specific rule and rationale. Prior approval for one step carries no authority into the next step of an adaptive workflow.

Evidence: disposition policy and expected-result matrix, plus timestamped events for each configured outcome. Include a sequence test in which the second action receives a fresh evaluation. The MAS SAFR runtime authorisation record provides the narrower architecture behind this checkpoint.

Remediate when: review happens after an agent submitted the transfer, or an earlier Auto-Execute result becomes a reusable permission token.

Check 6: make human escalation executable

Owner: operations risk with the named human decision function.

Pass condition: an Escalate result holds the proposed action before execution and sends a decision package to an authorised reviewer. The package includes the proposed action and supporting trace, names the triggered rule and deadline, and presents the available outcomes. Timeout behavior is written into the workflow. The final human decision returns to the same action flow and enters the record.

Evidence: escalation contract and reviewer role mapping, plus a timed exercise and the resulting decision event. Look at the screen. The reviewer should see the S$40,000 amount and breached limit without opening six tabs or asking the agent to explain itself again.

Remediate when: escalation means an email sent while the action continues, or the reviewer can approve outside the recorded workflow. Human oversight has substance only when it can change execution.

Check 7: write the authoritative decision record

Owner: records engineering with compliance and security.

Pass condition: every governance outcome creates a tamper-evident, append-only entry at the decision point. The entry carries the submitted envelope and mandate reference while preserving the outcome, rules applied, rationale, and timing. The agent and downstream action system lack modification rights. A reviewer can reconstruct every configured outcome without relying on the agent's later account.

Evidence: event schema and access model, plus integrity verification and retrieval results. Preserve retention approval and a rejected identity event.

Remediate when: the application writes a success log after execution or administrators can overwrite entries without detection. Decision reasons stored only in a transient dashboard also need remediation. This check defines the operating record; audit sampling and evidence packaging belong in a separate audit-evidence exercise.

Check 8: test the routed HTTP slice and assign the rest

Owner: security engineering for the policy route, with separate owners for the agent and execution environment.

Pass condition: production-representative tests trace authenticated user or agent -> HTTP policy point -> approved LLM endpoint. They cover valid identity and missing identity, plus approved and denied destinations. Include restricted prompt content and response handling. The event records the application-supplied principal and model route, along with the policy version, disposition, and a correlation identifier.

Evidence: route inventory and diagram, test plan and expected results, plus request-level records and bypass findings. Use AI model inventory management to reconcile approved endpoints with observed routes.

Remediate when: the application can call the provider directly or the policy point sees only a relay identity. A vendor's opaque embedded model needs separate treatment. DeepInspect evidence covers the routed HTTP interaction with the LLM, while payment settlement and local model execution remain with their actual control owners. The same applies to bypassing tool calls, board oversight, model validation, and customer-outcome review.

Singapore MAS FEAT AI compliance checklist grading rules

Run the eight checks against one named workflow rather than against an enterprise AI programme in the abstract. A pass needs current evidence and a reproducible test. Use out of scope only with a written reason and approving owner. Every other result is remediate, with containment and a target date.

This checklist focuses tightly on execution decisions. It tells a control owner what to run before an agent acts and what result closes the item. A controls mapping would connect each MAS statement to institutional control objectives, while an audit-evidence guide would focus on sample populations, custody, and reviewer independence. Combining those jobs produces a giant workbook. It looks impressive in a committee meeting and becomes awkward at the exact moment a payment agent proposes an action.

DeepInspect

DeepInspect sits inline between authenticated users or agents and HTTP-based LLM endpoints deliberately routed through the policy point. It evaluates application-supplied identity and workflow context against versioned content and destination policy before forwarding the request. The response passes through the same boundary. Each decision creates a signed, tamper-evident event containing the policy version and timestamp.

That event can support the routed portions of Checks 2, 5, 7, and 8. The institution remains responsible for agent registration and mandate approval, as well as governance-envelope integrity, human decision design, and retention. Execution-system controls and model validation remain institution-owned, along with senior-management oversight. Direct browser sessions and local inference need separate controls. So do agent tool calls that never cross the inspected user or agent-to-LLM HTTP path. Book a technical deep dive at deepinspect.ai.