Agentic AI Governance in Singapore: Who Publishes What

If a Singapore file says agentic AI governance, whose document should you read first? For financial institutions, start with the MAS page titled MAS Guidelines for Artificial Intelligence (AI) Risk Management. That page says the proposed Guidelines apply to all financial institutions and set MAS supervisory expectations for AI risk management. Treat that as a scope answer, not as evidence that one agent was allowed to release money or change a record.

Agentic AI governance Singapore: scope before slogans

The phrase is too broad to be useful unless it is pinned to a document and an action. “Agentic AI governance Singapore” can mean a board paper, a risk taxonomy, a model review, an incident file, or a control that stops an agent before it changes a live system. Those are not interchangeable.

The MAS source is precise about its audience. It says the proposed Guidelines will apply to all financial institutions. It also says those Guidelines set supervisory expectations on oversight of AI risk management in financial institutions, key AI risk management systems, policies and procedures, key AI life cycle controls, and capabilities and capacity needed for the use of AI.

2 The proposed Guidelines will apply to all financial institutions (FIs) and set out MAS' supervisory expectations on oversight of AI risk management in FIs, key AI risk management systems, policies and procedures, key AI life cycle controls, as well as capabilities and capacity needed for the use of AI.

— MAS Guidelines for Artificial Intelligence (AI) Risk Management

That sentence does real work. It gives the compliance officer a boundary. If the file concerns a financial institution, the MAS page belongs in the pack. If the file concerns a supplier, a group entity, or a technology team supporting the institution, the question is still whether the institution can satisfy the supervisory expectation it owns.

It does not do more than that. The sentence does not say that every company in Singapore sits inside the proposed Guidelines. It does not say that a risk framework proves one attempted payment release was approved. It does not give an artefact for a disputed action. Those omissions matter because agentic systems create event-level questions.

A conventional AI-governance folder may contain acceptable material and still be poor incident evidence. It may show that a committee exists. It may show that an assessment was performed. It may show that a model was reviewed. None of that, by itself, answers the narrow question that arrives after the event: who or what permitted this agent to do this thing at this time?

For the financial-services lane, keep MAS Guidelines material close to the governance file and read it alongside Verifiable AI Compliance: Singapore Financial Services. The useful split is simple. One document helps define the supervisory frame. The other should help the team ask what proof remains after an action.

Model AI governance Singapore and the action gap

“Model AI governance Singapore” is often used when the real problem is not only the model. A model can recommend. An agent can act. The governance burden changes when the system can update a customer field, trigger an outbound message, or submit a transaction instruction.

The MAS page is not limited to a narrow model-performance lens. It names oversight of AI risk management, AI risk management systems, policies and procedures, AI life cycle controls, and capabilities and capacity needed for the use of AI. That wording is broader than a model-review checklist.

The distinction is not academic. A credit model may be reviewed for its intended use. A separate agent may later use a score, combine it with account context, and attempt to change a limit. The first review may be necessary. It is still not the same as evidence that the later action was permitted.

This is where teams should resist a comfortable shortcut. A model-control artefact can be treated as if it governs every downstream act. It may not. The action may involve a different system, a different permission, and a different consequence. The governance question moves from “was the model acceptable?” to “was this act authorised under the rules that applied then?”

That shift is uncomfortable for model owners because it dilutes ownership. It is also uncomfortable for engineers because it turns a design diagram into a control question. A diagram can show a path. It cannot, unless the system produces the right record, show the decision that allowed one attempted change.

There is a reasonable objection. Not every agent action deserves the same treatment. A low-impact draft, a harmless retrieval, and a live instruction to move funds should not be governed as if they were identical. MAS itself recognises that AI can be applied to a wide range of use cases and that risk may vary by scale, scope and business models.

The answer is not to make every event a board matter. The answer is to classify the action before arguing about the artefact. If the agent is only preparing a summary, the evidence burden may be modest. If it is changing a record that a customer, regulator, or auditor can later contest, a model file is too far upstream.

AI governance framework Singapore as a map of questions

An AI governance framework is useful only if it tells the team which question is being answered. Scope is one question. Risk variation is another. Action evidence is another. Collapsing them creates false comfort.

The MAS page gives a strong reminder that AI use cases do not carry one uniform risk profile. It says MAS recognises AI can be applied to a wide range of use cases and that the risks associated with different usage may vary based on scale, scope and business models.

