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.
Updated October 14, 2026. IMDA MGF for Agentic AI v1.5 (May 2026) now supplemented by AI Tester Accreditation Programme (AI TAP, 5 accredited firms), Agentic Testing Starter Kit (4-step process), and Anthropic-Singapore MOU on model evaluation and testing standards. 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.
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 |
| Tool integrity verification | AI-MCP.2 | Tool schema hash with drift detection per invocation | |
| Server authentication | AI-MCP.3 | Auth method and mutual auth attestation per server | |
| 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.
Tool Integrity and Server Authentication
Two additional MCP security procedures address OWASP Agentic Top 10 risks directly relevant to IMDA D3:
Detecting Tool Poisoning and Schema Rug Pulls
Every MCP tool invocation can be witnessed with a SHA-256 hash of the tool's schema. If the schema changes between invocations (a "rug pull"), the drift flag is set automatically. This addresses OWASP MCP-03 (tool poisoning) and provides evidence that tool definitions remained stable throughout a session.
Query AI-MCP.2 anchors grouped by tool_name. Any anchor with schema_drift=true warrants investigation -- the tool definition changed mid-session, which could indicate compromise or uncontrolled updates.
Recording Auth State Before Tool Invocation
Records the authentication method (none, API key, OAuth, mTLS, DID) used between client and MCP server. FAIL verdict when no auth is configured (auth_method=0) is a valid compliance finding per NIST IA-9. Addresses OWASP MCP-07 (insufficient authentication).
Agent Credential Lifecycle (NHI Namespace)
The IMDA framework's emphasis on agent identity tracking and authorization gates maps directly to SWT3's Non-Human Identity (NHI) namespace -- 7 procedures covering the full credential lifecycle:
| NHI Procedure | IMDA Dimension | Evidence Produced |
|---|---|---|
NHI-SCOPE.1 | D3: Technical Controls | Credential scope boundary attestation |
NHI-CYCLE.1 | D3: Technical Controls | Credential lifecycle event (issued, activated, suspended, revoked) |
NHI-PRIV.1 | D2: Human Accountability | Privilege change attestation (scope expansion/reduction) |
NHI-ROTATE.1 | D3: Technical Controls | Credential rotation event (scheduled, compromise, policy) |
NHI-AGENT.1 | D2: Human Accountability | Agent-to-agent credential delegation with depth tracking |
NHI-REVOKE.1 | D3: Technical Controls | Credential revocation with cascade flag |
NHI-EXPIRE.1 | D3: Technical Controls | Credential expiration with renewal and grace period tracking |
The NHI namespace provides the evidence trail for IMDA's requirement that agent credentials are managed through a governed lifecycle. A deployment with AI agents but no NHI anchors indicates agents operating with ungoverned credentials -- a finding under both D2 (accountability) and D3 (technical controls).
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). |
| Shadow servers | Server Discovery Attestation (AI-MCP.4) inventories all MCP servers and flags those not in the approved registry. Addresses OWASP MCP-09. |
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
Jurisdiction and legal basis fields survive all clearing levels. For organizations already using the SDK, IMDA compliance evidence is generated automatically from existing witness calls. 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.
9. October 2026: AI TAP Accreditation, Anthropic MOU, and Agentic Testing Starter Kit
Three developments announced at Singapore International Cyber Week (October 14, 2026) significantly expand the Singapore AI governance ecosystem. Together they create a formalized testing infrastructure that moves Singapore from voluntary framework guidance to an accreditation-backed testing regime.
Why This Matters for SWT3 Users
AI TAP accreditation creates a class of professional third-party testers who need evidence infrastructure. The Agentic Testing Starter Kit prescribes a 4-step testing process that maps directly to SWT3 witness procedures. The Anthropic MOU signals that model evaluation, testing standards, and incident response are the priority for Singapore's AI safety cooperation. SWT3 provides the cryptographic evidence layer that makes all three operational.
9.1 AI Tester Accreditation Programme (AI TAP)
Announced May 18, 2026 by Minister Josephine Teo and launched in Q3 2026, AI TAP is the first programme in Asia to accredit third-party AI testing providers. The AI Verify Foundation evaluates applicants across technical competency, operational track record, delivery capability, and financial sustainability.
Five firms were accredited in the initial cohort: AIDX Tech, Knovel Engineering, PwC Singapore, Resaro, and Vulcan.
What Accredited Testers Need
AI TAP accreditation requires testers to demonstrate that their testing is rigorous, repeatable, and independently verifiable. This creates a direct need for evidence infrastructure:
| AI TAP Requirement | SWT3 Evidence | Procedure |
|---|---|---|
| Testing competency demonstration | Per-test witness anchor with model, inputs hash, verdict, and timestamp | AI-ASSESS.1 |
| Repeatable test execution | Identical test parameters produce identical fingerprints across runs | AI-INF.1 |
| Independent verification of results | Any party can verify anchors at sovereign.tenova.io/verify using only the anchor string | All procedures |
| Track record of testing engagements | Chronological ledger of all test anchors per engagement, tamper-proof | AI-AUDIT.1 |
| Continuous monitoring evidence | Drift detection anchors proving ongoing surveillance | AI-DRIFT.1, AI-DRIFT.2 |
SWT3 witness anchors provide tamper-proof evidence that your testing occurred at a specific time with specific parameters and produced a specific result. When IMDA reviews your accreditation renewal, the anchors demonstrate testing rigor without requiring access to proprietary test methodologies or client data. The clearing level system (L0-L3) ensures sensitive test data stays within appropriate boundaries while the cryptographic proof travels freely.
9.2 Agentic Testing Starter Kit
Released by IMDA alongside the AI TAP launch, the Agentic Testing Starter Kit extends the MGF for Agentic AI with a four-step testing process for AI agent deployments. The kit provides practical guidance for applying the framework's four dimensions to real-world agent testing.
| Starter Kit Step | Description | SWT3 Procedures | Evidence Produced |
|---|---|---|---|
| Step 1: Identify Risks | Assess autonomy level, tool access, data sensitivity, and reversibility of agent actions | AI-GRD.1, AI-SAFE.1 |
Guardrail evaluation and safe-state attestation anchors documenting risk boundaries |
| Step 2: Design and Run Tests | Execute structured tests across fairness, robustness, safety, and tool governance | AI-ASSESS.1, AI-FAIR.1, AI-TOOL.1 |
Per-test anchors with model ID, test parameters, and pass/fail verdicts |
| Step 3: Analyze Results | Evaluate test outcomes against acceptance criteria, identify gaps | AI-DRIFT.1, AI-EXPL.1 |
Drift detection against baselines, explainability attestation for result interpretation |
| Step 4: Monitor and Retest | Continuous monitoring with periodic re-testing as agents evolve | AI-DRIFT.2, AI-PMM.1 |
Consequence-mapped drift thresholds, post-market monitoring attestation |
The starter kit explicitly addresses controls around autonomy levels, tool access boundaries, data sensitivity, and human checkpoint requirements. Each of these maps to existing SWT3 procedures in the crosswalk table above (Section 2).
Step 4 is where most organizations struggle. SWT3 transforms continuous monitoring from a manual periodic activity into an automated evidence stream. Every inference, tool call, and policy check produces a witness anchor automatically. When IMDA or an AI TAP-accredited tester asks "show us your continuous monitoring evidence," the SWT3 ledger provides a chronological, tamper-proof answer.
9.3 Anthropic-Singapore MOU on AI Safety
On October 14, 2026, Anthropic co-founder Ben Mann and Kai Fong Chng, Permanent Secretary of Singapore's Ministry of Digital Development and Information, signed a Memorandum of Understanding on the sidelines of Singapore International Cyber Week. Anthropic also opened its fifth APAC office in Singapore.
The MOU covers four cooperation areas:
- Model evaluation and testing standards: Technical exchanges with Singapore's AI safety, security, and assurance institutions on evaluation methodology. Evaluations measure models against defined safety and performance criteria.
- Red teaming and incident response: Collaborative frameworks for probing harmful, unreliable, or exploitable behavior in AI systems. Structured incident response protocols.
- Research on AI adoption impact: Joint research on how AI deployment affects organizations and communities, informing future governance guidance.
- Responsible AI across public and private sectors: Technical and policy expertise as Singapore develops its regulatory approach, including support for SMEs and public officer AI capability building.
What the Anthropic MOU Signals
The MOU's emphasis on model evaluation, testing standards, and incident response aligns directly with the evidence requirements in the crosswalk above:
| MOU Cooperation Area | SWT3 Evidence Layer |
|---|---|
| Model evaluation against safety criteria | AI-INF.1 (inference provenance), AI-GRD.1 (guardrail evaluation), AI-ASSESS.1 (assessment attestation) |
| Red teaming and adversarial testing | AI-ROBUST.1 (robustness attestation), AI-SAFE.1 (safe state transition), AI-GRD.2 (policy violation recording) |
| Incident response | AI-INCIDENT.1 (incident attestation), AI-REV.1 (anchor revocation with reason codes), AI-EMRG.1 (emergency override lifecycle) |
| Responsible AI adoption | AI-FAIR.1 (fairness attestation), AI-TRANS.1 (transparency), AI-CONSENT.1 (consent verification) |
Anthropic's MOU is notable because it leads with safety testing infrastructure rather than consumer product adoption. This reinforces Singapore's position as a model-evaluation-first jurisdiction. For organizations deploying Claude or any AI system in Singapore, the MOU signals that IMDA will develop increasingly specific testing standards. SWT3 witness anchors provide the evidence format that survives the transition from voluntary guidance to structured evaluation requirements.
9.4 The 2026 Singapore Consensus on Global AI Safety Research Priorities
Published following the second International Scientific Exchange on AI Safety, the 2026 Singapore Consensus represents scientific agreement from over 100 contributors spanning 13 countries, frontier AI developers, government safety institutes, academia, and civil society.
Key developments relevant to agentic AI governance:
- Societal resilience elevated as a distinct fourth pillar alongside misuse prevention, alignment/control, and systemic risk. This recognizes that AI governance must prepare societal systems for failures, not just prevent them.
- Autonomous agent risks receive dedicated focus, acknowledging that increasingly autonomous AI agents introduce novel risk categories beyond traditional model safety.
- Open-weight model safety highlighted as requiring unique governance tools for ecosystem monitoring, given that open-weight models can be modified and deployed without oversight.
The Consensus is a scientific research priority document, not a regulatory instrument. However, it shapes the research agenda that feeds into future IMDA guidance, AI Verify testing criteria, and international standards alignment. Organizations building governance evidence trails now are better positioned when these research priorities translate into testing requirements.
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)
- Anthropic Singapore Office and Government MOU (October 14, 2026)
- AI Verify Foundation Resources (Agentic Testing Starter Kit, AI TAP)
- Singapore to Certify Private Sector AI Testing Firms (GovInsider)
- The 2026 Singapore Consensus on Global AI Safety Research Priorities
- IMDA Crosswalk: AI Verify Testing Framework x NIST AI RMF GenAI Profile (PDF)
- SWT3 Trust Mesh Protocol Guide
- SWT3 Protocol Specification
- UCT Registry (full procedure catalog)
- Framework Crosswalks (machine-readable)