Make Humans Meaningfully Accountable

Dimension 2 of Singapore's Model AI Governance Framework for Agentic AI (the MGF for Agentic AI) addresses a problem that agentic systems sharpen: keeping humans genuinely accountable for actions that an agent generates dynamically, rather than from fixed logic. It works on two fronts — allocating responsibility clearly within the organisation and across the agentic value chain, and designing human oversight that stays meaningful as agents become more capable. This page covers the value-chain and internal responsibility split, the four categories of approval checkpoint, the anti-rubber-stamping metrics that keep oversight honest, agent red-teaming and threat modelling, and third-party component assessment — and how each maps to the Modulos templates.

The MGF for Agentic AI is voluntary best-practice guidance published by IMDA. It is not a law, a regulation, or a mandatory standard. Read it as a structured set of recommendations for organisations deploying agentic AI, in the same spirit as the NIST AI Risk Management Framework.

Primary source

This page is a structured guide to Dimension 2 ("Make humans meaningfully accountable") of the IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant text is §2.2.1 (clear allocation of responsibilities within and outside the organisation) and §2.2.2 (design for meaningful human oversight); red-teaming and workflow testing draw on §2.3.2, while agentic threat modelling and taint tracing draw on §2.1.1. The framework's only explicit IMDA cross-reference is to the earlier Model AI Governance Framework (2nd Edition, 2020); the company case studies and adapted resources are illustrative.

Three challenges to human accountability for agents

The framework opens Dimension 2 by naming why accountability is harder for agents than for conventional AI, and these three challenges shape everything that follows:

• Emergent action. Agent actions emerge dynamically and adaptively from interactions, instead of from fixed logic, so it is harder to predict — and afterwards to reconstruct — why an agent did what it did.
• Diffused accountability. Multiple stakeholders are involved in different parts of the agent lifecycle, which can diffuse accountability across the value chain unless ownership is made explicit.
• Automation bias. As humans supervise increasingly capable agents, the tendency to over-trust a system that has performed reliably in the past becomes a larger risk — compounded by alert fatigue and anthropomorphic design.

The framework's response is twofold: clear allocation of responsibilities, paired with adaptive governance so the organisation can update its approach as the technology evolves; and measures that make human oversight meaningful — human approval at significant checkpoints, auditing of approval effectiveness, and automated monitoring as a complement.

Allocate responsibilities across the agentic value chain

As deployers, organisations and the humans who oversee agents remain accountable for the decisions and actions of those agents. But, as with conventional AI, the value chain involves multiple actors. The framework describes a simplified agentic AI value chain:

Role	Typical contribution
Model developers	Build the underlying models the agents reason with
Tooling providers (for example MCP servers, APIs)	Supply the tools and connectors agents call
Platform providers	Provide the runtime or orchestration platform
System providers / app developers	Compose models, tools, and instructions into an agentic application
Deployer	Puts the agentic system into operational use and remains accountable for its actions
End users	Use the agent's outputs to contribute to an organisational goal

An organisation may play several of these roles at once. A firm that develops its own agents and then runs them is both the system provider and the deployer. The deploying organisation's job is to establish chains of accountability across the value chain and the lifecycle, and to keep that allocation current as the technology changes.

Allocate responsibilities within the organisation

Within the organisation, responsibilities are allocated across the agent lifecycle. Every organisation is structured differently, but the framework offers an illustrative split across four archetypal teams:

Internal role	Illustrative accountabilities
Key decision makers (board, C-suite, department leaders)	Set high-level goals for agent use; define permitted operational use cases, including limits on agents' data access; set the overall governance approach, risk-management frameworks, and escalation processes
Product teams (product managers, designers, AI and software engineers)	Define agent design, requirements, feature controls, and phased rollouts; implement agents reliably across development, pre-deployment testing, and post-deployment monitoring; educate users on responsible use
Cybersecurity teams (CSO, security specialists, penetration testers)	Define baseline security guardrails and secure-by-design templates for technical teams to adapt; conduct regular red-teaming and threat modelling
Users (employees acting on agent outputs)	Use agents ethically and responsibly; attend required training; comply with usage policies; report bugs and issues in a timely manner

The framework also emphasises adaptive governance: all teams involved in agentic AI should build internal capability to understand the technology — new modalities such as computer-use agents, new evaluation frameworks — so the organisation can update its governance approach as developments arrive. (The PwC Singapore report-drafting example allocates accountability across a use-case owner, a technology risk team, the building team, and reviewing subject-matter specialists. This is illustrative of how the split can look in practice, not a framework requirement.)

Clarify obligations with external parties and address third-party opacity

When deploying agents, organisations often work with external parties — model developers, agentic AI providers, or hosts of external MCP servers and tools. To preserve their own accountability, the framework recommends two agent-specific measures:

• Clarify the distribution of obligations in any terms, conditions, or contracts with the external party — in particular provisions on security arrangements, performance guarantees, and data protection. Where there are gaps, the organisation should reassess whether the agentic deployment still meets its risk tolerance.
• Address third-party opacity. Externally provided agents can be hard to observe and control, making it unclear what they are grounded on, what they infer from conversations, or how data is stored and used. Organisations should require transparency and accountability from external parties (disclosures on capabilities and data handling) and request and evaluate technical security and control features — scoped API keys, per-agent identity tokens, and observability such as logging of tool calls and access history. Where these are lacking, consider alternative or in-house solutions, or scope the use case down (for example, restricting access to sensitive data).

