Operationalizing the MGF for Agentic AI in Modulos

This page is the practical rollout playbook for the IMDA Model AI Governance Framework for Agentic AI (v1.5) in Modulos. It assumes the reader is already oriented on the framework itself — the four dimensions, the agentic risk taxonomy, and the action-space-versus-autonomy classification (see the framework overview) — and walks through the OFF-17 and MFF-17 framework templates, the recommended project structure, how the four dimensions map to the thirteen requirements, the two-band control library, and the readiness-plus-attestation evidence loop.

The MGF for Agentic AI is voluntary best-practice guidance from IMDA, not a law or a mandatory standard. The Modulos templates label MFF-17 and OFF-17 with the platform tag Regulation, but that is a template-catalogue artefact and not a legal characterisation; treat the framework as a non-binding governance framework throughout, in the same way the NIST AI RMF templates are treated.

Recommended project structure (OFF-17 org + MFF-17 per app)

Most rollouts use the following structure:

• One organisation project with the OFF-17 framework template attached. This holds the tenant-wide governance that is set once and reused across every agent: value-chain and internal responsibility allocation, the agentic risk-assessment and change-management methodology, the central agent catalogue, and integrating-user training and manual-fallback competence.
• One AI-application project per agentic AI system with the MFF-17 framework template attached. Each application project holds the per-agent build-and-operate evidence: the suitability decision and risk classification for that agent, the bounds on its authority, its oversight design, the technical controls applied to its components, its pre-deployment testing, its gradual-rollout and monitoring evidence, its disclosure surface, and its red-team and third-party-component assessments.

OFF-17 carries four requirements (ORF-389 to ORF-392) and 22 unique mapped controls. MFF-17 carries nine requirements (MRF-311 to MRF-319) and 49 unique mapped controls. The two templates are designed to operate together — several application requirements reference an organisation-side companion rather than restating it (see How org-locus and app-locus obligations connect).

Primary source

IMDA, Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), Infocomm Media Development Authority, Singapore. The framework is organised around four dimensions applied as an iterative loop: (1) assess and bound the risks upfront; (2) make humans meaningfully accountable; (3) implement technical controls and processes; (4) enable end-user responsibility.

The four dimensions mapped to requirements

The framework's four dimensions are an iterative loop, not a one-time waterfall: an anomaly detected in monitoring (Dimension 3) can re-open the risk assessment (Dimension 1). The thirteen requirements distribute across the dimensions as follows.

Dimension	What it covers	App requirements (MFF-17)	Org requirements (OFF-17)
1 — Assess and bound the risks upfront	Suitability decision, action-space × autonomy classification, impact × likelihood scoring, bounding authority by design	MRF-311 (suitability and risk context), MRF-312 (bound agent authority by design)	ORF-390 (risk and change-management methodology), ORF-391 (central agent catalogue)
2 — Make humans meaningfully accountable	Value-chain and internal responsibility allocation, meaningful human oversight, red-teaming, third-party assessment	MRF-313 (meaningful human oversight), MRF-319 (red-team and third-party assessment)	ORF-389 (value-chain and internal responsibilities)
3 — Implement technical controls and processes	Dev-time controls for agentic components, pre-deployment testing, gradual deployment and monitoring, change management	MRF-314 (dev-time technical controls), MRF-315 (test agent workflows and multi-agent behaviour), MRF-316 (deploy gradually, monitor, manage change)	—
4 — Enable end-user responsibility	Disclosure at the point of interaction, integrating-user training, manual-fallback competence	MRF-318 (disclose identity, authority, data use, escalation)	ORF-392 (train integrating users, preserve tradecraft)
Cross-cutting — multi-agent	The multi-agent lens over the other dimensions	MRF-317 (govern multi-agent and cross-system interactions)	—

MRF-317 is conditional: it applies only when the system runs more than one agent. A single-agent deployment marks MRF-317 not applicable. Where it is in scope, it does not introduce a fresh dimension — it governs as a system the multi-agent facets of risks the framework also touches at single-agent level in suitability (MRF-311), technical controls (MRF-314), and testing (MRF-315).

Where in Modulos (requirements, controls, evidence, runtime)

The Modulos surfaces relevant to MGF rollout are:

Surface	Use
Project dashboard Add Framework	Attach OFF-17 to the organisation project; attach MFF-17 to each agentic-application project
Project → Settings → Frameworks	Manage attached frameworks — list, freeze, and update
Project → Requirements	Track the OFF-17 / MFF-17 requirements; status Not fulfilled → Fulfilled, with Out of scope for inapplicable duties such as MRF-317 on a single-agent system
Project → Controls	Document implemented measures — the action-space-and-autonomy classification, the risk-cell rubric, tool-invocation policy gates, oversight-effectiveness metrics, the agent catalogue — and map them to requirements; control status changes are routed through review requests
Project → Evidence	Store supporting artefacts (classification and suitability records, threat-modelling and taint-tracing artefacts, red-team reports, override-rate and response-time metrics, disclosure copy, training records) and link them to controls
Comments and logs on each requirement	Capture the rationale for fulfilment attestation, scoping and not-applicable decisions, and residual-risk acceptance

