Agentic AI in Singapore: design human approval checkpoints

Agentic AI human approval should sit at the point where a system can cause a meaningful consequence, not at an arbitrary place in the workflow. Singapore’s new governance framework emphasises accountable deployment, bounded powers and approval appropriate to risk. A practical design begins with the actions an agent can actually take.

Inventory actions, not just features

List every tool and system the agent can use: email, payments, customer records, code, procurement, calendars, files and external websites. For each one, record the identity used, data reachable, actions allowed and whether the result can be reversed. A chatbot that only drafts text presents a different risk from an agent that sends, purchases or changes production data.

Include chained actions. Reading a customer request, looking up an account and preparing a reply may be low consequence until the system can issue a refund or disclose personal data. Map the complete path so an approval cannot be bypassed by splitting one consequential outcome into several individually permitted steps.

Apply the Singapore risk principle

IMDA’s Model AI Governance Framework for Agentic AI calls for meaningful human accountability. It distinguishes pre-approval for higher-risk, irreversible actions from post-hoc review that may be suitable for lower-risk, reversible work. Use that distinction as a design principle rather than a fixed list.

Assess financial effect, legal or regulatory consequence, safety, privacy, customer impact, reversibility, scale and detectability. A small transfer repeated thousands of times can be material. A reversible database edit can still be harmful if nobody detects it promptly. Document the risk owner’s reasoning for each approval class.

Design pre-approval that informs the reviewer

A reviewer needs the proposed action, recipient or target, relevant source data, amount or scope, rationale, policy checks and expected consequence. Show uncertainties and model confidence only where they help judgement. Do not present an approve button beside a dense transcript and call that meaningful human control.

Prevent the action from changing after approval. Bind approval to the exact payload, identity and time window. If the agent revises a payment, message or contract term, require a new approval. Keep the reviewer independent when the action affects the reviewer’s own target or performance measure.

Use post-hoc review carefully

For low-risk work that is reversible, define sampling, review frequency, detection measures and rollback. Examples might include internal classification or draft organisation, depending on the company’s context. Set thresholds that move an action to pre-approval when volume, anomaly or uncertainty rises.

Post-hoc review is not permission to ignore outcomes. Record the action, inputs, tools, system identity, result and later correction. Monitor customer complaints, unusual tool use and repeated overrides. Give reviewers authority to pause the agent while an issue is investigated.

Limit tools, data and duration

Give the agent a dedicated identity with the minimum permissions required for the defined task. Separate read, draft, submit and approve rights. Restrict data fields, counterparties, transaction amounts and operating hours where practical. Expire temporary access rather than leaving a broad credential available after a pilot.

The framework highlights limits on tools and data, identity and access management, and traceability. Test those controls outside the agent’s own reasoning. A written instruction not to send money is weaker than an account that cannot transfer funds without an authorised human.

Prepare exception and incident routes

Define when the agent must stop and escalate: missing information, conflicting instructions, policy exceptions, new recipients, unusual amounts, security warnings or inability to confirm a source. The escalation should preserve context without exposing more data than the human needs.

Create a kill switch owned by named employees and rehearse it. Plan credential revocation, session termination, customer communication, transaction recovery, evidence preservation and regulatory assessment. An incident playbook should work even if the agent’s interface or vendor service is unavailable.

Test the checkpoints before deployment

Use realistic cases, including adversarial instructions, manipulated attachments, duplicate requests and attempts to use an unauthorised tool. Measure whether the agent stops, whether the human understands the request and whether the approved action matches the executed action. Include staff who did not design the workflow.

Compare results with the Singapore AI data-readiness guide, which covers data ownership, quality and lawful use. Approval design cannot rescue unreliable source data, and clean data cannot compensate for excessive permissions. Both controls should be reviewed before the pilot expands.

Keep accountability with the organisation

Assign an executive owner, process owner, technical owner and incident owner. Record the vendor’s responsibilities without transferring the company’s accountability to the provider. Review performance, overrides, incidents, model or tool changes and business use at a set cadence.

Link the operating record to the Champions of AI readiness guide. That broader guide helps management connect responsible AI, procurement and measurable business value. Human approval is successful when it changes or stops unsafe actions, not when it merely records that a person clicked a button.

Start with the agent’s most consequential action and make the approval specific, informed and technically binding. Once that works, lower-risk actions can be classified with evidence instead of optimism, and every expansion can remain accountable to a named human owner.

Measure whether human review is working

Track approval volume, rejection and modification rates, time to decision, repeated exceptions and actions later reversed. A near-zero rejection rate may mean the agent is consistently safe, but it may also show that reviewers are approving automatically. Sample approved cases and interview reviewers to distinguish those possibilities.

Watch for alert fatigue as use grows. Reduce unnecessary requests by narrowing the agent’s task or permissions, not by removing scrutiny from consequential actions. When a checkpoint changes, test the new design with the same difficult cases and preserve the reason for the change.