Singapore’s Agentic AI Governance Framework: A Practitioner’s Implementation Guide

The Singapore framework organises its guidance into four dimensions. The policy language is clear but high level. Here is what each one means in terms of what you actually build.

1. Assess and Bound the Risk Upfront

Before an agent ships, decide what it is allowed to touch. Pick use cases that fit autonomous action, and reject the ones that do not. Then put hard limits on the agent’s powers. Scope its data access to the minimum it needs. Whitelist the tools and APIs it can call. Cap the value of any irreversible action it can take on its own.

In practice this means a written risk profile for every agent before a line of production code runs. The profile should score three variables:

Autonomy level — does the agent take reversible actions only (read, draft, notify), or irreversible ones (send, pay, delete, modify records at scale)?

Data sensitivity — does the agent touch personal data, regulated financial data, confidential commercial data, or only internal operational data?

Action reversibility — if the agent misfires, can the action be undone in under one business day without customer impact, or not?

Map those three scores to a governance tier:

• Tier 1 (low risk): reversible actions only, non-sensitive data, no external APIs. Can deploy with standard logging and quarterly review.
• Tier 2 (moderate risk): some irreversible actions or access to personal data. Requires pre-deployment evaluation gate, named owner, human checkpoint on high-value actions, monthly review.
• Tier 3 (high risk): irreversible actions on regulated or sensitive data, external integrations, or customer-facing decisions. Requires full technical control stack, CISO sign-off, explicit MAS/IMDA-aligned risk acceptance, bi-weekly review.

A BFSI example: an agent that reads transaction history to draft a dispute summary is Tier 1. An agent that sends payment instructions is Tier 3 even if it looks “simple.” The risk is in the action, not the interface.

Document the worst realistic outcome for each agent before writing production code. You cannot bound a risk you have not named.

2. Make Humans Meaningfully Accountable

The framework asks you to define significant checkpoints where a human must approve. The word “meaningfully” carries weight.

What meaningful looks like: – A payment authorisation agent pauses on any transaction above S$10,000 and presents the approver with the full context: payee history, reason for payment, triggered policy rule, and a one-click reject with mandatory reason field. – A customer communications agent drafts responses to all queries but requires human review before sending on complaints, refund requests, or queries flagged as sensitive by the topic classifier. – A document processing agent auto-routes 80 percent of standard forms but escalates any document where confidence falls below 0.85, with the original document and extracted fields shown side by side.

What theatre looks like: – An approval notification that contains only “Agent action pending — Approve / Reject” with no context for the approver to evaluate. – A checkpoint that fires on every action regardless of stakes, so operators approve hundreds per day and treat it as a click-through to clear their queue. – An “audit log” that records the fact of human approval but not which human, when, or what context was shown to them.

Build checkpoints where the cost of a mistake is high and where a human can add real judgement. Pair each checkpoint with an override and an interrupt, so a person can stop an agent mid-task. Interrupts must be reachable in fewer than two steps from the monitoring dashboard — not buried in an admin console only three engineers know about.

Then assign a named owner to every agent. The owner is the person who would be called at 2 am if the agent caused an incident. If no person fills that role, you do not have an owner. You have a gap.

3. Implement Technical Controls Across the Lifecycle

This is the dimension your platform team owns. The framework points to baseline testing and controlled access to whitelisted services. Translate that into a concrete engineering checklist.

Pre-deployment evaluation gate: – Define a fixed test set before the agent enters staging. Include edge cases, adversarial inputs, and scenarios from the risk profile. – Set a minimum pass score on task completion rate, refusal rate on out-of-scope requests, and false positive rate on sensitive action triggers. – Record the test set version and scores in the agent registry. A model version change behind the agent counts as a release and triggers a re-test — treat it as a dependency upgrade, not a silent infrastructure change.

Action logging schema — minimum fields per event:

agent_id          string      // registry ID, not a display name
agent_version     string      // model + tool versions at time of action
action_type       enum        // read | write | call | handoff | escalate | error
tool_called       string      // API or function name
input_summary     string      // non-PII summary of what was passed to the tool
output_summary    string      // non-PII summary of what the tool returned
outcome           enum        // success | failure | retry | human_escalated
human_actor       string      // null if no human involved; user ID if checkpoint triggered
timestamp         ISO 8601
session_id        string      // links all events in one task run
risk_tier         int         // 1 | 2 | 3 from the risk profile

Log into your existing SIEM or security observability stack — not a separate “AI log” that no one monitors. If it is not in the same tooling as your incident response, it will not get used in an incident.

Credential scoping steps: 1. Create a dedicated service account per agent, not a shared platform credential. 2. Scope the account to the minimum API permissions needed for the task. If the agent reads Salesforce but never writes, grant read-only. 3. Set credential TTLs — no agent should run with credentials older than 90 days without re-attestation. 4. Audit effective permissions on a schedule (monthly for Tier 3, quarterly for Tier 2). Effective permissions include inherited group permissions, not just the ones you deliberately granted.

Kill switch test procedure: 1. Document the kill switch in the agent registry: the exact mechanism (feature flag, API disablement, service account revocation), the person authorised to trigger it, and the expected time to take effect. 2. Test it in staging every quarter — not just document that it exists. Record the test result in the registry. 3. Include the kill switch runbook in your on-call playbook. The engineer paged at 2 am should be able to disable an agent in under five minutes without asking anyone for access.

If your team is already moving GenAI from pilot to production, you have most of this scaffolding. Agents raise the bar on logging and identity, and that is where to invest first. For a deeper look at the engineering patterns, see our guide on how to build enterprise AI agents.

4. Enable End-User Responsibility

The people who use your agents need to know what they are using. The framework requires disclosure, capability communication, and operator training. Each has a specific implementation shape.

Disclosure patterns that satisfy the framework: – At session start, a persistent UI label: “You are working with an AI agent. It can [specific capabilities]. It cannot [hard limits].” – For customer-facing agents, a one-sentence disclosure before the first agent-initiated action: “I am an AI assistant and I am about to [action]. Would you like to proceed?” – In audit-facing systems, a timestamp and agent ID in every output document or record the agent creates.

What does not satisfy the framework: – A terms-of-service paragraph buried in onboarding that mentions “AI-powered features.” – A chatbot avatar that is clearly non-human but carries no explicit disclosure. – A disclosure shown once at signup and never surfaced again in the working interface.

Operator training program elements: – A baseline module (≤60 minutes) covering what the specific agent can and cannot do, how to read its outputs, and how to escalate or override. – A quarterly refresher that includes at least one worked example of an agent failure from your own logs or from industry incidents. – An explicit unit on automation bias — why reliable agents get less scrutiny over time, and how to counteract the tendency. Name the dynamic. Operators who know the word “automation bias” are more likely to catch it in themselves.

This dimension is the cheapest to skip and the most expensive to ignore. Most agent failures that reach a customer trace back to a human who trusted an output they were never trained to question.