End users sit at the far end of this chain. Organisations should give users enough information to hold the organisation accountable, and information about the user's own responsibilities — covered in detail under Enable end-user responsibility.

Design for meaningful human oversight

§2.2.2 sets out a three-step pattern for effective human supervision: define significant checkpoints or action boundaries that require human approval; train humans to evaluate those requests effectively and audit the approvals; and complement them with automated monitoring and predefined alert thresholds. The aim is oversight that stays meaningful at scale — not an approval button that humans press by reflex.

Approval checkpoints: high-stakes, irreversible, outlier, user-defined

Organisations should define significant checkpoints or action boundaries that require human approval, especially before sensitive actions execute. The framework names four categories:

• High-stakes actions and decisions — for example editing sensitive data, final decisions in high-risk domains such as healthcare or legal, and actions that may trigger liability.
• Irreversible actions — permanently deleting data, sending communications, or making payments.
• Outlier or atypical behaviour — an agent accessing a system or database outside its work scope, or selecting a delivery route twice as long as the median distance.
• User-defined boundaries — where agents act on behalf of users with different risk appetites, users may set their own thresholds, such as requiring approval for purchases above a chosen amount.

Beyond when approval is required, the framework asks organisations to design what form it takes. Keep approval requests short, contextual, and digestible while making the risk clear — surfacing the associated risk or a confidence score rather than long logs or raw data. Match the input form to the action: a simple approve or reject for straightforward actions such as a database read; an editable plan for complex cases such as reviewing an agent's plan before execution; and a written justification for high-risk actions before approving or rejecting.

Keep oversight effective: training, auditing, override metrics

Because humans remain susceptible to alert fatigue and automation bias, the framework recommends measures to ensure oversight stays effective over time:

• Audit the effectiveness of human oversight by tracking measurable indicators. The human override rate — how often humans reject or modify agent actions — is a primary signal; a persistently low rate may indicate rubber-stamping. Human response times during review are a second signal; a persistently short time may indicate automation bias or review fatigue. Data analytics can also surface outlier reviewers whose decision patterns deviate significantly from the norm, which may indicate compromised oversight.
• Train human overseers to identify common failure modes and agent limitations — inconsistent reasoning, reliance on outdated policies — and bear in mind that chain-of-thought reasoning, sometimes offered for explainability, is not analogous to human reasoning and may not faithfully explain the agent's actions.
• Ensure overseers have the domain expertise to evaluate the actions they approve; a user "vibe coding" with an agent may lack the software-engineering expertise to review the generated code's robustness.
• Complement human approval with automated real-time monitoring that escalates unexpected behaviour — alerts on logged events (such as attempted unauthorised access or repeated failed tool calls), anomaly detection on agent trajectories, agents monitoring other agents, and denying actions by default when approval infrastructure fails or no established approval policy covers a new action.

Red-team agents and maintain agentic threat-modelling artefacts

The framework places regular red-teaming and threat modelling with cybersecurity teams (§2.2.1), and §2.3.2 sets out how agentic testing differs from classical software and LLM testing, while threat modelling and taint tracing are introduced under §2.1.1. Two distinct artefacts result, and both are maintained:

• Red-team reports record what attacks were attempted and what succeeded. Testing should cover whole agent workflows (including reasoning and tool calling, not just final output), test agents individually and together to surface emergent multi-agent behaviour, run in realistic environments that mirror production, and repeat at scale across varied datasets to catch low-probability, high-impact behaviour.
• Threat-modelling artefacts record the attack paths in the design — how an attacker could compromise the system through the agent's planning loop, memory, tool descriptors, or inter-agent handoffs. A central technique is taint tracing: following how untrusted data can move through the system to a consequential action, recording the trust boundary at each hop. This is distinct from a red-team report.

Rather than a fixed annual cadence, the framework's risk emphasis favours a risk-tiered cadence: higher-risk action-space and autonomy cells warrant more frequent testing, with additional runs triggered on material change (new tools or protocols, new data sources, autonomy or topology changes, published attack techniques, or incidents).

Assess third-party agent components

Where an agentic system relies on third-party components — externally provided agents, MCP servers and other tool servers, models, and tooling — each should be assessed before use for transparency and control, and the decision to proceed, scope down, or substitute should be recorded. For each component the assessment covers its disclosed capabilities and limitations; its data-handling practices (what is collected, where it is stored, how it is used and retained); and the security and control features available (authentication strength, scoped credentials or per-agent identity, and observability of its actions). The acceptance bar is set per risk tier; where a component falls short, the required outcome is to scope down the use case, substitute the component, or bring the capability in-house — with the decision and its owner recorded.

How to operationalize Dimension 2 in Modulos

Modulos models the MGF for Agentic AI as two framework templates: MFF-17 (the application template, per build-and-operate obligations) and OFF-17 (the organisation template, tenant-wide governance). Dimension 2 lands across three requirements:

