Technical Controls and Processes

The Model AI Governance Framework (MGF) for Agentic AI of the Infocomm Media Development Authority (IMDA) of Singapore has four dimensions. Dimension 3 of the MGF is "Implement technical controls and processes" (MGF §2.3). The MGF is guidance with best practices, and it is not law. For more about the MGF, see The MGF for Agentic AI.

Controls for agents

The MGF (§2.3) gives organizations four measures for the lifecycle of an agent. It tells organizations that they "should consider" these measures:

• During design and development, make technical controls for the agent. "Depending on the agent design", use controls such as access controls. Use least-privilege access to tools and data to limit the effect of the agent on "the external environment".
• Before deployment, "test agents for safety and security".
• During deployment, "gradually roll out agents" and monitor them continuously in production.
• During the full lifecycle, use change management and version control. Set clear triggers that start a change review, and "categorise the needed changes accordingly".

An agent uses a model, instructions, and memory as a basic LLM-based application does, and it also has planning and reasoning, tools, and protocols (MGF §1.1.1). For all eight components, see Agent components.

The MGF (§2.3.1) recommends that organizations make technical controls for the agentic AI system to decrease the risks that they identified. Together with the "baseline software and LLM controls", the MGF tells organizations to "consider adding controls for" these areas:

• new agentic components, for example planning, reasoning, and tools
• "Increased security concerns from the larger attack surface and new protocols"
• multi-agent interactions.

The MGF gives the sample controls in the table below "for illustration". For a more complete set of controls, the MGF refers organizations to:

• the Draft Addendum on Securing Agentic AI of the Cyber Security Agency of Singapore (CSA)
• the Agentic Risk and Capability Framework of GovTech.

Component	Sample controls in the MGF (§2.3.1)
Planning	Tell the agent to "reflect on whether its plan adheres to user instructions". Tell the agent to "summarise its understanding and request clarification from the user before proceeding". Record the "plan and reasoning" of the agent "for the user to evaluate and verify".
Tools	Set tools to accept only "strict input formats". Apply least privilege to limit the tools of each agent, with "robust authentication and authorisation". For data tools, do not give the agent write access to tables in sensitive databases "unless strictly required". For data tools, set the agent to "let user take over control when keying in sensitive data", for example passwords or API keys.
Protocols	Use "standardised protocols where applicable", for example "agentic commerce protocols when agent is handling a financial transaction". For MCP servers, "Whitelist trusted servers and only allow agent to interact with servers on that whitelist". For MCP servers, sandbox all code execution.
Multi-agent interactions	Tell agents to send data to other agents through structured schemas, for example typed function calls, not through free text. This control decreases "unintended instructions passing between agents". Limit the access to shared memory between agents.

The MGF gives no set of controls for each multi-agent setup. For the multi-agent setups, see Multi-agent systems.

Structural controls

For organizations that select controls, the MGF (§2.3.1) compares rule-based safeguards with model-based safeguards and prompt-layer safeguards. It also identifies runtime controls.

"Rather than prompt-layer safeguards", the MGF tells organizations to "consider implementing deterministic safeguards that operate at a system-level through predefined logic, especially for higher-risk actions". For example, an access control at the tool layer can prevent all tool calls from the agent to that tool. The access control can also let the agent use the tool only "in a certain way", for example with read access only. Also, if an agent follows a set procedure, a workflow that contains that sequence is "more robust" than instructions to the agent only. Prompt-layer safeguards are frequently not the same for all users, but system-level safeguards can be the same for all users.

The MGF also gives a condition for model-based safeguards. Model-based safeguards "can be most effective" where a risk is "harder to define through fixed rules". The MGF gives this example: "to detect harmful content, which can manifest in different ways". For deterministic limits for agents, see Deterministic limits.

For runtime controls, the MGF tells organizations that agents operate with users and systems in real time. Thus, "static safeguards configured at design time may not be sufficient to catch every risk". Runtime controls decrease this problem "by monitoring and intervening during execution". The MGF gives two examples: "rate limits to prevent excessive tool use", and "input validation to catch harmful responses before they are acted upon".

MCP controls

For organizations that use the Model Context Protocol (MCP), the MGF (§2.3.1) gives this guidance: MCP "can potentially act as a governance layer".

MCP is between the agent and the enterprise systems that the agent accesses. It is the MGF example of a protocol for communication between agents and tools (MGF §1.1.1). For this protocol component, see Agent components.

Organizations "can consider defining controls on the MCP layer". The MGF gives these examples:

• "filtering sensitive data that passes through the servers"
• "logging all agent-to-system interactions"
• "whitelisting only trusted servers".

These controls are for organizations that use MCP. The MGF does not tell organizations to use MCP. It also does not recommend that organizations send all protocol communication through a governance layer.

Test agent workflows before deployment

