Who is accountable when an AI agent acts?

A finance director authorises an assistant to prepare supplier payments. An engineer connects it to the accounting platform. A vendor supplies the model. A member of staff approves the resulting batch. If the assistant changes a beneficiary before submission, the organisation needs to establish who authorised that change, who could prevent it and who can recover the money.

This is an illustrative situation, but it exposes a practical problem. Naming a human supervisor does not allocate all the responsibilities involved in an automated action. The supervisor may have approved the amount without seeing the destination. The engineer may have implemented the permissions that the business requested. The vendor may control a model update while having no knowledge of the payment mandate.

WCAI's view is that institutions should allocate accountability around the authority they delegate. Before an agent acts, they should be able to identify who owns the purpose, grants permission, supplies the system, approves consequential decisions and handles failure. Those responsibilities need evidence and resources behind them.

An action has a chain of authority

An AI agent is a system that can select and perform steps towards a task, potentially using other software. Its authority comes from the organisation's credentials, integrations and operating rules. A model's ability to propose a payment does not grant permission to execute one; the institution decides whether to connect that proposal to a service that can move money.

Singapore's Model AI Governance Framework for Agentic AI announcement, dated 22 January 2026, emphasises that “humans are ultimately accountable”. Its practical measures include bounding agents' powers, defining significant human approval checkpoints, testing and controlling access to approved services. The framework addresses organisations developing agents and those buying third-party solutions. It provides guidance rather than a new universal statutory liability rule.

The phrase “humans are ultimately accountable” still leaves an institution with decisions to make. Which humans? For which actions? With what authority to intervene? An effective arrangement answers those questions before an incident creates pressure to assign blame.

For an agent that prepares a payment, follow the complete sequence: the business purpose, the records it reads, the proposed beneficiary and amount, the approval, the service that executes the instruction and the confirmation returned. Responsibility can differ at each step. Each handover must preserve the limits agreed at the previous one.

Separate responsibility for purpose, deployment and supply

The business process owner should own the decision to use the agent for a defined outcome. That includes deciding which errors the business can tolerate, where people must decide and whether the operating benefit justifies the retained risk and effort. The owner needs the ability to narrow or suspend the use, together with budget for support and recovery.

The deployment team implements that decision. It configures integrations, access, approvals and monitoring, and establishes whether the system operates within the agreed boundaries. A deployment owner may be an internal team or a contracted operator. Buying a managed service changes who performs the work; it still requires an agreed operating arrangement.

Suppliers have responsibilities for the components or services they provide. These can include specifications, known limitations, security, availability, changes and incident assistance. The institution should establish the applicable obligations in procurement and contracts. A broad assertion that the vendor “handles AI governance” tells the buyer little about who controls the actual workflow.

This is a proposed operating allocation, not a finding about legal liability. Legal responsibility depends on the facts, applicable law and contractual arrangements. Several parties can have obligations at once. An internal responsibility table cannot transfer a statutory duty or settle a customer's claim.

Outsourcing creates interfaces that need ownership

Singapore's personal-data rules offer a concrete example of the distinction. In the section on procuring bespoke or fully customisable systems in its March 2024 AI advisory guidelines, the Personal Data Protection Commission says organisations bear primary responsibility for ensuring their chosen system can meet their obligations under the Personal Data Protection Act. The same guidance addresses applicable obligations of service providers acting as data intermediaries. It does not declare that every AI supplier has an identical role or that buyers bear all possible liability.

The procurement implication is specific: establish which party handles which data, on whose behalf, for what purpose and with which safeguards. Ask what the supplier can provide when the organisation needs to investigate an unauthorised change or explain its handling of personal data. A supplier's inability to provide necessary evidence can limit the uses the institution should approve.

There is a similar interface around system changes. A model provider may update a service that the deployment team uses. The team should know which changes require re-evaluation and what happens if notice or rollback is unavailable. The business owner then decides whether those conditions are acceptable for the intended action. For a low-consequence drafting assistant they may be manageable; for a system initiating consequential transactions they can change the deployment decision.

A human checkpoint must preserve the decision

Approval is useful when the person can assess the proposed action and the system executes what they approved. In the supplier-payment example, the reviewer needs the beneficiary, amount, source evidence and relevant uncertainty. Approval of a batch total cannot be assumed to cover a later change to a beneficiary.

The technical implementation should therefore bind approval to the exact instruction and require another decision when material details change. Its access controls should prevent actions outside that mandate. Instructions written in a prompt can help direct behaviour, but the system granting access should enforce the permission boundary.

Capacity matters as much as the interface. A reviewer processing a large queue needs sufficient time and information to make the decisions assigned to them. If management approves a workflow that gives someone hundreds of opaque confirmations to clear, the organisation has designed a weak checkpoint. It should change the review scope, staffing or delegated authority rather than assume that the presence of a person resolves the risk.

The MAS parliamentary reply of 5 August 2026 describes Safeguards for Agentic Finance at Runtime, or SAFR, as a “potential approach” to authorising actions, activating oversight and recording consequential decisions. That wording supports the questions an institution should investigate. It does not establish SAFR as a mandatory supervisory standard or decide liability for a failed action.

Responsibility continues after the instruction

Containment and recovery need explicit owners. Pausing the agent may prevent another instruction while leaving uncertainty about the last one. Operations must inspect the authoritative record, determine what completed, identify affected parties and decide whether to retry, reverse or escalate. Some actions are reversible; others require a counterparty's cooperation or cannot be fully undone.

Retain enough evidence to reconstruct the action: the approved mandate, relevant inputs, versions, permission decisions, human approvals, execution results and subsequent corrections. Select records for the investigation they support, with appropriate privacy, access and retention controls. Recording every possible input indefinitely creates its own obligations and may still fail to explain the decision.

Before granting consequential authority, complete a short action mandate:

• The task, entities, systems and action types covered, with explicit exclusions.
• The business owner and the people allowed to grant, change or withdraw authority.
• Limits enforced by the executing service, including amount, destination or data scope where relevant.
• The approval conditions and the evidence the reviewer receives.
• The deployment and supplier obligations for change, support and incident assistance.
• The suspension route, recovery owner and records needed to establish the resulting state.

Test that mandate against one failed-action scenario with the people named in it. If an owner lacks the access, time or authority to perform their part, resolve that gap before expanding the agent's powers. The release and operating pack provides records for turning the allocation into an operating decision. Accountability becomes usable when the institution can demonstrate who does what at the moment authority is exercised and when something goes wrong.