MAS published its Guidelines on Artificial Intelligence Risk Management for Financial Institutions on 7 October 2026. The Guidelines set out MAS’ expectations for how financial institutions should identify, assess and manage risks arising from their use of AI.
Security testing is one part of this framework. The Guidelines refer to vulnerability assessments, AI penetration testing and red teaming of AI systems, with the depth of testing depending on the risks associated with the AI use case.
For financial institutions in Singapore, this raises some practical questions: What does MAS expect from AI red teaming? How is AI red teaming different from traditional penetration testing? When should organisations test an AI system, and what evidence should they keep?
This guide explains the MAS AI red teaming expectations, the relevant guideline sections, testing approaches, evidence to maintain and practical considerations for financial institutions.
Need help assessing an AI system against the relevant MAS security expectations? Qualysec can help scope AI penetration testing and red-team assessments based on your AI environment and risk profile.
What do the MAS AI Red Teaming Requirements entail?
The MAS AI Red Teaming Requirements are guidelines, not a notice, and are to be considered by all stakeholders. They are applied proportionately to the testing depth, as in Paragraph 2.1, based on the level of risk that their AI systems present. This testing text is in paragraph 5.22(b). It directs companies to “perform vulnerability assessments, penetration testing and ‘red teaming’ of AI systems.” The same sub-paragraph points that work at manipulation, evasion and poisoning, and pairs it with input validation and anomaly detection.
The way in which the testing is done is influenced by three neighbouring paragraphs.
Which of the Guidelines apply and when?
The MAS AI Red Teaming Requirements programme has two dates. Paragraph 1.8 sets the dates: Sections 3 and 4 will be met on 7 October 2027, and Sections 5 and 6 on 7 October 2028. The split is shown in Table 1.
| Section | Topic | Applies from | Testing relevance |
| 3 to 4 | Governance, AI inventory, materiality | 7 October 2027 | Decides what is in scope and how deep tests go (paras 4.5 to 4.13) |
| 5 | Lifecycle controls | 7 October 2028 | Adversarial testing (5.14(b)), independent validation (5.19), third-party AI (5.10, 5.11), security testing (5.22(b)) |
| 6 | Capabilities | 7 October 2028 | Links AI to technology risk practice (para 6.3) |
Paragraphs 4.5 to 4.13 come first, as a test can only cover a system the firm knows about. Rate each AI use by impact, complexity and reliance. That rating then guides the testers on their efforts.
So how do the Guidelines relate to the MAS TRM Guidelines?
Paragraph 5.16 carries a footnote to the Technology Risk Management Guidelines, and paragraph 6.3 links the two. The AI document is not intended to supersede the current practice. It is a layer that is placed on top. It is included in Table 2 next to the MAS TRM Guidelines and the binding notices.
| Instrument | Binding? | Testing content |
| AI Risk Management Guidelines (7 October 2026) | Guidelines, applied proportionately | The sections of the document outline the various types of tests conducted as part of this program: 5.14(b) adversarial testing; 5.19 independent validation; and 5.22(b) penetration testing and red teaming. |
| Technology Risk Management Guidelines (January 2021) | Guidelines | Sections 13.1.2, 13.2, 13.3 and 13.6.1 cover vulnerability assessment, black and grey box testing, scenario-based cyber exercises and remediation respectively. |
| TRM notices: FSM-N05 (banks), FSM-N13 (payment) and FSM-N21 (capital markets) | Notices under the Financial Services and Markets Act 2022 (FSMA), in force since 10 May 2024 | Operational duties; FSM-N13 doesn’t mention penetration testing. |
| MAS circular on incident reporting | Effective 1 February 2026 | This is the MAS-Tx template to be used for reporting; the timeframe is determined by the relevant instrument. |
There is no frequency of testing provided in the MAS TRM Guidelines, and hence the AI file should document the firm’s own reasoned frequency. There’s one more development to watch. A Waystone update in July 2026 states that MAS consulted on revised TRM notices, feedback closed on 31 July 2026, and there will be a 12-month transition once they are finalised.
AI Red Teaming vs AI Penetration Testing: What Is the Difference?
Red teaming involves probing the question of whether the model can be persuaded to behave badly. AI Penetration testing is asking whether the plumbing around the model can be hacked. The first deals with prompt injection, jailbreaks, data leakage and poisoning. The second is related to API authorisation, cloud configuration and plugin permissions.
Both are mentioned in paragraph 5.22(b) for a good reason. A model can withstand any adversarial prompt, but still be serving a different customer’s data behind an API. That is why one method alone leaves gaps. This is the same split as highlighted in the OWASP Top 10 for LLM Applications. It includes prompt injection, together with sensitive information disclosure, data and model poisoning, and excessive agency.
| AI Red Teaming | AI Penetration Testing |
| AI behaviour and adversarial scenarios | Technical security of the AI environment |
| Prompt injection, jailbreaks, poisoning, data leakage | API security, authentication, access control, cloud configuration |
| Can the AI system be manipulated into unsafe behaviour? | Can an attacker compromise the surrounding technical environment? |
| Model, prompts, behaviour, data and workflows | APIs, infrastructure, authentication, permissions and integrations |
| Identify AI-specific attack paths | Identify exploitable technical weaknesses |
How to Test an AI System Component-wise?
For MAS AI Red Teaming Requirements, run one loop for each component. State the use case & assess its materiality level. Write down the usual behaviour as a baseline first, then alter an input and see if you can create a second pathway to the same output. Take a snapshot and then retest once the fix has been applied.
Prompts and Guardrails
Attempts at direct injection or jailbreak go against the system prompt and the filter that is in place for protection of the system. Pass condition is: No policy bypass, no disclosure of the system prompt. Evidence is the complete prompt and response log with times. Manipulation is at the top of the list in paragraph 5.22(b).
Data and Retrieval Pipelines
An instruction is embedded in a document or email that the model picks up from a source. Next, a typical business query is posed. The model passes if it considers the text obtained from the database, and no output is generated outside the scope of the model. Evidence is in the form of retrieval logs and final output.
Model APIs and Authentication
Endpoints are called using another user’s token, modified object identifiers and oversized requests. Authorisation must hold, and rate limits must trigger. Request and response captures show whether they do. The benchmark, as outlined in paragraph 5.16, is role-based access and MFA.
Agents and Tool Permissions
An agent is given a task whose shortest route includes a permission it shouldn’t use. The right answer is a refusal or a pass to somebody else. Tool-call traces show which. OWASP identifies this as too much agency, and agents with write access are at the greatest risk.
Third-Party AI Services
Paragraphs 5.10 and 5.11 call for third-party AI to be tested in context, and the firm holds accountability. That’s not a vendor’s report, though. Do keep the results of the in-context test on file.
Monitoring and Shutdown Controls
Paragraph 5.22(b) mentions anomaly detection. The test therefore verifies that the system responds to malicious input and sends the alert to a named person. It also verifies that the organisation can turn off the use case. The proof is in the alert records and response times.
Does the scale of testing need to match risk materiality?
The Guidelines use the word “proportional” and a materiality rating based on impact, complexity and reliance, but they do not specify test depth.
Table 3 is a proposed model from Qualysec, NOT from the MAS text.
| Tier | Example use | Test depth | Independence | Retest trigger |
| High | Credit decisioning, customer-facing agent with transaction rights. | Complete Red Teaming and AI Penetration testing of all components | Outside the build team (para 5.19) | All material changes, plus a schedule set by the firm. |
| Medium | Internal assistant that can use confidential information. | Red teaming and API testing focused on specific areas of interest. | Second line of defence | Changes to the model, data or prompt |
| Low | Drafting tool without customer information. | Baseline adversarial prompts, access review | Build team with peer review | Version changes |
Case Study: Documented AI Vulnerability
The vulnerability, dubbed EchoLeak, was uncovered by Aim Security as part of its research into Microsoft 365 Copilot. It had a CVSS severity of 9.3 (critical). As put by Microsoft: “An unauthorised attacker can share information over a network using AI command injection in M365 Copilot.” The fix came in the June 2025 Patch Tuesday, says The Hacker News. Customers did not need to take any action, and the security team detected no malicious use of the service.
It is useful because of the mechanism. An attacker emails an employee’s Outlook Inbox with a seemingly benign e-mail. The employee later asks Copilot a business question, like a synopsis of an earnings report. Copilot’s retrieval engine combines the untrusted email with the sensitive information into the model’s context, and the model exposes this data in the Teams and SharePoint URLs. The attack requires no click. Aim Security called the class of flaw “LLM Scope Violation.”
The case was not related to a MAS-regulated firm. However, retrieval of a combination of trusted and untrusted content is the same architecture that any copilot with mailbox access uses. Here’s how it maps.
- The relevant paragraphs are 5.22(b), on manipulation and input validation, and 5.16, on the environment.
- It’s a test that seeds a message in a mailbox, runs normal tests and monitors outgoing links and requests for data in URLs.
- Pass condition: The system treats retrieved content as data and does not deliver any content to an external address.
- Key evidence: retrieval trace, model output and network log.
Discuss retrieval and agent workflows with Qualysec’s security experts before they go into production!
What should the Evidence for MAS AI Security Testing Include?
An examiner assessing the MAS AI Red Teaming Requirements reads artefacts, not intentions. Each finding requires an ID, the AI use case, the materiality tier and the guideline paragraph. It also requires the component, technique, preconditions and steps. The organisation should complete the remainder of the record with the expected (target) behaviour, evidence, severity of the behaviour, remediation owner, and retest status.
Reproducible steps are most important. An organisation can achieve independent validation under paragraph 5.19 only when someone outside the build team can repeat the test and obtain the same result.
How Qualysec can help financial institutions.
Qualysec has separate services for the AI layer, as well as for the systems that are surrounding it. Qualysec breaks each engagement into six stages—scope definition, information gathering, enumeration, attack and penetration, reporting, and remediation testing.
AI Penetration Testing for LLM Applications
Qualysec’s LLM penetration testing service includes chatbots, copilots, RAG document systems, AI agents and code assistants. Qualysec can conduct engagements in black, grey, or white box mode. Test areas are based on OWASP Top 10 for LLM Applications – prompt injection, disclosure of sensitive information, data poisoning, model poisoning, and excess agency. Reports include severity ratings, PoC demonstrations and a letter of attestation.
Around AI Systems: API, Cloud & Infrastructure Testing
The model is just one aspect. The interfaces are addressed by Qualysec’s AI API security service. It has a broader scope of work, as described on its MAS TRM penetration testing page, including web, API, cloud, network and mobile testing. Qualysec’s service pages indicate that the normal assessment takes 1-3 weeks and complex agentic setups take 4-6 weeks.
Retesting and Guideline-Mapped Reporting
Finally, fixes are verified rather than assumed in the remediation testing phase of each engagement. Qualysec maps its findings to the OWASP Top 10 for LLM Applications.
Conclusion
The MAS AI Red Teaming Requirements mention red teaming in only one sub-paragraph. Inventory, materiality, independence and secure environments reside around that line; so, think of the test as part of a larger job. The governance is due on 7 October 2027, and lifecycle testing is due on 7 October 2028. Anyone building AI red teaming that Singapore regulators will accept should start with the inventory, because every later test depends on it.
FAQs (Frequently Asked Questions)
What Are MAS AI Red Teaming Requirements?
MAS AI Risk Management Guidelines include vulnerability assessment, AI penetration testing and red teaming as part of security testing for AI systems. The testing approach should be proportionate to the risks associated with the AI use case. Financial institutions should also consider AI inventory, materiality, independent validation, third-party AI risks and evidence of testing and remediation.
Does MAS require AI red teaming?
MAS’ AI Risk Management Guidelines include vulnerability assessment, AI penetration testing and red teaming as part of the security testing expectations for AI systems. The approach is risk-proportionate, so the scope and depth of testing should reflect the risks associated with the AI use case.
When will the MAS AI Guidelines become effective?
The dates are the thing to nail on your wall when it comes to MAS’ AI Guidelines, which came out on 7 October 2026. There are two deadlines provided in paragraph 1.8. Sections 3 and 4, on goveexpected to be met by 7 October 2027. rnance, inventory and materiality, are Lifecycle controls and capabilities follow on 7 October 2028 (Sections 5 and 6). Where do you start? With the AI inventory. There’s no way to rate a model that no one has listed.
Are there any exceptions to the Guidelines for any financial institution?
Paragraph 1.2 applies them on a group basis to locally incorporated financial institutions under consolidated MAS supervision and to owners of critical information infrastructure. Paragraph 2.1 then applies them proportionately. The scope paragraphs do not extend beyond those groups: firms outside them must confirm their position with their MAS supervisor or legal adviser.
What is the difference between AI red teaming and penetration testing?
Red teaming looks to attack the behaviour of the model. Consider prompt injection, jailbreaks, data leakage and poisoning. Penetration testing expands to the entire system: the APIs, the authentication, the cloud configuration and all the permissions your tools might have.
One assesses what the model can do, while the other assesses what an attacker can access. Sub-paragraph 5.22(b) mentions both types of tests, and each focuses on a different aspect of security. For instance, even if an AI model won’t respond to any malicious prompts, there might well be an API that leaks out customer records. Therefore, programmes frequently require both of these strategies.
Is third-party AI required to be tested?
Financial institutions should assess third-party AI as part of their AI risk-management process. MAS expects FIs to remain accountable for AI used in the services they deliver, including AI provided by third parties. FIs should obtain appropriate assurance, assess whether the third-party AI is suitable for its intended use and apply additional controls where assurance gaps exist.
How frequently do you need to test AI systems?
Paragraph 5.22(b) does not specify an interval, so MAS AI security testing should follow materiality. For high-materiality systems, organisations should conduct testing whenever they change the model, data, or prompts and establish and document a testing schedule. Lower materiality uses can follow version changes. The organisation needs to document the reasoning in the AI inventory record so that an examiner can locate it there.