The MGF (§2.3.2) recommends that organizations "test agents for safety and security before deployment". These tests help to show that the agents operate correctly and that the "controls are effective". The best practices for software testing and LLM testing stay applicable. Examples are unit testing and integration testing for software systems, and "representative datasets, and useful metrics and evaluators for LLM testing". The MGF also refers organizations to the Starter Kit for Testing of LLM-based Applications for Safety and Reliability.

The MGF also recommends that organizations adapt their testing for agents. It gives these six points:

• "Testing for new risks". Agents can give incorrect outputs, and they can also do "unsafe or unintended actions through tools". Organizations "can consider testing for" these four items:
  • "Overall task execution": if the agent can complete the task accurately.
  • "Policy compliance": if the agent follows the standard operating procedures (SOPs), and if it sends actions for human approval when necessary.
  • "Tool calling": if the agent uses the correct tools, with the correct permissions, with the correct inputs, and in the correct sequence.
  • "Robustness": the behavior of the agent when errors and edge cases occur.
• "Testing entire agent workflows". Agents can do many steps in sequence without human involvement. Thus, the MGF recommends tests across the full workflow, together with reasoning and tool calls, and not only tests of the last output.
• "Testing agents individually and together". See Test multi-agent systems.
• "Testing in real or realistic environments". The MGF recommends that "testing should occur in a properly configured execution environment that mirrors production as closely as possible". Examples are "tool integrations, external APIs, and sandboxes that behave as they would in deployment". The MGF also tells organizations that "organisations should calibrate the need for realism against the risk of prematurely allowing agents to access tools that affect the real world".
• "Testing repeatedly and across varied datasets". The MGF tells organizations that agent behavior is "inherently stochastic and context dependent". The MGF recommends tests "at scale and across varied datasets" to find "unexpected low-probability behaviours, especially if they are of high-impact". For these tests, it is necessary to make test datasets for the different conditions that agents can find. The MGF also recommends that organizations do the tests many times "to check for stability", "including minor perturbations where needed".
• "Evaluating test results at scale". The MGF tells organizations that "Reliably evaluating test results at scale is a known challenge for LLM testing". Agent workflows can also be long and contain data without structure. Organizations "may consider using different evaluation methods for different parts of the agentic workflow". An example is "deterministic tests for structured tool calls vs LLM or human evaluation for unstructured agent reasoning". The MGF adds that "there is still a need to evaluate agents holistically". It gives an example of "Current industry solutions": "defining LLMs or agents to evaluate other agents, while incorporating human-in-the-loop review".

Test multi-agent systems

For multi-agent systems, the MGF (§2.3.2) recommends tests of each agent and tests at the level of the multi-agent system. These tests help to find the emergent risks and behaviors when agents work together. Examples are "competitive behaviours", and "the impact on other agents when one agent has been compromised". In §1.2.3, the MGF tells organizations that agents that work together "can cause emergent behaviours that cannot be predicted from testing each agent individually". For these risks, see Systemic and multi-agent risks.

Deployment and monitoring

The MGF (§2.3.3) tells organizations that pre-deployment testing "establishes a useful baseline but needs to be complemented by continuous monitoring and testing during deployment". Agents adapt to real-time conditions, and their behavior can change. The MGF adds: "For multi-agent systems especially, failure modes such as miscoordination or emergent behaviours may only manifest through agent behaviour over time and under realistic conditions." The MGF gives guidance in three areas: "Gradual deployment of agents", "Continuous testing and monitoring", and "Robust change management". For change management, see Change management.

Deployment in steps

The MGF (§2.3.3) recommends that organizations "consider gradually rolling out agents into production to control the amount of risk exposure". An organization can select these items for each deployment step:

• the users of agents, for example "rolling out to trained or experienced users first"
• the tools and protocols of agents, for example "restricting agents to more secure, whitelisted MCP servers first"
• the systems that agents can access, for example "using agents in lower-risk internal systems first".

The MGF gives a GovTech case study as an example. GovTech put "agentic coding assistants" into use in steps. In the first step, only GovTech personnel used them, without access to MCP servers, and only on low-risk systems. During the first step, GovTech prepared controls for the next step. Examples are "central logging and monitoring", and "a path for developers to connect to whitelisted MCP servers from a containerized sandbox". These selections apply to that case study only, and the MGF does not recommend them for all organizations.

Monitoring and logs

The MGF (§2.3.3) recommends that organizations "continuously monitor and log agent behaviour post-deployment". It also recommends "reporting and failsafe mechanisms" for "agent failures or unexpected behaviours". With these measures, the organization can do these tasks:

• "real-time intervention". When the organization finds "potential failures", it stops the agent workflow and sends the problem to a human supervisor. An example is an agent that "attempts unauthorised access".
• Debugging after incidents. Logs and tracing of each step of an agent workflow, and of the communication between agents, "help to identify points of failure".
• Audits at regular intervals, to make sure that the system is "performing as expected".

