Parties & Value Chain

The accountability challenge

“The organisations that deploy agents and the humans who oversee them remain accountable for the agents’ actions.” §2.2, p.25

But fulfilling that accountability is hard, for three reasons the framework names:

• agent actions “emerge dynamically and adaptively from interactions instead of fixed logic”;
• “multiple stakeholders may also be involved in different parts of the agent lifecycle, diffusing accountability”; and
• automation bias — over-trusting a system that has performed reliably before — grows as agents become more capable.

IMDA’s two responses frame this whole topic and the next:

• Clear allocation of responsibilities within and outside the organisation — establish chains of accountability across the value chain and lifecycle, with adaptive governance so the approach keeps pace as the technology evolves.
• Measures to enable meaningful human oversight — human approval at significant checkpoints, auditing the effectiveness of those approvals, and complementing them with automated monitoring. §2.2, p.25

The agentic AI value chain

“As deployers, organisations and humans remain accountable for the decisions and actions of agents. However … the value chain for agentic AI involves multiple actors.” So responsibility must be allocated both within the organisation and vis-à-vis other organisations along the chain. §2.2.1, p.25

Organisations may play multiple overlapping roles. “An organisation that develops its own agents and subsequently deploys them would play both the role of the system provider and the deployer.” §2.2.1, p.25 This is why a deployer cannot off-load accountability by pointing upstream — it may be the upstream party. interpretation

v1.5 refinement. The “What’s new” page records that v1.5 “refined the agentic AI value chain to separate platform providers and system providers or app developers” — so in v1.5 these are distinct roles; don’t conflate the platform an agent runs on with the application built on it. “What’s new”, p.5

(For a fuller stakeholder list the paper points to CSA & FAR.AI, Securing Agentic AI: A Discussion Paper.)

Internal teams & responsibilities

“Within the organisation, organisations should allocate responsibilities for different teams across the agent lifecycle.” The paper is explicit that its four-team split is illustrative — “while each organisation is structured differently, this is an illustration of how such responsibilities may be allocated.” §2.2.1, p.26 The “who” and responsibilities below are verbatim.

Key decision makersProduct teamsCybersecurity teamsUsers

Key decision makers

Who: Leaders who define strategic decisions and high-level policies for the organisation — e.g. board members, C-suite executives, managing directors, or department leaders.

Key responsibilities

• Setting high-level goals for use of agents
• Defining permitted operational use cases for agents, including limits on agent’s data access
• Setting the overall governance approach, including risk management frameworks and escalation processes

Worked example — PwC Singapore §2.2.1, pp.27–28

PwC’s AI Factory built an agentic app that drafts research/analysis sections of internal reports, using three coordinated agents (Planner → Researcher → Summariser) in a primarily sequential workflow with feedback loops, ending in human review.

Operating accountability is split across four roles:

• Use-case owner — use-case appropriateness & accountable use; “remains accountable for the responsible use of the application and for ensuring that appropriate human oversight is in place.”
• Technology Risk Management Team — risk assessment & control advice.
• AI Factory — design, development, guardrails, monitoring & change management.
• End users / SMEs — output review and approval; AI output is “a first draft intended to support, and not replace, professional judgement.”

The paper presents these four roles independently and does not map them onto the generic four-team table — they don’t correspond one-to-one (there is no cybersecurity-team analogue, for instance). interpretation

Adaptive governance. “All teams involved in agentic AI should also develop internal capabilities to understand the technology” — staying aware of new modalities (e.g. computer-use agents) and evaluation methods lets an organisation adapt its governance to new developments. §2.2.1, p.28

Working with external parties

Organisations may need to work with external parties — “model developers, agentic AI providers, or hosts of external MCP servers or tools” — and must “similarly ensure that there are measures in place to fulfil its own accountability.” §2.2.1, p.28 Two agent-specific considerations:

• Clarify the distribution of obligations in terms & conditions or contracts — covering security arrangements, performance guarantees, and data protection. “Where there are gaps, the organisation should reassess if the agentic deployment meets its risk tolerance.”
• Address third-party opacity. External agents “can be difficult to observe and control.” So: require transparency and accountability (disclosures on agent capabilities and data handling); request and evaluate technical control features — “scoped API keys, per-agent identity tokens, and observability such as the logging of tool calls and access history”; and where such features are lacking, “consider alternative or in-house solutions, or scoping down the agentic use case.”

interpretation The controls to demand from a vendor are the external-facing mirror of the deployer’s own least-privilege identity practices — if a vendor can’t offer them, you scope down the use case rather than accept the residual risk.

End-user archetypes

“Ultimately, end users are the ones who use and rely on agents, and human accountability also extends to these users.” §2.4, p.46 The paper splits them into two archetypes with different information needs:

This second group inherits all the transparency information above, then layers education and training on top. §2.4.3, p.47

Worked example — Workday §2.4, p.48

For internal finance/HR-agent users (e.g. a Recruiter Agent), Workday applies several transparency measures:

• The UI gives notice that the tool is AI-powered.
• Factsheets specify what each agent can and cannot do — reinforcing that users and HR remain in control.
• In sensitive workflows, the agent shows its reasoning, so users know where human judgment is required.

The accountability anchor

The deploying organisation and its humans are the fixed point of accountability, no matter how long the chain:

• “As deployers, organisations and humans remain accountable for the decisions and actions of agents.” §2.2.1, p.25
• Even with overlapping roles or external vendors, the deployer must “ensure that there are measures in place to fulfil its own accountability.” Where vendor controls are inadequate, the framework’s answer is to scope down or bring in-house — interpretation not to transfer accountability upstream.

Cross-reference — MAS MindForge (not IMDA text). For financial institutions, MindForge is the higher-authority source and sharpens which actor is on the hook: assign final accountability to the party with the most control over an action (MindForge p.128).

Under MAS, the FI remains accountable regardless of build-vs-buy, and MindForge itself points FIs to this IMDA framework — so the two are complementary, with MindForge governing where they meet. interpretation

---

Next — Topic 03: RACI Responsibility Assignment. This topic mapped who the parties are and where accountability sits. Topic 03 turns that into a concrete, calibratable RACI matrix across the framework’s four governance dimensions.