The runtime surface is where the operating-model evidence for an agent in production is observed (see the runtime operating model below in Related pages); monitoring, logging, and anomaly-detection controls under MRF-316 are evidenced there.

A sequence that works

A pragmatic rollout sequence follows the iterative loop, organisation-side groundwork first, then per-agent:

1. Allocate responsibility and establish the methodology (org). Fulfil ORF-389 (value-chain and internal RACI, contracts with external parties) and ORF-390 (the documented agentic risk-assessment and change-management methodology, including threat-modelling techniques such as taint tracing and overseer competence). Stand up the central agent catalogue under ORF-391.
2. Assess and bound each agent (app, Dimension 1). For each agentic application, fulfil MRF-311 — run the suitability gate, classify each workflow action class on action-space and autonomy, and score impact and likelihood — then MRF-312 to bound the agent's authority by design (least-privilege, deterministic limits preferred over prompt instructions, emergency revocation).
3. Design oversight (app, Dimension 2). Fulfil MRF-313 — define approval checkpoints for high-stakes, irreversible, outlier, and user-defined actions, and put anti-rubber-stamping and automation-bias measures in place (override-rate and response-time metrics via the oversight-effectiveness control).
4. Build and test (app, Dimension 3). Fulfil MRF-314 (technical controls for the agentic components), then MRF-315 (test agent workflows and, where applicable, multi-agent behaviour before deployment).
5. Deploy and monitor (app, Dimension 3). Fulfil MRF-316 — gradual rollout, continuous monitoring with immutable logs and alert thresholds, and agentic change management. Where more than one agent runs, fulfil MRF-317; otherwise mark it not applicable.
6. Enable users (Dimension 4). Fulfil MRF-318 (disclose the agent's identity, authority, data use, and escalation path at the point of interaction) and, on the organisation side, ORF-392 (train the users who integrate agents into their work and preserve manual-fallback competence).
7. Red-team and reassess (app, Dimension 2). Fulfil MRF-319 (red-team the agent and assess third-party components), and feed findings back into the risk assessment — closing the iterative loop.

Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfilment.

How the agentic control library is organised (baseline vs agentic-specific)

The MGF templates pair two bands of controls, and keeping them distinct is what makes cross-framework reuse clean.

Baseline shared library. These are control objects reused by other Modulos framework templates. On the application side they include risk tiering (MCF-16), risk management at inception (MCF-23), transparency for users (MCF-47), human override (MCF-131), advanced model evaluation (MCF-205), input and output filtering (MCF-330), least-privilege access (MCF-331), human approval for high-risk actions (MCF-332), adversarial testing (MCF-334), rate limiting (MCF-400), sandboxing (MCF-403), and the logging, monitoring, application-security, and change-management controls MCF-308, MCF-309, MCF-319, and MCF-325. On the organisation side they include the governance, competence, risk, change, supplier, and incident-governance controls OCF-1 to OCF-3, OCF-44, OCF-95/OCF-97, OCF-103/OCF-130, OCF-109/OCF-110/OCF-111, OCF-131, and OCF-249/OCF-251/OCF-259, among others. Several of these — MCF-308, MCF-309, MCF-319, MCF-325, and a number of the OCF controls — carry an Agnostic tag, meaning evidence recorded once serves every framework that maps them.

Agentic-specific block. These controls exist for the agentic problem space and are the substance the framework's recommendations add over a plain generative-AI application:

Control	Name
MCF-517	Intent binding and drift detection
MCF-518	Tool invocation policy gate
MCF-519	Agent identities and delegation controls
MCF-520	Attested registries and signed descriptors
MCF-521	Emergency revocation and quarantine
MCF-522	Secure inter-agent communication and discovery
MCF-523	Safe code execution pipeline
MCF-524	Memory governance and rollback
MCF-525	Blast-radius limits and circuit breakers
MCF-526	Trust-aware approval UX
MCF-545	Action-space and autonomy classification
MCF-546	Agentic risk-cell rubric (impact × likelihood)
MCF-547	Agent suitability gate
MCF-548	Oversight effectiveness metrics
MCF-549	Multi-agent system testing
MCF-550	Agent capability and escalation disclosure
MCF-551	Agent workflow testing and staged rollout
MCF-552	Agentic threat modelling
MCF-553	Third-party agent component transparency
OCF-297	Human tradecraft continuity
OCF-298	Central agent catalogue and identity reconciliation
OCF-299	Agentic oversight and user training

Risk scoping for this framework runs entirely through the classification cluster — MCF-545 (action-space and autonomy, including the multi-agent topology dimension), MCF-546 (the impact × likelihood rubric), and MCF-547 (the suitability gate) — and not through any tag filter. None of the thirteen MGF requirements carries a Singapore-specific classification tag.

How org-locus and app-locus obligations connect

The org/app split is deliberate, and a small number of obligations are routed across the two templates so they are documented on one side only:

• Risk methodology (O-007). MRF-311 (app) references the organisational risk-assessment methodology, including agentic threat modelling such as taint tracing. That obligation lives on the organisation side at ORF-390, not on MRF-311. The application requirement consumes the methodology; the organisation requirement maintains it.
• Central agent catalogue (O-014). MRF-312 (app) references per-agent identity and delegation. The central agent catalogue that prevents agent sprawl lives on the organisation side at ORF-391, which maps one-to-one to the single control OCF-298 — the only one-to-one requirement-to-control mapping in OFF-17.

The rule is that tenant-wide governance set once belongs on OFF-17, while per-application execution belongs on MFF-17. Do not duplicate either obligation on both sides; the application requirement points to its organisation-side companion in its requirement detail.

Evidencing requirements: readiness signal + owner-attested fulfilment

Requirements in Modulos use a two-step pattern, not a review:

• when all linked controls are in a final state, the requirement becomes ready for review — a signal to the requirement owner;
• the requirement owner attests fulfilment by marking the requirement Fulfilled, with rationale captured in the requirement's comments and logs.

Review requests in Modulos apply to control status changes (and other reviewable objects such as assets) — not to the requirements themselves. A requirement can be marked Out of scope with rationale; MRF-317 on a single-agent deployment is the canonical example. Remediation loops attach to the controls and evidence under a requirement, and the residual-risk acceptance recorded under MRF-311 is itself an attested artefact.

Common pitfalls

• Treating the platform Regulation tag as a legal status. The MGF for Agentic AI is voluntary IMDA guidance. The Regulation label on MFF-17 / OFF-17 is a template-catalogue artefact; do not present it as a legal obligation.
• Looking for a Singapore scoping tag. There is none. Scope each agent through the action-space-and-autonomy classification and the impact × likelihood rubric under MRF-311 (controls MCF-545/MCF-546/MCF-547), not through a tag filter.
• Duplicating the methodology or catalogue on the app side. The risk methodology lives on ORF-390 and the catalogue on ORF-391. MRF-311 and MRF-312 reference them rather than restating them.
• Marking MRF-317 fulfilled on a single-agent system. It is conditional — mark it not applicable unless more than one agent runs.
• Confusing AI literacy with tradecraft continuity. ORF-392 covers two distinct things: training users who integrate agents into their work, and preserving the manual fallback skill they would need if the agent were unavailable. Evidence both.
• Using reviews to sign off requirements. Requirements are evidenced by readiness plus owner attestation; reviews are for control status changes.

Related pages

MGF for Agentic AI overview

The four dimensions, scope, and the MFF-17 / OFF-17 split

Dimension 1: Assess and bound the risks

Suitability, classification, bounding authority — MRF-311 / MRF-312

Dimension 2: Human accountability

Responsibility allocation, oversight, red-teaming — MRF-313 / MRF-319 / ORF-389

Dimension 3: Technical controls

Build, test, deploy, govern multi-agent — MRF-314 to MRF-317

Dimension 4: End-user responsibility

Disclosure, training, tradecraft continuity — MRF-318 / ORF-392

Operating model

How projects, requirements, controls, and evidence fit together

Controls in Modulos

Execute, review, and map controls across frameworks

Runtime operating model

Where in-production agent monitoring evidence is observed

Source attribution

The Model AI Governance Framework for Agentic AI, v1.5 (published 20 May 2026, updated 5 June 2026), is issued by the Infocomm Media Development Authority (IMDA), Singapore, as a living document building on the Model AI Governance Framework (2020, 2nd Ed). This page describes how Modulos maps the framework's recommendations to platform surfaces through the MFF-17 and OFF-17 framework templates; the recommendations themselves are in the IMDA publication. Worked examples named in the framework are illustrative of practice, not framework requirements.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The IMDA Model AI Governance Framework for Agentic AI is voluntary best-practice guidance, not a law or a mandatory standard; the Regulation tag on the Modulos templates is a catalogue artefact, not a legal characterisation. For authoritative interpretation, consult the published IMDA framework and qualified advisers.