Appearance
Enable End-User Responsibility
Enable end-user responsibility is the fourth dimension of the IMDA Model AI Governance Framework for Agentic AI. It addresses the people who ultimately use and rely on agents. Human accountability — the subject of Dimension 2 — extends to these end-users, and the framework's premise here is that trustworthy deployment does not rest solely on developers: organisations should give end-users enough information to use agents responsibly, and enough retained skill to carry on when agents fail.
Dimension 4 has two operative moves. First, disclose the right things to users at the point of interaction so they can trust and properly use an agent. Second, for users who build agents into their own workflows, layer on education and training — including training that preserves tradecraft, the human ability to do the work manually when an agent is unavailable.
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, in the same spirit as the NIST AI Risk Management Framework.
Primary source
This page is a structured guide to §2.4 Enable end-user responsibility 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 authoritative text is the framework itself; this page summarises §2.4.2 (users who interact with agents) and §2.4.3 (users who integrate agents into their work processes) for orientation and shows how the duties map onto Modulos requirements MRF-318 and ORF-392.
Why trustworthy deployment does not rest solely on developers
The earlier dimensions of the framework place obligations on the organisations that design, build and operate agents. Dimension 4 closes the loop on the human side of deployment: end-users are the ones who use and rely on agents, so human accountability extends to them too. The framework asks organisations to provide sufficient information to end-users to promote trust and enable responsible use.
That information has two broad purposes. Transparency lets a user understand an agent's capabilities — the scope of its access to the user's data, the actions it can take — and know whom to escalate to if the agent malfunctions. Education lets a user apply proper oversight and guards against the slower harm of skill erosion: as agents take over more functions, basic operational knowledge can be eroded, so sufficient training should be provided to ensure humans retain core skills. The framework is careful to treat these as complementary, not interchangeable: education does not replace disclosure, and disclosure does not substitute for retained competence.
Disclose agent identity, authority, data use, and escalation
The disclosure baseline applies to every end-user, and the framework's instruction is that the fact the user is interacting with an agent should be declared upfront in the user interface, at the point of interaction, rather than only in separate documentation. The other disclosure facts are point-of-interaction information the framework asks organisations to provide, without specifying that each must live in the user interface. For users who interact with agents (§2.4.2), organisations should share information including:
| What to disclose | What it means | Source emphasis |
|---|---|---|
| Interaction | Declare upfront in the user interface that the user is interacting with an agent, at the point of interaction. | Not only in separate documentation. |
| Range of actions and decisions | Inform users of the range of actions and decisions the agent is authorised to perform and make. | Authorised action range. |
| Data | Be clear on how user data is collected, stored and used by the agent, in line with the organisation's data-privacy policies; obtain explicit consent where necessary. | Consent where required. |
| Human accountability and escalation | Provide the human contact points responsible for the agent, whom users can alert if the agent malfunctions or they are dissatisfied with a decision. | A named escalation route. |
| User's responsibilities | Clearly define the user's responsibilities, such as double-checking information the agent provides; where appropriate, allow users to set their own approval thresholds and boundaries beyond organisation-defined limits. | User recourse and personal thresholds. |
The Workday case study in the framework is illustrative of this pattern. Its agent interfaces give notice in the surface where the user already works — for example in Slack or Microsoft Teams — that the tool is AI-powered and supports a select range of actions, and its factsheets specify both what an agent can do and what it cannot do, reinforcing that users and HR remain in control. The agents also accompany recommendations in sensitive workflows with an explanation of their reasoning, including the data considered and any noted uncertainties. These are illustrative design choices, not framework requirements.
In the Modulos platform this disclosure baseline is carried by application-scope requirement MRF-318 — Disclose agent identity, authority, data use, and escalation. Its agentic-specific addition is control MCF-550 — Agent capability and escalation disclosure, which expects the disclosed action range to state both authorised actions and limits and to surface the escalation route at the point of interaction. MRF-318 also draws on the shared transparency library: MCF-47 — Transparency for Users, MCF-125 — Impersonation disclosure, MCF-162 — Transparent Interaction with Natural Persons, MCF-394 — Risk Communication and MCF-396 — User Interface Design.
Users who interact with agents vs users who integrate agents
The framework caters to two end-user archetypes with different information needs. The distinction matters because the second group inherits everything the first group needs and then adds to it.
| Archetype | Typical agents | Facing | Framework focus |
|---|---|---|---|
| Users who interact with agents (§2.4.2) | Customer-service, sales or HR agents acting on behalf of the organisation | Mostly external-facing (can be internal) | Transparency |
| Users who integrate agents into their work processes or oversee them (§2.4.3) | Coding assistants, enterprise-process automation, where the agent acts for and on behalf of the user | Mostly internal-facing | Education and training, in addition to transparency |
The framework states the additive relationship explicitly: for users who integrate agents, organisations layer education and training in addition to the transparency information above. The disclosure baseline is the floor for everyone; integrating users get a training layer on top.
Train integrating users on appropriate use and oversight
For users who integrate agents into their work processes, the framework groups the education and training into three areas:
- Foundational knowledge on agents — relevant use cases so users understand how to integrate agents into day-to-day work and the scenarios under which agent use should be restricted (for example, not using an agent for confidential data); instructing agents, including general prompting best practices; and the agent's range of actions, so the user is aware of its capabilities and potential impact.
- Effective oversight of agents — common agent failure modes such as hallucinations or getting stuck in loops after errors, so users can identify and flag issues; ongoing support such as refreshers on the latest features and common mistakes; and feedback loops, so that when users override agent actions or identify wrong actions they can report them and the reports can be used to improve the agent.
- Potential impact on tradecraft and business continuity — addressed in the next section.
In Modulos these duties live in organisation-scope requirement ORF-392 — Train integrating users and preserve manual fallback competence. The agentic-specific training control is OCF-299 — Agentic oversight and user training, whose curricula cover both designated overseers (failure modes, the limits of agent reasoning traces, and how to evaluate an approval request critically rather than rubber-stamp it) and integrating users (which use cases are permitted or restricted, prompting practices, the agent's range and limits, and how to report problems and override actions). General literacy is provided by the shared control OCF-44 — AI Literacy and Awareness, and the competence controls OCF-109 — Competence determination, OCF-110 — Competence assurance and OCF-111 — Competence development ensure the right people are trained and kept current.
Preserve manual fallback competence (tradecraft continuity)
The framework's most distinctive contribution in this dimension is its attention to tradecraft. As agents take over entry-level tasks — which typically also serve as training for new staff — this can lead to skill degradation, in which users lose basic operational knowledge. The consequence is operational, not merely educational: it can create business-continuity risks in which users may no longer know how to perform critical processes manually when agents malfunction or become unavailable.
The framework's instruction is concrete: organisations should identify the core capabilities of each job and provide sufficient training and work exposure so that users retain foundational skills. In Modulos this is the agentic-specific control OCF-297 — Human tradecraft continuity, held under ORF-392. The control's pattern is to identify the roles where agentic AI is deployed, identify per role the core capabilities the agent now performs, determine which capabilities would create business-continuity exposure if eroded (could the work be done manually if the agent were unavailable?), and define training, exercises or work-exposure programmes with retained-competence thresholds — for example drill pass criteria, a target manual-fallback time, or a certification-currency window.
Tradecraft continuity is distinct from AI literacy
It is worth holding these two ideas apart, because they answer different questions:
| AI literacy | Tradecraft continuity | |
|---|---|---|
| What it is | The capability to work with AI | The retained human skill to do the work without AI |
| The question it answers | Can the user instruct and oversee the agent competently? | Can the user perform the critical process manually if the agent fails? |
| Modulos control | OCF-44 — AI Literacy and Awareness | OCF-297 — Human tradecraft continuity |
| Failure mode it guards against | Misuse, over- or under-reliance, poor oversight | Skill erosion that becomes a business-continuity risk on agent failure |
A workforce can be highly AI-literate and still have lost the manual tradecraft to operate when agents are down. That is why the framework names tradecraft separately, and why Modulos models OCF-297 as a distinct control rather than folding it into the literacy baseline. Tradecraft continuity is the human counterpart to the technical fallback controls elsewhere in the framework — emergency revocation, quarantine and circuit breakers govern the system; tradecraft continuity governs whether people can still carry the work.
How to operationalize Dimension 4 in Modulos
Dimension 4 spans both template scopes: per-application disclosure sits in MFF-17 (app), and tenant-wide training and tradecraft sit in OFF-17 (org). The two requirements are evidenced the same way as every Modulos requirement — through mapped controls and evidence, a readiness signal, and owner-attested fulfilment, not through reviews. (Reviews record control-status changes; requirement status is owner-attested.)
| Requirement | Scope | Covers | Agentic-specific controls | Shared / baseline controls |
|---|---|---|---|---|
| MRF-318 — Disclose agent identity, authority, data use, and escalation | Application (MFF-17) | Point-of-interaction disclosure of identity, authority, data use, escalation and user responsibilities | MCF-550 (agent capability and escalation disclosure) | MCF-47, MCF-125, MCF-162, MCF-394, MCF-396 |
| ORF-392 — Train integrating users and preserve manual fallback competence | Organisation (OFF-17) | Training for integrating users and overseers; preservation of manual fallback competence | OCF-297 (human tradecraft continuity), OCF-299 (agentic oversight and user training) | OCF-44, OCF-109, OCF-110, OCF-111 |
To put Dimension 4 in place:
- Build the disclosure into the product surface. Surface, at the point of interaction, that the user is interacting with an agent, the agent's authorised action range and its limits, how user data is handled (with consent where required), the named escalation route, and the user's own responsibilities. Map this to MRF-318; attach the in-product disclosure artefact (screenshot or design) as evidence against MCF-550, then attest fulfilment.
- Separate the two user populations. Confirm whether the application's users are interacting users, integrating users, or both; integrating users inherit the disclosure baseline and require the training layer.
- Stand up agent-specific training. Under ORF-392, deliver and record OCF-299 curricula for overseers and integrating users — distinct from a relabelled generic AI-awareness course — with a refresher cadence and an ad-hoc-retraining trigger.
- Run the tradecraft programme. Identify at-risk core capabilities per role, define retained-competence thresholds, and evidence training, drills or work exposure against OCF-297; carry the competence lifecycle through OCF-109/110/111. Attest ORF-392 fulfilment with the rationale captured in the requirement's comments and logs.
- Feed overrides back. Ensure the override and incident-reporting path taught to users is the same path that reaches the people who can act on it, so reports drive remediation loops rather than disappearing.
For the end-to-end operating model across both templates, see Operationalizing the MGF for Agentic AI in Modulos.
Cross-framework mapping (preview)
Dimension 4 sits adjacent to the user-facing and competence provisions of several frameworks that organisations commonly adopt alongside the MGF for Agentic AI:
- OWASP Top 10 for Agentic Applications — disclosure of an agent's authority and the user's recourse complements OWASP's treatment of excessive agency and over-reliance on autonomous agents.
- ISO/IEC 42001:2023 — the training and competence duties correspond at a high level to the framework's competence, awareness and resourcing requirements; the Modulos competence controls (OCF-109/110/111) already serve those obligations.
- NIST AI RMF — end-user disclosure, feedback capture and post-deployment user engagement align loosely with the framework's Govern and Manage outcomes.
Preview
These are high-level adjacencies only. Cross-framework reuse in Modulos is implicit at the control layer — several controls referenced here also serve other frameworks. Detailed control-by-control mappings are not asserted on this page; in particular, no EU AI Act Article-level mapping is claimed.
Related pages
MGF for Agentic AI overview
The four dimensions, the agentic risk taxonomy, and how the framework maps to Modulos
Ensure human accountability (Dimension 2)
Value-chain responsibility allocation and meaningful human oversight — the accountability this dimension extends to end-users
Operationalizing the MGF for Agentic AI in Modulos
The MFF-17 / OFF-17 operating model across application and organisation scope
Source attribution
This page summarises §2.4 (Enable end-user responsibility), including §2.4.2 and §2.4.3, 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 Workday case study referenced is an illustrative example drawn from the framework, not a framework requirement. Requirement and control codes (MRF-318, ORF-392, and their mapped MCF/OCF controls) refer to the Modulos platform templates MFF-17 and OFF-17, which adapt the framework for operational use.
Disclaimer
The IMDA Model AI Governance Framework for Agentic AI is voluntary best-practice guidance, not a law or regulation, and adopting it is not mandatory. Where the Modulos platform labels the MFF-17 / OFF-17 templates as "Regulation", that is a platform-template artefact and not a legal characterisation of the framework. This page reproduces and summarises publicly available IMDA guidance for orientation and operational use; the authoritative source is the framework text itself. This page does not constitute legal advice.