Requirement	Template	What it carries	Mapped controls
ORF-389 — Allocate value-chain and internal responsibilities for agentic AI	OFF-17 (org)	Value-chain allocation, internal RACI across the four team archetypes, escalation processes, secure-by-design templates, and third-party contracts (security, performance, data protection)	OCF-1, OCF-2, OCF-11, OCF-54, OCF-131, OCF-154, OCF-170, OCF-249, OCF-251, OCF-259
MRF-313 — Design and audit meaningful human oversight	MFF-17 (app)	Approval checkpoints by category, approval form per action class, anti-rubber-stamping metrics, automated monitoring, and deny-by-default behaviour	MCF-131, MCF-309, MCF-332, MCF-379, MCF-394, MCF-396, MCF-404, MCF-518, MCF-526, MCF-548
MRF-319 — Red-team agents and assess third-party components	MFF-17 (app)	Risk-tiered red-teaming, agentic threat-modelling artefacts (taint tracing), and third-party component transparency assessment	MCF-71, MCF-319, MCF-334, MCF-349, MCF-352, MCF-354, MCF-520, MCF-552, MCF-553

A few points worth knowing when working with these requirements:

• The org / app split is deliberate. ORF-389 holds the tenant-wide responsibility allocation and supplier contracts; MRF-313 and MRF-319 hold the per-application oversight and red-teaming work. Do not duplicate an obligation across both templates — each duty lives on one side.
• The agentic-specific controls are the operative additions. On MRF-313, MCF-548 (oversight-effectiveness metrics — override rate, response time, outlier-reviewer detection) and MCF-526 (trust-aware approval UX, including side-effect-free preview to prevent consent laundering) are the agentic adds; the rest are baseline controls shared with other frameworks. On MRF-319, MCF-552 (agentic threat modelling) and MCF-553 (third-party agent component transparency) are the agentic adds. MCF-552's taint-tracing artefact is distinct from the red-team reports captured under MCF-334/MCF-349.
• Requirements are evidenced through readiness plus owner-attested fulfilment, not reviews. When all linked controls reach a final state, the requirement becomes ready for review as a signal to its owner; the owner then attests fulfilment, with rationale captured in the requirement's comments and logs. Reviews in Modulos govern control status changes (and other reviewable objects), not requirements themselves. Where a metric threshold fires or a third-party gap is found, the resulting fixes run through remediation loops.
• Risk scoping is not tag-driven. All thirteen MFF-17/OFF-17 requirements carry empty requirement tags. The action-space × autonomy classification and the impact × likelihood risk-cell rubric — encoded in MCF-545, MCF-546, and MCF-547 — set the risk tier that, in turn, drives the depth of oversight and the red-teaming cadence under Dimension 2.

For the full operating model across both templates, see Operationalizing the MGF for Agentic AI in Modulos.

Cross-framework mapping (preview)

Preview

Dimension 2 sits adjacent to several frameworks many organisations adopt alongside the MGF for Agentic AI, at a high level only:

• OWASP Top 10 for Agentic Applications — the meaningful-oversight and approval-UX work (trust-aware confirmation, side-effect-free preview) is adjacent to the OWASP agentic threat classes around unsafe approvals and consent laundering.
• ISO/IEC 42001:2023 — responsibility allocation, roles, and supplier governance correspond to the management-system clauses on leadership, roles, and operational control.
• NIST AI RMF 1.0 — the accountability-structure and third-party themes map loosely onto the Govern function's accountability and supply-chain categories.

These are framework-level adjacencies. Detailed control-by-control mappings are out of scope here, and this page asserts no EU AI Act Article cross-references. Cross-framework reuse is implicit at the control layer, through the framework-agnostic controls shared with other templates.

Related pages

MGF for Agentic AI overview

The four dimensions, agentic components, and risk taxonomy in one place

Assess and bound risks (Dimension 1)

Action-space × autonomy classification, the impact × likelihood rubric, and bounding agent authority

Enable end-user responsibility (Dimension 4)

Agent identity disclosure, capability and escalation transparency, and user-side duties

Operationalizing in Modulos

Turn the four dimensions into MFF-17 / OFF-17 requirements, controls, and evidence

Source attribution

The authoritative source is the IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. This page draws on Dimension 2, §2.2.1 (clear allocation of responsibilities within and outside the organisation) and §2.2.2 (design for meaningful human oversight); red-teaming and workflow-testing material comes from §2.3.2, and the threat-modelling and taint-tracing material from §2.1.1. The framework's only explicit IMDA cross-reference is to the Model AI Governance Framework (2nd Edition, 2020). Company case studies (including PwC Singapore, Tencent, and X0PA) and adapted third-party resources referenced by the framework are illustrative and are not framework requirements.

Disclaimer

This page summarises and paraphrases publicly available IMDA guidance for orientation and operational use. The MGF for Agentic AI is voluntary best-practice guidance, not a law or regulation; nothing here is a legal characterisation of any obligation. The authoritative source is the IMDA Model AI Governance Framework for Agentic AI (v1.5). This page does not constitute legal advice.