3 MAS recognises that AI can be applied to a wide range of use cases, and that the risks associated with different usage of AI may vary based on the scale, scope and business models of FIs.

— MAS Guidelines for Artificial Intelligence (AI) Risk Management

That is a better starting point than a generic checklist. It forces the organisation to say what the agent does. It also forces the organisation to say where the risk changes. Reading, drafting, recommending, approving, and executing are different control moments.

The framework should therefore be a router, not a slogan. First, identify the document that applies to the organisation. Then identify the type of AI use. Then identify the action the system can take. Only after that should the team ask what evidence would survive an audit sample.

This is also where risk owners should be sceptical of neat governance diagrams. A diagram may name a committee and still omit the live permission step. A policy may say that certain actions require approval and still fail to record whether approval existed when the agent acted. A register may identify systems and still say nothing about a disputed event.

The point is not to dismiss frameworks. A framework without evidence is unfinished. A framework with no scope boundary is untestable. A framework that cannot distinguish a recommendation from an execution will over-control harmless work and under-control the thing that will later be investigated.

Threat material has its place, but it should not be mistaken for permission evidence. For a security-centred reading, use this agent authority failures note beside the governance file. It is a different question from the MAS scope question.

What this means if you have to produce evidence

The test is not whether the governance pack looks mature. The test is whether it can answer a hostile, narrow question. Why did the agent do this?

Start with the action, not the framework. A payment release, a deleted record, a changed limit, or a customer message each needs its own answer. The action is where accountability becomes concrete.

The MAS page supports the need to think about oversight, systems, policies, procedures, life cycle controls, capabilities and capacity. Those are governance categories. They are not automatically event records.

A compliance officer should therefore ask for two different artefacts. The first is the governance artefact that shows the organisation understood and managed the AI use. The second is the action artefact that shows the rule, decision, and outcome for the specific attempted act. If those two artefacts are the same document, the team should be able to explain how one document does both jobs.

Most weak files fail at the join. The policy says approval is needed for a class of action. The system log says an action happened. Nobody can show the decision that connected the two. The gap may not be visible in a design review, but it becomes obvious in an incident review.

Engineers should expect this to feel unfair. They may have implemented the workflow exactly as described. They may have retained ordinary application records. They may even be able to reconstruct the path after the event. Reconstruction is not the same as contemporaneous evidence.

The risk owner’s question is harsher. Could the organisation show, without relying on memory, that the agent’s authority existed when it acted? Could it show whether a human approval was required? Could it show whether the action was blocked, escalated, or allowed? Those answers should not depend on reading source code during an investigation.

This is where an AI governance framework becomes operational. It stops being a policy document and becomes a set of controls around particular acts. The valuable unit is not “the AI system” in the abstract. It is the attempted action and the decision attached to it.

Practical steps for the governance file

1. Fix the scope first. If the organisation is a financial institution, record that the MAS page says the proposed Guidelines apply to all financial institutions and set supervisory expectations for AI risk management.
2. Name the AI use. Do not write “agentic AI” as if it were a control. Write what the system can attempt: read, draft, recommend, approve, change, send, or submit.
3. Separate the model question from the action question. Keep model assessment material where it belongs, but do not let it stand in for proof that a particular action was authorised.
4. Classify the action by consequence. A harmless draft and a live record change should not require the same approval path. The classification should be visible before the action is attempted.
5. Attach a rule to the action. The file should show which policy or approval condition applied to the attempted act, not merely that a policy existed somewhere.
6. Record the decision outcome. The useful evidence says whether the act was allowed, blocked, escalated, or sent for human approval.
7. Keep the record readable. An incident reviewer should not need to infer authority from scattered logs, screenshots, and meeting notes.
8. Test the hostile case. Pick one attempted action and ask whether the evidence would satisfy someone who believes the action should not have happened.

The practical position is narrow: place a permission step before the action, and keep a tamper-evident record of the decision that follows. For teams comparing that pattern with their governance file, see GREENLIGHT and the product demonstration.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• MAS Guidelines — collected material for the financial-services governance lane.
• Verifiable AI Compliance: Singapore Financial Services — a deeper treatment of evidence in regulated financial workflows.
• Agent authority failures — a security-side view of agent authority failures.
• GREENLIGHT — the permission step for consequential agent actions.