Contents
IMDA MGF for Agentic AI v1.5 × OWASP Agentic Top 10 2026 — Control Matrix and Risk View
A clause-level comparison of the two agentic-AI documents most likely to sit on a financial institution's desk in 2026: Singapore IMDA's governance framework and the OWASP GenAI Security Project's threat list. The two tables below are the working core of that comparison — 28 normalised control dimensions and 17 harmonised risk themes — each row stating what the two documents actually require, how strong that coverage is, and how to combine them. Both tables are filterable in place.
How to read this page
- The two documents are not substitutes. IMDA is a governance framework: bodies, accountability, approval, training, residual-risk acceptance. OWASP is an attacker-perspective threat and control list: ten threat entries, 148 controls, no governance structure at all. Read a
Noneon the OWASP side as out of scope for that document, not as an oversight. - Coverage grades are
Strong/Partial/Weak/None, assessed per row against the demands of that row alone — not against the document as a whole. - Filters. Each table has a keyword box (space-separated terms, all must match) plus dropdowns for the categorical columns. The most useful views: set IMDA coverage to
Weakfor the engineering blind spots to import from OWASP; set OWASP coverage toNoneorWeakfor what only IMDA can carry. - Sections cited are native:
§x.y.zfor IMDA,ASI01–ASI10for OWASP. - Related analyses on this site. Anthropic RSP v3.4 covers threshold-based governance from a lab's own side; Frontier AI risk evidence map covers how strong the underlying evidence currently is; Five boundaries of agent security covers the enforcement mechanisms these two documents assume but do not specify.
Cross-framework control matrix · 5 pillars / 28 control dimensions
Master sheet of this workbook. Each row is a normalised control dimension; the two middle columns state what each document actually requires for that dimension (with native section numbers / ASI references); the final column gives the integration recommendation. Coverage is colour-coded per the legend.
| Pillar | Control Dimension | IMDA requirement (section) | OWASP requirement (ASI reference) | IMDA Coverage | OWASP Coverage | Integration note |
|---|---|---|---|---|---|---|
| A. Governance & Accountability | C1 Board and senior management accountability | §2.2.1 “key decision-makers”: set the high-level objectives for agent use, define the permitted operational use cases (including data-access ceilings), and establish the overall governance route (risk management framework and escalation mechanisms) | None. The document contains no governance bodies, no ownership and no escalation structure; the closest is the ASI08 narrative — “enterprises must assess this carefully to ensure it remains within the organisation’s overall risk budget” — which invokes risk appetite but names no accountable owner | Strong | None | Use IMDA §2.2.1 as the institutional template; nothing can be expected from the OWASP side, so the firm must map the ASI controls onto its existing first / second / third line-of-defence responsibilities itself. |
| A. Governance & Accountability | C2 Role allocation and segregation of duties | §2.2.1 sets out key responsibilities for four role types (key decision-makers / product teams / cybersecurity teams / users); the security team is explicitly accountable for baseline security guardrails, secure-by-design templates, and periodic red teaming and threat modelling | Very weak. No RACI, no three lines of defence, no segregation of duties. Closest items: ASI01 mitigation 9 “bring AI agents into the insider-threat programme”, ASI08 mitigation 5 “governance agent”, ASI10 mitigation 6 “the orchestrator, not the agent, holds the keys” | Strong | Weak | Assigning each OWASP technical control to one of the four role types defined by IMDA produces a responsibility matrix directly. |
| A. Governance & Accountability | C3 Use-case suitability assessment and risk tiering | §2.1.1 risk = likelihood × impact; five impact factors (domain error tolerance, sensitive-data access, external-system access, scope of action, reversibility) plus five likelihood factors (degree of autonomy, task complexity, external exposure, third-party operation, system complexity); the case studies present a three-tier and a five-tier rating | Weak and implicit. No approval workflow, no use-case tiering. The closest are the “Least-Agency” doctrine, ASI05 mitigation 2 “no direct agent access to production systems” and ASI08 mitigation 9 “gate any relaxation of policy on a blast-radius ceiling” — all engineering gates rather than governance approvals | Strong | Weak | IMDA’s ten factors can be turned straight into a use-case intake form; OWASP’s Least-Agency principle can serve as grounds for a security-review veto. |
| A. Governance & Accountability | C4 Residual risk assessment and acceptance | §2.1.2, closing paragraph: residual risk always remains; the organisation should assess it, determine whether it sits at an acceptable level, and accept it explicitly | Only the passing reference to the “organisation’s overall risk budget” in the ASI08 narrative — no process, no accountable owner | Strong | Weak | Residual-risk acceptance must be tied to use-case tiering; recommend citing OWASP AIVSS scores as the quantitative input within the IMDA mechanism. |
| A. Governance & Accountability | C5 Third-party and vendor governance (commercial side) | §2.2.1: contracts and terms must specify security arrangements, performance guarantees and data-protection obligations, and where gaps remain the risk tolerance must be reassessed; third parties must disclose agent capabilities and data-handling practices; technical control features are required (scoped API keys, per-agent identity tokens, logs of tool calls and access history), failing which the firm must switch to an alternative or in-house solution or narrow the use case | No commercial governance. The technical supply chain is very strong (ASI04), but there is no due diligence, no contractual control, no audit rights, no concentration risk and no exit or substitutability; only the ASI08 scenario indirectly observes the concentration impact of a hyperscale cloud provider outage | Strong | Weak | IMDA governs contracting and onboarding, OWASP governs technical verification. The two must be layered; otherwise the firm either signs a contract it cannot verify against, or verifies a product over which it has no recourse. |
| A. Governance & Accountability | C6 Training and end-user education | The whole of §2.4: for users interacting with an agent the emphasis is transparency (five disclosures); for users with an agent embedded in their workflow it is training (baseline awareness, effective oversight, skill degradation); §2.2.1 requires users to attend training and to report issues promptly | Partial. ASI09 mitigations 4 / 5 / 8: periodic reminders to users about manipulation patterns and agent limitations, a reporting channel for suspicious behaviour, and continuous training and assessment of staff involved in human oversight; no training-programme design and no frequency requirements | Strong | Partial | Folding ASI09’s “manipulation-pattern reminders” into the failure-mode training list in IMDA §2.4.3 produces a curriculum that covers both the business and the security side. |
| A. Governance & Accountability | C7 Regulatory compliance mapping | None. No mapping to any regulatory provision; the document states only that it carries forward the 2020 MGF | None. The front matter states expressly that it does not constitute legal advice; compliance appears only as an AIVSS scoring category (Compliance Violations) | None | None | A gap shared by both. Financial institutions must connect these to local regulation themselves (see the MAS / ABS / FSB directories in this repository) and perform a one-off mapping of the IMDA clauses to regulatory provisions. |
| B. Identity & Authorisation | C8 Agent identity (unique, verifiable, centrally catalogued) | §2.1.2 sets four identity requirements: unique and cryptographically verifiable; attributable (linked to a supervising agent / person / department); differentiated and logged according to “on whose behalf the agent is acting”; centrally catalogued and centrally managed to prevent agent sprawl, with prompt decommissioning of identities no longer needed | ASI03 (per-agent identity, mTLS / scoped credentials, onboarding agents onto the platform as managed non-human identities with audit trails and lifecycle controls); ASI10 (cryptographic identity attestation per agent, signed behaviour manifests); Appendix C maps to the NHI Top 10 | Strong | Strong | One of the two most complementary rows in the matrix. IMDA supplies the requirements, OWASP the implementation and the interface to an external standard (NHI); together they compose directly into an agent identity standard. |
| B. Identity & Authorisation | C9 Least privilege and scoped authorisation | §2.1.2 least-privilege tool and data policies; partition agents along functional boundaries; §2.3.1 least privilege at the tool layer, enforced through strongly authenticated authorisation, with write access to sensitive tables withheld by default | ASI02 mitigation 1 “least agency and least privilege” (per-tool scope, maximum rate and egress allowlist, expressed as IAM policy statements); ASI03, ASI05, ASI08 and ASI10 all restate this control | Strong | Strong | Both agree. The implementation insight lies in OWASP’s form of expression — write permissions as executable policy statements rather than as prose in a document. |
| B. Identity & Authorisation | C10 Short-lived / just-in-time credentials and non-transferability | §2.1.2 authorisation must be scope-limited, time- or session-bound, non-transferable and least-privilege, with an explicit escalation path | ASI02 “just-in-time and ephemeral access” (session-bound keys); ASI03 (short-lived scoped tokens, automatic revocation on idleness or anomaly); ASI08 (per-run, task-scoped short-lived credentials); ASI10 (single-use credentials per run bound to a single-use audience; keys managed, rotated and revoked in an HSM / KMS and never issued to the agent, with the orchestrator signing on its behalf) | Partial | Strong | IMDA gives only the principle; OWASP reaches down to the key-custody layer. Recommend adopting OWASP’s “never issue keys to the agent” as a hard design constraint. |
| B. Identity & Authorisation | C11 Delegation chains and transitive permissions | §2.1.2: an agent’s permissions must never exceed those of the delegating principal, and delegation must be explicitly recorded; the document acknowledges that recursive delegation (an agent spawning sub-agents) remains an unsolved problem | ASI03: OAuth tokens bound to a signed intent (subject / audience / purpose / session); per-action authorisation re-checked by a central policy engine; re-authentication on context switch; no cross-agent permission inheritance without intent re-validation; detection of delegation and transitive permissions; detection of anomalous cross-agent privilege escalation and of device-code phishing flows | Partial | Strong | The “recursive delegation” problem raised by IMDA is precisely what ASI03’s intent-bound tokens answer; this is the tightest technical join between the two documents. |
| C. Technical Controls & Runtime | C12 Preference for deterministic / structural-layer controls | §2.3.1 (new in v1.5): for high-risk actions, prefer deterministic and structural controls at the system layer over prompt-layer guardrails (prompt-layer definitions are inconsistent across users); use model-based guardrails for risks that resist expression as rules; §2.1.2 “prefer deterministic constraints, bound by design”, with non-deterministic constraints requiring additional monitoring or a human in the loop | ASI02 mitigation 4 “policy-enforcement middleware” (the Intent Gate: a PEP / PDP validating intent, parameters, schema, rate and short-lived credentials, revoking and auditing on drift); ASI08 mitigation 4 “high-impact tool calls must first pass policy-as-code rules”, mitigation 5 “separate planning from execution using an external policy engine” | Strong | Strong | Both reach the same conclusion. IMDA states the principle in governance terms, OWASP supplies its architectural implementation (PEP / PDP separation, policy-as-code). |
| C. Technical Controls & Runtime | C13 Tool-layer controls (input format, allowlisting, rate, egress) | §2.3.1 tool controls: strict input formats; least privilege enforced through strongly authenticated authorisation; write access to sensitive tables withheld by default; sensitive material (passwords, API keys) handed back to the user to enter; §2.3.1 runtime controls: rate limiting and input validation | The whole of ASI02: egress allowlisting with rejection of non-approved destinations; adaptive tool budgets (cost, rate and token ceilings, with automatic revocation or throttling on breach); semantic and identity validation (fully qualified tool names, version pinning, fail-on-ambiguity); tamper-proof tool-call logs and anomaly detection over chained tool calls | Partial | Strong | IMDA’s “hand sensitive material back to the user to enter” is a sound practice that OWASP does not cover and can be contributed in the reverse direction; for everything else, follow OWASP. |
| C. Technical Controls & Runtime | C14 Sandboxing, isolation and trust zones | §2.1.2 self-contained environments with restricted network and data access (particularly for high-risk tasks such as code execution); §2.3.1 sandbox any code execution | ASI02 (execution sandboxing and egress control); ASI04 (container sandboxes with restricted network and system calls, reproducible builds); ASI05 (non-root, restricted file system, framework sandbox); ASI08 (isolation and trust boundaries: sandboxing, network segmentation, scoped APIs, mutual authentication); ASI10 (trust zones with strict inter-zone communication rules, restricted execution environments) | Partial | Strong | IMDA gives the scenarios, OWASP the layered design (trust zones plus network segmentation plus system-call restriction). Recommend adopting the ASI08 / ASI10 trust-zone model as the architectural baseline. |
| C. Technical Controls & Runtime | C15 Code-execution security | A single line in §2.3.1: sandbox any code execution | The whole of ASI05, seven groups: follow LLM05 output handling; prohibit direct agent access to production and bring vibe coding into pre-release checks (security assessment, adversarial unit tests, detection of unsafe in-memory evaluators); disable eval in production agents (use a safe interpreter with taint tracking instead); execution-environment security (non-root, restricted network and file system, blocking of packages with known vulnerabilities, logging of file diffs); architectural separation of code generation from code execution with a validation gate; the auto-execution allowlist placed under version control; static scanning before execution and runtime detection of prompt-injection patterns | Weak | Strong | A net gap for IMDA. Any institution using coding assistants or code-execution tools should adopt ASI05 directly as its control checklist. |
| C. Technical Controls & Runtime | C16 Memory and context integrity | A single line in §2.3.1: limit memory shared between agents; §2.1.1 names memory poisoning as a common threat; the case studies mention “curated datasets for external agents” and a “deterministic context graph carrying version and expiry metadata” | The whole of ASI06, nine groups: encryption in transit and at rest plus least privilege; validation of every memory write and model output before persistence (rule-based plus AI); memory isolated by user session and by domain; acceptance only of authenticated curated sources, contextualised access per task, retention minimised by sensitivity; source attribution and detection of suspicious update frequency; prohibition of automatic re-ingestion of the agent’s own output (bootstrap poisoning); adversarial testing, snapshot rollback, version control, human review of high-risk actions, tenant namespaces, trust scores, decay and expiry, rollback and quarantine; automatic expiry of unverified memory; retrieval weighted by trust and tenant | Weak | Strong | IMDA’s thinnest area (named twice, with no control family behind it). Any deployment enabling long-term memory or RAG must close the gap with ASI06, failing which the governance documentation will be severely disconnected from the actual risk. |
| C. Technical Controls & Runtime | C17 Agent-to-agent communication security | Two lines in §2.3.1: replace free text with structured schemas and typed function calls to reduce inadvertent transfer of instructions; limit memory shared between agents | The whole of ASI07, nine groups: end-to-end encryption plus per-agent credentials, mutual authentication, PKI certificate pinning and forward secrecy; message integrity and semantic protection (digital signatures, payload and context hashing, natural-language-aware sanitisation, intent-diffing); replay protection (nonces, session identifiers, timestamps bound to the task window, message fingerprints); protocol and capability security (weak and legacy modes disabled, identity-bound trust negotiation, gateway-side version and capability policy); limiting metadata inference (fixed-length padding, rate smoothing); protocol pinning (MCP / A2A / gRPC rejecting downgrades and unknown schemas); discovery and routing protection; attestable registries and signed agent cards; typed contracts with schema validation | Weak | Strong | IMDA’s “structured schema” is only one item among the nine ASI07 control groups. Multi-agent and A2A deployments must take ASI07 as the baseline. |
| C. Technical Controls & Runtime | C18 Supply-chain integrity (SBOM / signing / pinning) | §2.3.1 MCP server allowlisting plus sandboxed code execution; §2.2.1 requires third parties to provide technical control features; the staged path in the GovTech case study of “block MCP first → allowlist MCP → containerised sandbox” | The whole of ASI04, nine groups: provenance attestation and SBOM / AIBOM (signing and attestation of manifests, prompts and tool definitions; periodic attestation; an AI component inventory; a curated registry; blocking of untrusted sources); dependency gating (allowlisting and pinning, typosquat scanning, provenance verification before installation, automatic rejection of unsigned artefacts); containerisation and reproducible builds; prompts and memory placed under version control and scanned for anomalies; mutual authentication and attestation between agents (PKI / mTLS, no open registration, message signing and signature verification); continuous runtime re-verification of signatures, hashes and SBOMs together with behaviour, permissions, lineage and telemetry; content-hash and commit ID pinning; staged rollout plus differential testing plus automatic rollback on hash drift; a supply-chain kill switch (emergency revocation across all deployments); zero-trust design | Weak | Strong | A net gap for IMDA. The onboarding process for third-party agents, plugins, MCP servers and skills should adopt ASI04 directly. |
| C. Technical Controls & Runtime | C19 Guardrails and input / output validation | §1.1.1 lists “controls” as a core agent component (access control / guardrails / human approval); §2.3.1 runtime input validation; §2.2.1 makes the security team accountable for baseline security guardrails and secure-by-design templates | ASI01 (treat all natural-language input as untrusted; sanitise every connected data source using CDR, prompt-carrier detection and content filtering); ASI05 (output encoding); ASI06 (validation before write); ASI09 (output validation and human gates) | Partial | Strong | IMDA abstracts guardrails into a component, OWASP supplies the concrete sanitisation techniques. Recommend hanging ASI01’s sanitisation control list beneath IMDA’s definition of the “controls” component. |
| D. Human Oversight | C20 Approval checkpoint design | §2.2.2 identifies four situations requiring approval: high-impact actions and decisions; irreversible actions (deleting data, sending communications, making payments); anomalous or outlier behaviour; user-defined thresholds; approval requests must carry context and be digestible, must state the risk clearly, and may include a confidence level; the form of human input is tiered (approve or reject, edit the plan, written justification for high-risk cases) | Scattered but concrete: ASI01 (human approval required for high-impact and goal-changing actions); ASI02 (human confirmation required for destructive actions, with a plan or dry-run diff before execution); ASI03 (human in the loop for privilege escalation); ASI05 (human approval required for privileged execution); ASI09 (explicit confirmation or multi-step approval before sensitive-data access or high-risk actions) | Strong | Strong | IMDA defines what gets approved, OWASP defines how it is presented for approval (dry-run diffs, separation of preview from commit). Merged, the two amount to a complete approval standard. |
| D. Human Oversight | C21 Guarding against automation bias and auditing oversight effectiveness | §2.2.2: audit the human override rate (too low = rubber-stamping), approval response times (too short = automation bias or fatigue), and use data analytics to identify “outlier approvers”; train approvers to recognise failure modes and warn them that a chain of thought may not faithfully reflect the action actually taken; ensure approvers hold the relevant domain expertise; deny by default when the approval infrastructure fails or no established policy exists | ASI09: adaptive trust calibration (autonomy and oversight intensity adjusted against a contextual risk score); confidence-weighted cues (“low confidence”, “source unverified”); continuous training and assessment of staff involved in oversight; periodic reminders about manipulation patterns and agent limitations; avoidance of persuasive or emotive phrasing in safety-critical flows; plan-deviation detection; ASI08 adds a “governance drift cascade” scenario (oversight loosens after a run of successes → bulk approvals → uncontrolled configuration drift) | Strong | Strong | The row most worth integrating first: IMDA supplies the oversight-effectiveness metrics, OWASP the product mechanisms that reduce oversight load and bias. Absent either one, the control degrades into rubber-stamping. |
| D. Human Oversight | C22 Human factors and interface security | §2.4.2: the interface must state up front, at the point of interaction, that the user is dealing with an agent (this may not be disclosed only in a separate document); disclose the scope of actions the agent is authorised to take; provide a named escalation contact | ASI09: plain-text risk summaries in place of model-generated rationales; risk badges showing provenance and expected side effects; separation of preview from commit (preview mode blocks network and state-changing calls); visual differentiation of high-risk recommendations (red borders, banners, secondary confirmation); content provenance metadata (source ID, timestamp, integrity hash); digital-signature verification and runtime policy blocking of actions that lack a trusted source or exceed scope | Partial | Strong | IMDA reaches only as far as “inform”, OWASP as far as “prevent misjudgement”. Customer-facing agent interfaces should satisfy both sets of requirements. |
| E. Testing, Monitoring & Resilience | C23 Pre-deployment testing and evaluation | §2.3.2 sets out four testing dimensions (end-to-end task execution; policy compliance, that is whether SOPs are followed and human approval is routed when required; tool invocation, that is whether the correct tool, permissions, inputs and sequence are used; robustness); test the complete workflow rather than the final output alone; single-agent testing plus multi-agent system-level testing; test in a production-like environment; test repeatedly across diverse datasets (including small perturbations and stability re-runs); for evaluation at scale, use a hybrid approach with LLM / agent judges plus a human in the loop | No standalone testing chapter; testing requirements are scattered: ASI01 mitigation 13 (periodic red teaming simulating goal override); ASI05 mitigation 2 (pre-release security assessment and adversarial unit tests); ASI06 mitigation 7 (adversarial testing); ASI08 mitigations 8–9 (a digital twin replaying recorded actions in an isolated production clone, with a blast-radius ceiling gating any grant of further autonomy) | Strong | Partial | IMDA provides the testing methodology, OWASP the test content and the source of test cases (148 controls plus the 24 real-world incidents in Appendix D). Combined, they constitute a complete test plan. |
| E. Testing, Monitoring & Resilience | C24 Red teaming and threat modelling | §2.1.1 threat modelling generates contextualised threat events and must be updated periodically, supported by taint tracking; §2.2.1 makes the cybersecurity team accountable for periodic red teaming and threat modelling; the GovTech case study uses red teaming to validate guardrail effectiveness | ASI01 mitigation 13 periodic red teaming; the document is organised from the attacker’s perspective and gives an attack scenario for every entry; Appendix D lists 24 real-world incidents (EchoLeak, ForcedLeak, the malicious postmark-mcp, Replit, an A2A man-in-the-middle, Cursor RCE and others) and is maintained weekly; the threat-modelling methodology itself is delegated to a separate Agentic Threat Modelling Guide | Partial | Strong | IMDA mandates that it be done, OWASP supplies what to do. Recommend converting the attack scenarios in ASI01–ASI10 and the Appendix D incidents directly into a red-team scenario library. |
| E. Testing, Monitoring & Resilience | C25 Logging, observability and tamper-proof audit | §2.3.3 specifies explicitly what to log (prioritising high-risk activity such as database modification and payments); multi-layer monitoring (user–agent, agent–tool, model inference); step-by-step logs and traces covering agent-to-agent interaction; integration with an observability platform and OpenTelemetry; logs must be tamper-proof (failure traces must not be deletable); §1.1.1 lists logging and monitoring as core agent components | ASI02 (tamper-proof tool-call logs); ASI08 (tamper-resistant, timestamped logs of inter-agent messages, policy decisions and execution results, bound to a cryptographic agent identity, with lineage metadata attached to every propagated action); ASI09 (tamper-proof logs of user queries and agent actions); ASI10 (complete, immutable, signed audit logs, reviewed for covert infiltration and unapproved delegation); the document declares observability to be “non-negotiable” | Strong | Strong | Both reach the same conclusion. The difference is that OWASP requires logs to be bound to a cryptographic identity and to carry lineage metadata — the precondition for forensics and accountability, and recommended for adoption. |
| E. Testing, Monitoring & Resilience | C26 Runtime monitoring, anomaly detection and drift | §2.3.3 defines three classes of alert threshold (programmatic thresholds such as unauthorised access and repeated failed tool calls; outlier and anomaly detection; agents monitoring agents); define the intervention for each alert type; continuous testing to address model drift; feedback loops that flow back into the training data and the evaluation framework | ASI01 (behavioural baselines: goal state, tool-usage patterns, invariants; stable active-goal identifiers with drift alerting); ASI02 (drift detection and anomalies over chained tool calls); ASI08 (behavioural and governance drift detection: deviation of decisions from the baseline and from alignment, alerting on gradual degradation); ASI09 (detection of sensitive-data exposure behaviour within sessions and during execution, plan-deviation detection); ASI10 (watchdog agents, detection of collusion and of coordinated signal forgery, behavioural integrity baselines) | Strong | Strong | Both are strong. OWASP’s concept of “governance drift” (oversight loosening as successes accumulate) is an important addition to the metric set in IMDA §2.2.2. |
| E. Testing, Monitoring & Resilience | C27 Circuit breakers, termination, quarantine and recovery | §2.1.2 design a decommissioning mechanism and limit the blast radius; §2.3.3 high-priority alerts may pause execution, and termination and fallback options should be considered in the event of catastrophic failure or compromise | ASI10: kill switches and credential revocation to disable a rogue agent immediately; quarantine of suspect agents in a sandbox for forensic review; a trusted baseline for recovery; re-attestation, dependency verification and human approval before readmission to production; ASI04: a supply-chain kill switch (emergency revocation across all deployments); ASI08: circuit breakers, quotas and progress ceilings | Partial | Strong | IMDA stops at “terminate and fall back”, OWASP adds quarantine forensics and a readmission gate. The incident-response process should adopt OWASP’s full closed loop. |
| E. Testing, Monitoring & Resilience | C28 Change management and version control | §2.3.3 (new in v1.5): four classes of change-review trigger (technical, such as model updates and tool modifications; environmental, such as domain drift and business change; performance, such as anomalies and degradation; regulatory, such as changes in compliance requirements); changes are tiered by risk — minor (prompt tweaks) receive a lightweight review, substantive (model updates, autonomy adjustments) a full governance review, and critical (affecting high-risk decisions) trigger an immediate re-run of the risk assessment | ASI01 (changes to goals and rewards must pass through configuration management and human approval); ASI04 (prompts, orchestration scripts and memory schemas under version control with peer review; reproducible builds; content-hash and commit pinning; staged rollout plus differential testing plus automatic rollback); ASI06 (memory snapshots and rollback, version control); ASI10 (behavioural integrity baselines spanning the lifecycle) | Strong | Partial | IMDA’s triggers and tiering are the governance entry point, OWASP’s version control and automatic rollback the technical exit. Recommend listing “autonomy adjustment” explicitly as a substantive change requiring sign-off. |
Risk view · 17 harmonised risk themes
Rows = harmonised risk themes; the two middle columns give each document's native wording and source reference; the coverage columns are colour-coded per the legend (Strong / Partial / Weak / None).
| Group | Theme | IMDA wording and source | OWASP wording and source | IMDA coverage | OWASP coverage | Note |
|---|---|---|---|---|---|---|
| Adversarial | Goal hijack / intent tampering | §1.2.1 semantic misalignment and hallucination at the planning and reasoning layer; at the tool layer, “prompt or code injection can manipulate an agent into exfiltrating or altering data”; §1.2.2 unauthorised actions | ASI01 Agent Goal Hijack: goals, task selection and decision paths are altered through prompt manipulation, deceptive tool output, malicious artefacts, forged agent messages or poisoned external data | Partial | Strong | IMDA identifies the source of this risk but does not develop it into an itemised control family; OWASP sets out 15 mitigations (locked system prompts, a stable active-goal identifier with drift alerting, signed intent-capsule envelopes, and others). |
| Adversarial | Tool misuse and out-of-scope invocation | §1.2.1 tool-related risks: hallucinating tools that do not exist, selecting the wrong tool, passing the wrong input to the right tool, biased tool invocation | ASI02 Tool Misuse and Exploitation: unsafe use of legitimate tools within an already authorised scope, leading to exfiltration or workflow hijacking through chained invocation, dynamic tool selection and delegation | Partial | Strong | IMDA treats this as “error”, OWASP as “an attack surface that can be induced”; the latter therefore adds controls such as egress allow-listing, tool budgets, a semantic firewall and fail-on-ambiguity. |
| Adversarial | Identity and privilege abuse | §1.2.2 unauthorised actions (at the consequence level); §2.1.2 treats identity and authorisation as controls rather than as a risk entry | ASI03 Identity and Privilege Abuse: exploiting delegation chains, role inheritance, cached credentials and session history to escalate privilege, hijack identities or perform unauthorised actions across systems | Partial | Strong | IMDA places this on the control side (the five agent-identity requirements); OWASP places it on the risk side and supplies detection items (anomalous cross-agent privilege escalation, device-code phishing flows). |
| Adversarial | Supply chain and third-party components | §2.1.1 likelihood factor 9 (“provided or operated by an external party”); the OpenClaw case study names “supply-chain risk in third-party skills”; §2.3.1 MCP server allow-listing | ASI04 Agentic Supply Chain Vulnerabilities: models and weights, plugins, datasets, other agents, MCP/A2A interfaces, registries and update channels can all be poisoned at source, and are assembled at runtime | Weak | Strong | IMDA offers only two touchpoints, the risk factor and the allow-list; OWASP provides SBOM/AIBOM, signed attestations, hash and commit pinning, staged release with automatic rollback, and a supply-chain kill switch. |
| Adversarial | Unexpected code execution (RCE) | §2.3.1 protocol control (“sandbox any code execution”); §2.1.2 place high-risk tasks such as code execution in a self-contained environment | ASI05 Unexpected Code Execution: agents that generate and run code (including vibe coding) give rise to RCE, local abuse or sandbox escape through prompt injection, tool misuse or insecure deserialisation | Weak | Strong | IMDA has a single sandboxing requirement; OWASP sets out seven groups of controls, including no eval in production, non-root execution, separation of code generation from execution, version control of the allow-list for automatic execution, and static scanning before execution. |
| Adversarial | Memory and context poisoning | The §2.1.1 threat-modelling passage names “memory poisoning”; the OpenClaw case study names it again; §2.3.1 offers only “restrict memory shared between agents” | ASI06 Memory & Context Poisoning: persistent contamination of summaries, embeddings, RAG stores, session history and memory tools, skewing subsequent reasoning, planning and tool invocation or assisting exfiltration | Weak | Strong | The weakest item on the IMDA side — two mentions, no control family. OWASP provides validation before write, provenance attribution, tenant namespacing, trust weighting and decay, snapshot rollback, and a prohibition on automatically feeding an agent's own output back into memory. |
| Adversarial | Insecure inter-agent communication | §2.3.1 multi-agent controls: replace free text with structured schemas / typed function calls; restrict shared memory | ASI07 Insecure Inter-Agent Communication: weak authentication, integrity, confidentiality or authorisation allows messages to be intercepted, altered, forged or blocked; covers the transport, routing, discovery and semantic layers as well as covert side channels | Weak | Strong | Two IMDA controls against nine groups of OWASP controls (signing, mTLS, anti-replay nonces, protocol-version pinning, protection of discovery and routing, signed agent cards, typed contracts). |
| Adversarial | Loss of control / rogue agents | §1.2.3 agent sprawl, collaboration failure (misalignment, conflict, collusion), unpredictable and emergent behaviour | ASI10 Rogue Agents: autonomous deviation without an external attacker in continuing control, including covert infiltration, unapproved delegation, collusion and forged signals | Partial | Strong | IMDA views sprawl and collaboration failure from a governance standpoint; OWASP takes a technical standpoint and provides signed behaviour manifests, a behaviour-verification layer, periodic attestation through challenge tasks, a watchdog agent, quarantine forensics and criteria for reinstatement. |
| Non-adversarial | Erroneous actions / business error from hallucination | §1.2.2 erroneous actions: for example booking an appointment on the wrong date, or writing defective code; the harm depends on the specific action | No standalone entry (treated as a consequence of ASI01/ASI06, or delegated to LLM09 Misinformation in the LLM Top 10) | Strong | Weak | This item is IMDA's net addition. In financial settings a large share of actual losses arises from execution errors with no adversary involved; using OWASP alone would leave no corresponding entry and no acceptance criteria. |
| Non-adversarial | Bias and unfairness | §1.2.2 biased or unfair actions: procurement vendor selection, award of subsidies, hiring decisions | No corresponding entry | Strong | None | OWASP organises its content by attack surface, and fairness falls outside its scope. This must be carried by IMDA together with local regulation (for example the MAS/FEAT principles). |
| Non-adversarial | Cascading and compounding failure | §1.2.3 cascading or compounding effects: a single-step error propagates and is amplified in subsequent steps (a hallucinated inventory figure → incorrect replenishment) | ASI08 Cascading Failures: concerned with the propagation and amplification of a failure rather than its origin; provides quotas, progress ceilings, circuit breakers, digital twin replay, and behavioural and governance drift detection | Partial | Strong | Both identify the risk, but OWASP supplies implementable blast-radius controls and detection hooks (and states explicitly that ASI08 applies only where a defect spreads across agents). |
| Non-adversarial | Damage to connected systems | §1.2.2 damaging connected systems: for example deleting a production code repository, or overwhelming an external system with a flood of requests | Dispersed across ASI05 (host/container compromise, persistence) and ASI08 (failure propagation, rate limits and quotas) | Strong | Partial | IMDA has a distinct risk type; OWASP has no entry of the same name but its controls are more granular (egress control, rate limiting, circuit breakers). |
| Non-adversarial | Multi-agent misalignment / conflict / collusion | §1.2.3 misalignment (differing interpretations of user intent), conflict (each optimising a different objective), collusion (apparent coordination that was never instructed, such as pricing agents converging on a higher price) | ASI10 mentions collusion patterns and the detection of coordinated forged signals, but presupposes an adversary or a deviation; it takes no view on algorithmic price collusion | Strong | Partial | Algorithmic collusion engages competition-law compliance and is a governance and legal matter that OWASP does not address. This is unique to IMDA and carries direct regulatory implications for financial institutions. |
| Non-adversarial | Agent sprawl / shadow agents | §1.2.3 agent sprawl: disorderly expansion without central management, unknown provenance, incompatibility between old and new versions; §2.1.2 requires identities to be centrally catalogued and promptly withdrawn | No direct entry; touched on only indirectly by ASI04 (“inventory of AI components and a policy-governed registry”) | Strong | Weak | IMDA treats this as a governance problem (central registration and withdrawal), OWASP as a supply-chain problem (registry and allow-list). Joining the two would yield a standard for an agent inventory. |
| Human & Org | Exploitation of human-agent trust / automation bias | §1.2.3 sustained human oversight gives rise to automation bias and alert fatigue; §2.2.2 override rate, response time, outlier approvers, chain of thought not necessarily being faithful | ASI09 Human-Agent Trust Exploitation: human misjudgement or over-reliance is exploited; adaptive trust calibration, confidence cues, separation of preview from commit, risk badges, plan-deviation detection | Strong | Strong | Both sides are strong and complementary — this is the row in the whole table that most warrants priority integration: IMDA supplies the metrics, OWASP the mechanisms. |
| Human & Org | Skill degradation and business continuity | §2.4.3 loss of tradecraft: agents taking over entry-level tasks erodes skills, so that in a failure no one is able to execute the critical process manually; requires identifying the core competencies of each role and providing sufficient hands-on exposure | No corresponding entry | Strong | None | New in IMDA v1.5, and a matter of organisational resilience. It is of direct input value to a financial institution's business continuity plan (BCP). |
| Human & Org | Systemic and concentration risk | §1.2.3 cross-boundary interaction (no white-box access to external systems); speed and scale make real-time interdiction difficult | An ASI08 scenario observes a regional DNS failure at a hyperscale cloud provider disrupting AI services across multiple organisations, but sets no governance requirement | Partial | Weak | A gap common to both. Financial institutions must additionally draw on systemic-risk material such as the FSB's Sound Practices for the Responsible Adoption of AI (see the FSB directory in this repository). |
Sources
| Document | Version / date | Note |
|---|---|---|
| IMDA, Model AI Governance Framework for Agentic AI | v1.5 · published 2026-05-20, updated 2026-06 | Infocomm Media Development Authority of Singapore; §2 is the body of the framework (4 dimensions, 9 sub-sections). |
| OWASP GenAI Security Project, Top 10 for Agentic Applications | 2026 (ASI series) | Agentic Security Initiative; ASI01–ASI10, 148 controls, Appendix D incident list. |
Both tables are extracted verbatim from the full comparison workbook (12 sheets), which additionally covers framework profiles, positioning, the structure map, the two reverse checks, the gap analysis and an 18-item integration action list.