MAS AI risk management guidelines: what they mean for AI agents
What Singapore’s MAS AI guidelines mean for teams using agents: understanding their work, assessing risks and choosing where people need to review actions.
The decision in brief
For teams using agents, a useful starting point is one familiar workflow: describe its purpose, the information it uses, the actions it can take and who is responsible. Then choose checks and review that fit the consequences of a mistake.
What MAS issued and when it takes effect
On 7 October 2026, the Monetary Authority of Singapore (MAS) issued its Guidelines on Artificial Intelligence Risk Management. They set out supervisory expectations for financial institutions using AI, including agents.
The guidelines take effect on 7 October 2027. Institutions may implement them in phases: Sections 3 and 4, covering oversight and risk management, from that date; Sections 5 and 6, covering life cycle controls and capabilities, by 7 October 2028.
For security and platform teams, the practical question is how those expectations relate to the agents already being introduced at work.
Start with the work the AI is doing
MAS asks institutions to identify their AI use, maintain an inventory, assess risks and apply controls suited to those risks. The inventory covers AI use cases, systems or models. A list of connected tools can help, but the wider picture includes what the AI is for, its owner, its data and its dependencies.
The guidelines use the term risk materiality: how much harm a failure or mistake could cause. That assessment informs the level of testing, monitoring and human oversight needed. Institutions also remain accountable when AI is supplied by a third party.
What changes when an agent can take action?
An assistant that drafts a reply gives someone text to review. An agent that can send the reply also needs access to a system and permission to act. Understanding that difference helps a team decide what the agent can do on its own and where review would be useful.
Some agents connect to workplace tools through the Model Context Protocol (MCP). An MCP server exposes operations such as finding a ticket or updating a record. Each request gives the team a specific action to examine: who requested it, which system it reaches and what information or change is involved.
Our reading is that reviewing these requests can support the broader governance work. It provides a place to apply access rules and, where needed, review an action before it happens. It does not replace the institution’s assessment of the whole AI use case.
An example: an agent helping with customer support
Consider an illustrative support agent that summarises tickets and drafts replies. Giving it access to customer records or letting it send a reply changes the questions the team needs to answer.
The support owner and security team could work through the following choices together. These are examples for discussion, rather than MAS-prescribed controls or built-in Durin settings.
- Record the workflow’s purpose, owner and systems in the institution’s AI inventory.
- Keep the risk assessment and agreed checks alongside that record.
- Try both expected actions and requests the agent should be unable to carry out.
| Agent task | Possible risk | One approach | Useful evidence |
|---|---|---|---|
| Summarise public help articles | Outdated or incorrect advice | Check answers against current documentation | Example answers and test results |
| Read customer records | Exposure of private information | Limit access to the records needed for the task | Access settings and tests of refused requests |
| Send a customer reply | Incorrect content or recipient | Review messages where the consequences warrant it | Review decisions and delivery results |
Match review to what could go wrong
The example shows why reading information can deserve as much care as changing it. A customer record may contain sensitive data even when the agent never edits the record. Sending a routine acknowledgement and changing a customer’s account details also have different consequences.
Requiring someone to review every small action can make the process harder to use and the important requests harder to spot. MAS’s human-oversight guidance considers decision fatigue as well as the need for people to intervene. Review works best when its purpose, responsible person and scope are clear.
A team can start with one workflow, test its boundaries and use what it learns to decide whether to expand access. The wider governance program still includes ownership, testing, monitoring and assurance about the systems involved.
Where Durin fits
Durin helps teams govern agent requests routed through its MCP gateway. It checks access and the team’s rules before a request can go ahead, and records the decision and the result. Requests made through other routes need their own controls.
Reviewed requests can proceed by default after the required access checks. Teams can choose stricter rules, including requiring another administrator to review proposed changes. When that review is needed, the administrator approves the exact request; the requester then sends it again before the permission expires. Approval alone does not perform the action.
These records can help a team understand what an agent requested and what happened next. They support part of a wider AI governance program; they do not establish compliance on their own.
Sources and further reading
The MAS documents below explain the expectations and implementation dates. The support example and suggested starting point are our interpretation of how a team could approach agent use.