Audience: AI engineering teams, compliance officers, and governance leads deploying agentic AI systems in Singapore, ASEAN, or for organizations subject to IMDA guidance. Also relevant for MAS-regulated financial institutions using AI agents.
IMDA MGF for Agentic AI v1.5 published May 20, 2026. Voluntary framework, but referenced by MAS (Monetary Authority of Singapore) and sectoral regulators. Over 60 organizations contributed to v1.5, including Tencent, Google, AWS, DBS, OCBC, PwC, GovTech, and Workday. This is the world's first government-issued governance framework specifically designed for AI agents that plan, call tools, and act over multiple steps.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
1. What the IMDA Framework Requires
The IMDA Model AI Governance Framework for Agentic AI (MGF) is a 51-page practical guide that addresses AI systems capable of autonomous planning, reasoning, tool calling, and multi-step execution. Unlike high-level principle documents, the MGF provides specific governance requirements across four dimensions.
The Four Dimensions
| Dimension | Focus | Key Requirements |
|---|---|---|
| D1: Risk Assessment | Assess and bound risks upfront | Impact analysis (domain, data access, external systems, reversibility). Likelihood assessment (autonomy level, complexity, exposure to external inputs). Tiered risk approach. |
| D2: Human Accountability | Make humans meaningfully accountable | Clear ownership chains for agent actions. Escalation mechanisms. Meaningful oversight (not rubber-stamp approval). Automation bias mitigation. |
| D3: Technical Controls | Implement controls and processes | Structural, rule-based, and prompt-layer controls. Tool access governance. Logging and monitoring. Multi-agent coordination safeguards. |
| D4: End-User Responsibility | Enable informed end-user decisions | Transparency about agent capabilities and limitations. Disclosure when interacting with AI agents. User control over agent scope. |
What Makes This Framework Unique
The MGF explicitly addresses challenges that generic AI governance frameworks do not:
- Agent sprawl: Uncontrolled proliferation of agents across an organization
- Miscoordination: Multiple agents working at cross purposes
- Conflict: Agents with incompatible objectives sharing resources
- Collusion: Agents optimizing together in ways that circumvent intended constraints
- Emergent behaviors: Unexpected capabilities arising from multi-agent interactions
The framework covers three multi-agent architectures: sequential (pipeline), supervisor (orchestrator-worker), and swarm (peer-to-peer). SWT3 chain witnessing provides cryptographic evidence across all three patterns.
2. Four-Dimension Crosswalk to SWT3
| IMDA Dimension | Requirement | SWT3 Procedure | Evidence Produced |
|---|---|---|---|
| D1: Risk Assessment | Risk bounding | AI-GRD.1 | Guardrail evaluation verdict per inference |
| Guardrail policy enforcement | AI-GRD.2, AI-GRD.3 | Policy version binding, violation recording | |
| Fairness and bias assessment | AI-FAIR.1, AI-FAIR.2 | Bias metric attestation per model | |
| D2: Human Accountability | Agent identity tracking | AI-ID.1 | Agent identity bound to every witness anchor |
| Human oversight attestation | AI-HITL.1, AI-HITL.2 | Human-in-the-loop verification evidence | |
| Authorization gates | AI-ACC.1 | Pre-inference authorization attestation | |
| D3: Technical Controls | Tool call governance | AI-TOOL.1, AI-TOOL.2 | Per-tool-call witness anchor with permission verification |
| Inference logging | AI-INF.1 | SHA-256 fingerprinted inference record | |
| Multi-agent chain tracing | AI-CHAIN.1 | Cycle ID linking all anchors in a decision chain | |
| Model drift monitoring | AI-DRIFT.1 | Drift detection attestation | |
| Revocation capability | AI-REV.1 | Anchor revocation with reason codes | |
| D4: End-User Responsibility | Transparency and explainability | AI-EXPL.1, AI-TRANS.1 | Transparency attestation per interaction |
| Consent management | AI-CONSENT.1 | Consent verification attestation | |
| Content watermarking | AI-MARK.1 | AI-generated content marking verification | |
| May 2026 Additions (v1.5 Update) | |||
| D1 (updated) | Multi-agent system risk factors | AI-CHAIN.1, AI-SAFE.1 | Multi-agent coordination evidence, safe state transitions |
| D1 (new) | Third-party agent governance | AI-SUPPLY.1, AI-TRUST.1 | Supplier compliance assessment, trust credential verification |
| D2 (updated) | Automation bias monitoring | AI-HITL.1, AI-DRIFT.1 | Override rate tracking, response time monitoring |
| D4 (new) | Skill degradation risk | AI-HITL.2 | Human override attestation, process knowledge verification |
3. Multi-Agent Chain Witnessing
The IMDA framework's coverage of multi-agent architectures maps directly to SWT3's chain witnessing capability. Every node in a multi-agent decision chain receives its own witness anchor, linked by a shared cycle_id.
How It Maps to IMDA D3 (Technical Controls)
When an orchestrator agent delegates work to sub-agents, each step produces a witness anchor. The cycle_id field links all anchors in the chain. Auditors can reconstruct the full decision lineage: which agent acted, what tools were called, what model was used, and whether any policy violations occurred.
The SWT3 auditor portal visualizes these chains as a "subway map" -- a swimlane diagram showing human intent, orchestrator decisions, and worker/tool execution with color-coded nodes for PASS, FAIL, and policy violations.
Each node in the chain carries: agent ID, model ID, clearing level, tool name (if applicable), policy violations (if any), and an SWT3 anchor. The chain is cryptographically verifiable end-to-end. No node can be inserted, removed, or modified after witnessing.
Architecture Coverage
| IMDA Architecture | SWT3 Evidence Pattern |
|---|---|
| Sequential (pipeline) | Linear chain of anchors with sequential timestamps. Each step inherits the cycle_id from the previous step. |
| Supervisor (orchestrator-worker) | Orchestrator anchor at the start, worker anchors branching off, orchestrator anchor at the end. The agent_id field distinguishes orchestrator from workers. |
| Swarm (peer-to-peer) | Multiple agents with the same cycle_id but different agent_ids. Trust Mesh credentials verify each agent's identity before data exchange. |
4. Tool Call Governance
The IMDA framework emphasizes tool access governance as a core technical control. SWT3 provides two procedures for tool witnessing:
Per-Tool-Call Evidence
Every tool call executed by an AI agent generates a witness anchor recording: the tool name, the calling agent, the model used, the clearing level, and the verdict. If the tool call violates policy (e.g., accessing a restricted database, exceeding scope), the violation is recorded in the anchor's observations field.
Pre-Execution Authorization
Before a tool is executed, the permission verification procedure checks whether the agent has authorization for that tool at the current clearing level. The verification result is witnessed regardless of outcome -- both grants and denials create evidence.
The framework distinguishes between structural controls (architecture-level), rule-based controls (policy enforcement), and prompt-layer controls (instruction-level). SWT3 tool witnessing operates at the rule-based control layer -- it records what happened and whether it matched policy. Structural and prompt-layer controls are the deployer's responsibility; SWT3 witnesses the outcome.
5. Trust Mesh for Agent-to-Agent Verification
The IMDA framework identifies agent-to-agent trust as a key challenge in multi-agent systems. Trust Mesh is SWT3's mutual verification protocol: before two agents exchange data, each presents a cryptographic credential proving its compliance posture, clearing level, and jurisdiction.
How Trust Mesh Addresses IMDA Risks
| IMDA Risk | Trust Mesh Response |
|---|---|
| Agent sprawl | Every agent must present a valid credential. Unregistered agents cannot participate in the mesh. |
| Miscoordination | Policy requirements are declared before data flows. If requirements conflict, the exchange is blocked and the blocked attempt is witnessed. |
| Collusion | Every agent-to-agent exchange is independently witnessed. Coordinated behavior that violates policy produces detectable patterns in the audit trail. |
| Emergent behaviors | Chain witnessing captures the full interaction sequence. Unexpected behavior produces anomalous anchor patterns (drift detection). |
6. Clearing Levels for Cross-Border Compliance
Singapore's position as a cross-border data hub creates unique compliance requirements. The IMDA framework applies alongside PDPA (Personal Data Protection Act) and sector-specific regulations (MAS guidelines for financial institutions, HSA for healthcare).
SWT3 clearing levels control what metadata survives the witness process:
| Level | Content Retained | Singapore Use Case |
|---|---|---|
| L0 Analytics | Full context: hashes, factors, model ID, provider, guardrails | Internal R&D, pre-deployment testing |
| L1 Standard | Hashes and factors only. No raw prompts or responses. | Production deployments, MAS-regulated systems |
| L2 Sensitive | Hashes, factors, model ID only. No provider metadata. | Healthcare AI (HSA), PII-heavy workloads under PDPA |
| L3 Classified | Numeric factors only. Model ID hashed. Zero metadata. | Government systems (GovTech), defense applications |
Clearing levels are embedded in every witness anchor. Cross-border data transfers can use higher clearing levels to strip metadata before evidence leaves Singapore jurisdiction, while retaining the cryptographic proof that governance controls were active.
7. Implementation Path
The singapore-imda profile pre-configures clearing level defaults, jurisdiction metadata (SG), and enables chain witnessing for multi-agent deployments. All witness anchors include jurisdiction and legal basis fields that survive all clearing levels.
For organizations already using the SDK, IMDA compliance evidence is generated automatically. No code changes are required beyond setting the profile. The crosswalk mapping above shows which SWT3 procedures produce evidence for each IMDA dimension.
Every witness anchor can be independently verified at sovereign.tenova.io/verify using only the anchor string. No API keys, no vendor access. SHA-256 runs locally.
8. May 2026 Update: Multi-Agent Systems, Third-Party Agents, and Automation Bias
The v1.5 update (May 20, 2026) added substantial new guidance in four areas. Over 50 organizations contributed real-world case studies spanning financial services, government, healthcare, and enterprise AI -- including Singaporean companies (DBS, OCBC, GovTech), multinational enterprises (Tencent, Google, AWS, PwC, Workday), and government agencies. The update also provides more granular guidance on technical controls, with specific implementation patterns drawn from production deployments. The changes are most significant for organizations deploying multi-agent architectures or integrating third-party AI agents.
8.1 Multi-Agent System Risk Factors
The MGF now explicitly identifies multi-agent configurations as factors affecting risk probability under Dimension 1. Previously, multi-agent risks were addressed implicitly through the three architecture patterns (sequential, supervisor, swarm). The update adds multi-agent deployment as a standalone risk factor in the likelihood assessment, requiring organizations to evaluate coordination risks, emergent behavior potential, systemic risks from cascading failures across agent networks, and shared resource conflicts before deployment.
How SWT3 Addresses This
Chain witnessing (AI-CHAIN.1) provides cryptographic evidence of multi-agent coordination: every agent in a chain produces a witness anchor linked by cycle_id. Safe state transitions (AI-SAFE.1) record when agents are suspended due to coordination failures or policy violations. Together they create a complete risk evidence trail for multi-agent deployments.
Query AI-CHAIN.1 anchors grouped by cycle_id to verify all agents in a chain are independently witnessed. Cross-reference with AI-SAFE.1 anchors to identify coordination failures. A deployment with multi-agent chains but no AI-SAFE.1 anchors warrants investigation into whether fail-safe mechanisms are configured.
8.2 Third-Party Agent Governance
The update adds third-party agent usage as a distinct risk factor affecting likelihood assessment under Dimension 1. The MGF differentiates roles between platform providers and system developers/app creators across the agentic AI lifecycle, establishing clearer accountability structures for external agent integrations. Organizations deploying agents built by third parties must assess the agent's governance posture independently, not rely on the provider's self-attestation alone.
How SWT3 Addresses This
Supply chain witnessing (AI-SUPPLY.1) records the compliance assessment of third-party agent providers. Trust Mesh verification (AI-TRUST.1) requires each agent to present a cryptographic credential before data exchange, proving its compliance posture, clearing level, and jurisdiction. A third-party agent without a valid Trust Mesh credential is blocked from participating in the mesh.
Request AI-SUPPLY.1 anchors for each third-party agent integrated into the system. Verify that Trust Mesh credentials (AI-TRUST.1) are checked before every cross-agent data exchange. A gap between the number of third-party agents in production and the number of AI-SUPPLY.1 assessments indicates agents deployed without governance review.
8.3 Automation Bias Monitoring
The MGF expands Dimension 2 (Human Accountability) with specific guidance on preventing automation bias. The update recommends monitoring human override rates and response times as leading indicators of over-reliance on AI agent recommendations. Organizations should track how frequently humans reject agent recommendations and measure response latency to identify patterns suggesting rubber-stamp approval rather than meaningful oversight.
How SWT3 Addresses This
Human-in-the-loop witnessing (AI-HITL.1) records each human review decision (approve, reject, escalate) with response latency. Drift monitoring (AI-DRIFT.1) detects when override rates fall below acceptable thresholds, signaling potential automation bias. The combination provides continuous evidence that human oversight is meaningful, not perfunctory.
Example factor encoding:
Trend override rates over time using AI-HITL.1 anchors. A steadily declining override rate with decreasing response times is a red flag for automation bias. The MGF does not prescribe specific thresholds, but override rates below 2% or response times below 500ms across hundreds of reviews warrant investigation. Cross-reference with AI-DRIFT.1 anchors to confirm drift detection is monitoring these metrics.
8.4 Skill Degradation and Knowledge Loss
The v1.5 update adds a new emphasis under Dimension 4 (End-User Responsibility) on operational risks from AI agent deployment: skill degradation, loss of manual process knowledge, and business continuity threats when entry-level automation causes knowledge loss. Organizations must assess whether agent deployment erodes the human skills needed to perform tasks manually if the agent fails.
How SWT3 Addresses This
Human override attestation (AI-HITL.2) records that designated personnel can perform the agent's function manually. This is not a one-time check -- periodic attestation proves that manual capability is maintained over time. The override event, reason, and outcome are captured in each anchor.
Check the cadence of AI-HITL.2 anchors. A deployment running for 6+ months with no override attestations suggests the organization has not verified that manual fallback capability still exists. The MGF recommends periodic manual override exercises, not just documentation that the capability exists in theory.
PDPC Generative AI Advisory Guidelines (June 2, 2026)
On June 2, 2026, the Personal Data Protection Commission (PDPC) published Advisory Guidelines on the Use of Generative AI Tools. These guidelines complement the IMDA MGF by addressing personal data handling in generative AI contexts:
- Consent and notification: Organizations must notify individuals when their personal data is used as input to generative AI. PDPC recommends purpose limitation and data minimization. SWT3 procedure:
AI-CONSENT.1witnesses consent status per inference. - Output accuracy: Organizations must take reasonable steps to verify AI-generated outputs before acting on them, especially when outputs concern individuals. SWT3 procedures:
AI-INF.1(inference provenance),AI-HITL.1(human verification). - Third-party AI tools: Organizations using third-party generative AI services remain responsible for data protection. Contractual safeguards and technical controls are expected. SWT3 procedures:
AI-ACC.1(access control),AI-SUPPLY.1(supply chain governance). - Cross-border transfers: Data sent to overseas AI providers must comply with PDPA transfer requirements (Part 4A). SWT3 clearing levels (2+) hash sensitive data before it leaves the application boundary.
The PDPC guidelines are advisory (not mandatory), but they signal the direction of enforcement. Organizations that demonstrate compliance with these guidelines through verifiable evidence are better positioned for regulatory engagement.
References
- IMDA Model AI Governance Framework for Agentic AI (PDF)
- IMDA v1.5 Update Press Release (May 20, 2026)
- PDPC Advisory Guidelines on Use of Generative AI (June 2, 2026)
- SWT3 Trust Mesh Protocol Guide
- SWT3 Protocol Specification
- UCT Registry (full procedure catalog)
- Framework Crosswalks (machine-readable)