Agents do many actions "at machine speed", and monitoring systems make large quantities of logs. Thus, it is hard to get "meaningful insights" from these logs. This problem increases when the organization wants to find high-risk anomalies in real time.

To identify the data to record, the MGF recommends that organizations "determine their objectives for monitoring". Examples are "real-time intervention", debugging, and "integration between components". The MGF also recommends that organizations "prioritise monitoring for high-risk activities such as updating database records or financial transactions".

The MGF (§2.3.3) also recommends that organizations "continuously test the agentic system even post-deployment". These tests make sure that the system "works as expected and is not affected by model drift or other changes in the environment".

In §2.2.2, the MGF also recommends that "human oversight should be complemented with automated real-time monitoring". See Human oversight.

Alert thresholds and human review

For the monitoring of logs, the MGF (§2.3.3) tells organizations that they "can consider implementing these practices":

• Monitor on more than one layer, for example the "user-agent interaction", "agent-tool invocation", and "model reasoning" layers. This helps to identify "specific sources of failure".
• Set alert thresholds of three types:
  • "Programmatic, threshold-based" alerts, for example when an agent "attempts unauthorised access or makes too many repeated tool calls within a specified timeframe".
  • "Outlier / anomaly detection", which uses "data science or deep learning techniques" to find "anomalous behaviour that may indicate malfunctions".
  • "Agents monitoring other agents" in real time, which find "anomalies or inconsistencies".
• For each "alert type", "consider what the level of intervention should be".
• Use human review or human-in-the-loop review. The MGF tells organizations that "Some degree of human review or human-in-the-loop is useful to detect any emergent behaviours that may not have been previously accounted for".
• Connect agent monitoring to "existing observability and debugging platforms", "including standards like OpenTelemetry for tracing".
• Use log immutability and feedback loops. See Log immutability and feedback loops.

For each "alert type", the MGF tells organizations to "consider what the level of intervention should be". The MGF recommends some human review, in proportion to the risk level. It gives these examples:

• "lower-priority alerts can be flagged for review at a scheduled time"
• "higher-priority ones might require temporarily halting agent execution until a human reviewer can assess"
• "In the event of catastrophic agentic malfunction or compromise, commensurate measures such as termination and fallback solutions should be considered".

Log immutability and feedback loops

Organizations "can consider" log immutability (MGF §2.3.3). The MGF tells organizations to "Maintain complete audit trails by ensuring that problematic agent trajectories and failures cannot be deleted, preserving them for analysis and compliance purposes."

Organizations "can consider" feedback loops. The MGF tells organizations to "feed monitoring insights back into training datasets and evaluation frameworks for continuous improvement".

Change management

The MGF (§2.3.3) tells organizations this: "As an agentic system becomes more complex, small modifications can cascade into larger impact." As a safeguard, the MGF gives organizations two measures to "consider":

• Triggers that start a change review. The MGF gives these examples:
  • "technical triggers": "model updates, tool modifications"
  • "environmental triggers": "domain shifts, business context changes"
  • "performance triggers": "anomalous behaviour, degraded performance"
  • "regulatory triggers": "changes in compliance requirements".
• "Categorising review changes by risk", as the table below shows.

Type of change	Example in the MGF	Review in the MGF
"Minor changes"	"prompt refinements"	"may follow lighter review processes"
"Material changes"	"model updates or autonomy adjustments"	"may require a full governance review"
"Critical changes"	"affecting high-stakes decisions"	"may mandate an immediate re-risk assessment"

The MGF (§2) recommends that organizations "re-evaluate the earlier dimensions" after anomalies during "implementation or monitoring", "re-assessing and further bounding the risks if needed".

Use the framework in Modulos

In Modulos, MFF-17 is the Framework for the Singapore MGF for Agentic AI at the AI System level. OFF-17 is the Framework at the Organization level. For the Requirements that apply to §2.3, see the Requirement table. The Requirement MRF-317 applies only when the system has more than one agent. Make this decision before development and testing, as the Modulos steps show.

Related information

• The MGF for Agentic AI: the four dimensions and the status of the MGF. Its section Related guidance gives the status of other Singapore guidance, for example the CSA addendum "Securing Agentic AI" of June 2026 and SAFR from MAS.
• Risk assessment and limits on agents: Dimension 1 of the MGF, with residual risk.
• Human accountability and human oversight: Dimension 2 of the MGF, with the agent value chain, red teaming, and threat modeling.
• FAQ about the MGF for Agentic AI.

Sources

• IMDA, Model AI Governance Framework for Agentic AI, Version 1.5, "Published 20 May 2026", "Updated 5 June 2026". PDF. Provisions: §1.1.1 (agent components), §1.2.3 (systemic and multi-agent risks), §2 (page 13), §2.2.2 (automated monitoring), §2.3 (page 33), §2.3.1 (pages 33–34), §2.3.2 (pages 38–39), and §2.3.3 (pages 42–45, with the GovTech case study).

Disclaimer

This page gives general information. It is not legal advice.