The MAS Technology Risk Management Guidelines apply to AI agents as they apply to any technology a financial institution runs. Agents need board-level governance, privileged access controls on their identities, change management over their instructions and model versions, resilience plans for when an agent or its model provider fails, and monitoring that can spot abnormal agent behaviour quickly.
What do the TRM Guidelines require?
The TRM Guidelines set MAS's expectations for managing technology risk. In substance they cover:
- Governance: the board and senior management oversee technology risk; a technology risk management framework with clear roles.
- Risk management: identifying, assessing and treating technology risks, including those from new technologies.
- IT project management and security-by-design: security built into systems from the start.
- Software development and change management: controlled development, testing, release and change, with segregation of duties.
- IT service management and resilience: availability, recovery objectives, business continuity and testing of recovery.
- Access control: least privilege, strong authentication, management of privileged access, regular reviews.
- Data and infrastructure security: protection of data at rest, in transit and in use.
- Cyber security operations and assessment: monitoring, threat intelligence, incident response, penetration testing.
- Third-party risk: due diligence and oversight of service providers, alongside MAS's outsourcing expectations.
They are guidelines, but MAS assesses institutions against them, and they sit alongside binding notices on technology risk and cyber hygiene.
Who do they apply to?
Financial institutions regulated by MAS: banks, insurers, capital markets intermediaries, payment service providers and others. Agent platform vendors are not directly subject, but they are pulled in through the institution's third-party and outsourcing obligations.
What do the guidelines mean when the system is an agent that acts?
Four areas need specific thinking.
Access control: agents are privileged users. An agent that can read customer records across the institution and write to core systems has privileges that, held by a person, would trigger privileged access controls. Apply the same: unique identity, least privilege per capability, short-lived credentials, logging of every use, regular review.
Change management: instructions are code. The TRM expectation that changes are tested and approved before release applies to the agent's brief, its data sources, its permissions and the model version underneath. An edit in a vendor console that changes what an agent does is an unauthorised change if it bypassed the process.
Resilience: the model provider is a dependency. If the model provider is unavailable or changes behaviour, the agent stops or degrades. Business continuity needs a fall-back: people take over, or another model is qualified in advance. Recovery objectives should reflect which services depend on the agent.
Monitoring: abnormal behaviour looks different. An agent under attack or malfunctioning may read far more records than usual, attempt actions outside its scope or produce unusual volumes of output. Monitoring should alert on these signals, and refused actions are useful early warnings. A sudden rise in refusals for one agent often means something upstream has changed.
How do you meet the guidelines?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Board and senior management oversight | Agent use and risk reported; accountable executive named | Board papers; accountability map |
| Technology risk assessment | Agents assessed for new risks, including manipulation and excessive permissions | Risk register entries |
| Security-by-design | Agent permissions and sources defined before build | Design records; versioned briefs |
| Change management | Brief, source, permission and model changes tested and approved | Change tickets; test results |
| Segregation of duties | People who write agent instructions cannot approve their own changes | Approval records |
| Access control and privileged access | Unique agent identities; least privilege; reviews | Identity register; access reviews |
| Resilience and recovery | Fall-back plans for agent and model provider failure; tested | Continuity tests |
| Monitoring and incident response | Alerts on abnormal agent activity; incidents handled under existing process | Alerts; incident records |
| Cyber security testing | Adversarial testing of agents, including injected instructions | Test reports |
| Third-party risk | Platform and model provider assessed and contracted | Due diligence; contracts |
Governance principles on fairness and accountability sit in FEAT, not TRM; see MAS FEAT principles applied to AI agents. The two should be run together. For the shorter answer to how FEAT reaches agents, see how MAS FEAT principles apply to AI agents.
What will MAS ask?
- Which services depend on agents, and what are their recovery objectives?
- How are changes to agent instructions controlled, and who approves them?
- How are agent identities and privileges managed?
- What happens if the model provider is unavailable for a day?
- How would you detect an agent behaving abnormally?
- Has the platform been assessed under your outsourcing framework?
What do the guidelines not cover?
They do not address fairness, ethics or explainability of decisions. They do not prescribe AI-specific tests. They do not replace data protection law. Wider risk management for AI can draw on ISO/IEC 23894 AI risk management for AI agents or the NIST AI Risk Management Framework; our explainer on what AI risk management is covers the basics. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme separates the model from the governance. Qualification changes an agent's brief, sources, bounds and certification, all versioned, so a change is visible and reviewable. Because governance does not depend on one model provider, a second model can be qualified through Attest in advance as a resilience fall-back, and every verdict, including refusals, is filed in an append-only record for monitoring.
Questions people ask
Is an agent platform outsourcing under MAS rules?
Often, if it supports a service the institution would otherwise perform itself and is material. Assess it under MAS's outsourcing expectations as well as TRM.
Should agent instruction changes go through the same change board as code?
They should follow a change process with testing and approval proportionate to risk. Low-risk wording changes can use a lighter path, but changes to permissions or actions need full control.
Do the TRM Guidelines require explaining agent decisions?
No. Explanation is a FEAT and data protection matter. TRM focuses on the security, reliability and resilience of the technology.