← Blog

Singapore MAS AI Controls Mapping: Owners for Agentic Finance

Parminder Singh
Parminder Singh··7 min read
Summarize with AI

This Singapore MAS AI controls mapping assigns the proposed AI risk management and SAFR runtime outcomes to accountable owners. Each row connects a source position to an objective, operational control point, test, evidence contribution and open gap, while keeping an HTTP policy gateway inside its actual boundary.

Industry Verticalsai-complianceai-governanceagentic-airegulationpolicy-enforcementaudit
Singapore MAS AI Controls Mapping: Owners for Agentic Finance

A useful Singapore MAS FEAT AI controls mapping starts with the person who can change the control. The board owns risk appetite. Model risk owns validation. An application team supplies identity and purpose. Security engineering owns the HTTP policy point. Put all four under one green box marked MAS covered and the map becomes decoration. I would reject that map before the meeting starts.

TL;DR

  • Treat the proposed MAS Guidelines and the SAFR paper according to their stated status, then map each outcome to a named owner.
  • Give the business owner authority scope, security engineering the runtime policy point, and records management the retention design.
  • Credit an HTTP gateway only for routed user or agent traffic to an LLM. Board oversight, model validation, downstream execution and enterprise retention sit elsewhere.
  • Keep every Partial verdict open until the missing owner completes a defined closure test.

Singapore MAS FEAT AI controls mapping starts with source status

MAS addressed agentic AI in an August 2026 written parliamentary reply. The reply places AI agents inside the proposed Guidelines on Artificial Intelligence Risk Management for financial institutions. Those Guidelines remained proposed when MAS published the reply, so a control map should describe them as forthcoming supervisory expectations rather than binding rules already in force.

The companion Safeguards for Agentic Finance at Runtime paper has a narrower job. SAFR frames runtime safeguards around authorization, assessment before execution, and records that support review, accountability and remediation. MAS also states that the framework carries no regulatory guidance or supervisory expectation. That status belongs in the source column.

A mapping should therefore separate source status and implementation judgment. For each row, record the source outcome and control objective. Name the accountable owner and operating team. Then add the control point, test, evidence contribution, coverage verdict and unresolved gap. Product names belong after those fields.

Enterprise AI governance belongs to the board and CRO

Source outcome and objective: place agentic AI inside the institution's AI risk management framework, with senior accountability and risk decisions proportionate to the use case.

Owner and control point: the board approves risk appetite. The CRO owns the framework and reports exposure. Business leadership sponsors each agentic use case, while compliance interprets the MAS position for the institution. The operative control points include use-case approval, risk acceptance and periodic management review.

Test and evidence contribution: select one production agent and trace its approval to the current inventory entry, risk tier, named executive sponsor and accepted operating limits. Confirm that a material scope change returned to approval. The useful artifacts include the decision record, meeting minutes, inventory history and assigned remediation.

Coverage verdict: Outside an HTTP gateway. A routed request record can show activity under an approved policy version, which supports review, but it cannot approve risk appetite or prove board oversight. The enterprise AI governance guide covers that programme layer. This row stays open when the inventory and live route list disagree.

Agent authority belongs to the business and IAM

Source outcome and objective: define what an AI agent may do for a specific principal, purpose and data context before the agent proposes a model-mediated action.

Owner and control point: the business owner defines permitted actions and financial limits. IAM owns principal proofing, role lifecycle and delegated access. The application owner supplies the originating user or agent identity, purpose and session context with each routed LLM call. Security engineering translates approved bounds into request policy.

Test and evidence contribution: use a synthetic relationship-manager identity to request an allowed client summary through the approved model route. Change the client segment or destination to one outside the delegated scope and expect a denial. Remove the originating identity and expect restrictive handling. Retain the entitlement snapshot, policy version, request decision and correlation identifier.

Coverage verdict: Partial. An HTTP policy point can evaluate application-supplied context on routed LLM traffic. It depends on truthful identity and purpose inputs, and it cannot govern a bank transfer executed later through a separate API. The agent post-authentication gap explains why a standing service credential leaves this row incomplete.

Runtime assessment belongs to security engineering

Source outcome and objective: assess a proposed agent action at runtime before the relevant LLM request proceeds, applying the institution's policy to the actual caller, content and destination.

Owner and control point: security engineering owns the inline policy service and restrictive failure behavior. AI platform engineering owns route integration and model endpoint registration. Data governance supplies classification rules. The business owner defines which outcomes require human review instead of an automated permit or block.

Test and evidence contribution: send declared synthetic account data through an approved application at 10:14 SGT. The first request uses an allowed model and purpose. A second points to an unapproved endpoint, while a third triggers an evaluator timeout. Confirm the expected outcome for each case and retain policy latency, destination, classification, decision and escalation reference.

Coverage verdict: Full only for policy evaluation on authenticated HTTP traffic that actually traverses the control. Direct browser sessions, local inference and opaque vendor-managed calls remain outside. So do tool executions after the LLM response. A diagram with one bright green gateway box can hide those gaps; the route register must list them in black and white.

Model assurance belongs to model risk management

Source outcome and objective: understand the model's limitations and assess the risks created by the institution's agent design before production use and after material change.

Owner and control point: model risk management owns the validation standard and challenge. The model owner maintains design records and evaluation results. Compliance contributes conduct obligations, while the business owner sets acceptance criteria tied to the financial process.

Test and evidence contribution: inspect one approved model-agent combination. Confirm that its evaluation covers the declared use, foreseeable misuse, human-review condition and change threshold. Introduce a material model or prompt-policy change and verify that the institution invokes the prescribed review. Preserve the validation report, limitations, approval and remediation record.

Coverage verdict: Outside the gateway, with a limited evidence contribution. A policy point can pin an approved model route and record which destination received a request. It cannot establish model accuracy, fairness, stability or suitability. Calling destination control a model validation control would inflate a narrow runtime mechanism into an assurance programme.

Runtime records have several owners

Source outcome and objective: retain records that let the institution review a consequential event, assign accountability and remediate an outcome that diverged from intent.

Owner and control point: security engineering owns creation of the runtime decision event. The application owner preserves workflow context and downstream outcome. Records management determines classification, retention and retrieval. Legal and compliance set hold and production requirements. Internal audit tests the joins and custody arrangements.

Test and evidence contribution: choose one disputed agent interaction and reconstruct the originating principal, requested model action, destination, content classification, governing policy and runtime outcome. Join that event to any human escalation and downstream financial workflow. Verify integrity, retrieval and authorized access. A per-decision record supports the row only when the institution can connect it to the case under review.

Coverage verdict: Partial. An external HTTP policy point can create independent evidence for the traffic it sees. Enterprise retention, legal hold and downstream transaction records require other systems. The tamper-evident AI audit log guide provides the custody test, but the MAS control owner still decides how the event enters the official record schedule.

Control owners must close route and evidence gaps

A control map earns its place when each owner can rerun the assigned test. Record the covered applications and model routes, required inputs, expected result, evidence location, last test date and open exception. Use Partial when one component works and another owner still owes a dependency. Use Outside where the mechanism sits beyond the mapped architecture.

My blunt view is that a single institutional coverage percentage should stay out of the board pack. 94% mapped can conceal the one wealth-management agent that reaches an LLM through a vendor-managed browser session. Show that route as an open gap with an owner, interim restriction and closure date. The red line is more useful than the percentage.

Keep shared evidence from blurring accountability. The same runtime event may support security review, records production and an internal audit sample. Each control retains its own objective and owner, plus a separate pass condition. A missing join between the model event and downstream transaction should appear as a failed join, rather than inheriting a pass from the gateway row.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. It evaluates application-supplied identity and context, classifies request content, applies destination and policy rules, inspects the response, and writes a signed, tamper-evident decision record.

In this mapping, DeepInspect contributes to agent-authority enforcement, pre-execution assessment and runtime event creation for routed LLM traffic. The institution still owns identity proofing and route completeness, board governance, model assurance, downstream action controls, retention classification and supervisory judgment. That boundary keeps the map usable when an auditor selects one agent interaction and asks each owner for the record under their control. Book a technical deep dive at deepinspect.ai.

Frequently asked questions

Does SAFR create a binding MAS requirement?

MAS presents SAFR as a framework for industry consideration and states that it carries no regulatory guidance or supervisory expectations. Record that status explicitly. A financial institution may still use the paper as a design reference for authorization, pre-execution assessment and review records.

Who owns an agent's authority limit?

The business owner defines permitted actions and financial bounds. IAM manages principal and delegated-access state. The application supplies that context at call time, and security engineering enforces the resulting policy on routed LLM traffic. Each contribution needs its own test.

Can one gateway close the full MAS AI governance map?

A gateway closes only bounded runtime components for authenticated HTTP traffic that passes through it. Board oversight, use-case approval, model validation, vendor governance, downstream transaction control and institution-wide retention remain assigned to their respective owners.

What makes a Partial verdict useful?

A useful Partial verdict names the functioning component and the missing dependency. It also identifies the owner, interim treatment, target date and closure test. For runtime records, the gateway event may exist while the join to a financial transaction remains unresolved.

Where should human review appear?

Human review belongs at the business decision point named by the use case. Runtime policy can route a request to escalation and preserve that outcome. The qualified reviewer, review standard and final financial decision remain controlled by the institution's workflow.