Guide · Malaysia & Singapore
Agentic AI Governance: How to Govern AI Agents and Connectors
Once AI can read your email, change records or act in a browser, an acceptable use policy is not enough. This guide sets out autonomy levels A0–A4, connector controls, human approval and kill switches, and an agent register checklist, with what Singapore and Malaysia expect.
Short answer
What is agentic AI governance?
Agentic AI governance is the set of rules, owners and controls for AI that can act, not only answer: agents, connectors, and browser or computer use. It decides what each agent may read and do, at which autonomy level, who approved it, who can stop it, and how its actions are recorded.
The question changes from “what did someone type?” to “what can this system do on our behalf?” Three controls carry most of the weight: an approved autonomy level for each agent, connectors that are approved, scoped and reconciled every month, and a named person who can stop the agent.
What changes when AI can act
From “what did someone type” to “what can this system do on our behalf”
A chat assistant produces text that a person reads and decides what to do with. An agent works through tools. The kit treats this as its own tool tier, T3 Agentic with actions: write-enabled connectors, browser or computer use, and autonomous agents (AGK-000 v1.1).
- 01
It reads
A connector gives the AI your mailbox, shared drives or CRM. Whatever the connected account can see, the AI can now see and summarise.
- 02
It acts
Write tools let it send, edit, file, update or delete. A mistake is no longer a bad paragraph; it is an email sent or a record changed.
- 03
It keeps going
An agent plans several steps and runs them with less checking in between. The more it does alone, the more the limits must be set in advance.
The risk now depends less on the prompt and more on three settings decided before the agent runs: what it can reach, what it can change, and how much it does without a person checking.
Autonomy levels · AGK-000 v1.1
Agent autonomy levels A0–A4, and who approves each
Every agent gets an approved autonomy level. The level sets the minimum oversight. Approval follows the use case's risk tier, and any A3 or A4 agent is High risk, so the AI Governance Committee (AIGC) approves it.
| Level | What it means | Minimum oversight | Who approves |
|---|---|---|---|
| A0 Assist | What it meansSuggests only; no tools | Minimum oversightAcceptable use policy; the user reviews the output | Who approvesSet by the use case's risk tier |
| A1 Read | What it meansReads data through connectors under the user's own permissions | Minimum oversightApproved connectors; read-only scopes | Who approvesSet by the use case's risk tier |
| A2 Draft-and-approve | What it meansPrepares actions; a human approves each one | Minimum oversightPer-action approval; logging | Who approvesSet by the use case's risk tier |
| A3 Bounded autonomy | What it meansActs within an allowlisted, reversible scope; exceptions escalate | Minimum oversightAgent identity, limits, monitoring, kill switch | Who approvesAI Governance Committee |
| A4 High autonomy | What it meansMulti-step, irreversible or external-facing actions | Minimum oversightAIGC approval, red-team, real-time human-on-the-loop | Who approvesAI Governance Committee |
Source: AGK-000 v1.1, section 7 (agent autonomy levels) and section 8 (the AIGC approves standards, High-tier use cases and A3–A4 agents). Red-team: adversarial testing before release.
Use-case risk tiers behind “who approves”
| Risk tier | Meaning | Approval |
|---|---|---|
| High | MeaningMaterial risk of harm to individuals, customers, finances, safety or regulatory standing; decisions about people; A3–A4 agents | ApprovalAI Governance Committee |
| Medium | MeaningModerate, contained risk; human review of outputs before use; Confidential data | ApprovalAI Governance Lead |
| Low | MeaningProductivity uses with Internal data and human review | ApprovalSelf-service within the acceptable use policy; register if a system |
Record the level the agent is approved for, not the most the platform allows. Where Restricted data is involved, the kit's data rules hold agentic tools to A2 or lower unless the AIGC approves more.
Connector risk · AGK-STD-A03 v1.0
Connector risk: email, files and business systems
A connector (including an MCP server or desktop extension) lets an AI tool read from or act in another application. Each one widens what the AI can see and, if write tools are on, what it can change.
Email and calendar
Read: Client correspondence, contracts in attachments and personal data in signatures and threads.
Write: Messages sent in a person's name to people outside the company, which cannot be unsent.
Files and shared drives
Read: Everything the connected account can open, often far more than the task needs.
Write: Documents overwritten, moved, shared externally or deleted.
Business systems
Read: CRM, ERP, HR and finance records, including customer and staff personal data.
Write: Records created or changed, tickets closed, and actions that touch money or customers.
Five connector controls
- 01
Approve before enabling
No connector, MCP server or desktop extension is switched on until it has been requested and approved.
- 02
Triage into a lane
Green for read-only, low-sensitivity, company-account connectors from a vetted publisher; Amber for write tools, Confidential data or a new publisher; Red to decline or escalate.
- 03
Company accounts only
Connectors sign in to company-controlled accounts. Personal email, storage or code accounts are never linked to the company AI tenant.
- 04
Read-only by default
Write tools stay off unless approved for a defined use case, and each one is set to "needs approval" or "blocked".
- 05
Registry before enablement
Each approved connector is recorded with its lane, scopes, enabled tools and their permission settings, data label, owners, approval reference and next recertification date.
The monthly reconciliation
Approval only covers what people ask for. Once a month, the AI platform administrator compares the connectors actually enabled in each AI tenant and on managed devices with the registry. Anything unapproved is disabled within a set period (the template default is five business days) or sent through the request procedure if there is a real business need, and the finding is recorded.
Control AGK-STD-A03-C18, listed in the Lite control checklist of AGK-001 v1.0. The request procedure is AGK-PRC-A01 v1.0 and the registry is AGK-TPL-02 v1.0 (member documents).
Human-in-the-loop and kill switch
Human approval, actions agents never take, and the kill switch
Human oversight has to be designed in, not assumed. These controls come from the browser and computer-use standard (AGK-STD-A04 v1.0) and the incident procedure, as listed in AGK-001 v1.0.
A person confirms what cannot be undone
The user confirms before any irreversible or externally visible action: submit, send, publish, purchase, delete. Where the platform has an “ask before acting” mode, it is enforced. Browser and computer use stay off by default and are enabled only for approved groups.
What a browser agent must never do
- Enter credentials, passwords or one-time codes
- Make payments or transfers
- Accept terms, contracts or consents for the company
- Delete data
- Bypass or solve CAPTCHAs and other anti-automation controls
- Change security or account settings
The kill switch
From A3 upwards, an agent needs its own identity, limits, monitoring and a kill switch. In a P1 or P2 incident involving an agent, it is suspended within the containment time unless the incident coordinator documents why keeping it running is safer. Suspected prompt injection or an unintended action is reported at once.
Approval prompts lose value if people click through them. Singapore's framework makes the same point: design oversight against automation bias, and audit whether approvals are working.
Checklist
Agent register checklist: what to record for every agent
Every AI system, connector and agent has a named human owner recorded in a register (AGK-000 v1.1). For each agent, capture at least the following before it goes live.
Named owner
One accountable business owner for the agent, plus the platform administrator who configures it.
Purpose and use case
What the agent is for, and the approval reference for that use case.
Autonomy level
A0 to A4, recorded as approved, not as the platform's maximum.
Risk tier
Low, Medium or High; any A3 or A4 agent is High.
Connectors and scopes
Every system it can reach, the scopes granted, and whether access is read or write.
Write tools and their setting
Each write or act tool, set to "needs approval" or "blocked" unless explicitly approved.
Highest data label
The most sensitive data it can reach: Public, Internal, Confidential or Restricted. Secrets never.
Identity and credentials
The account it acts as, with managed credentials, never secrets pasted into prompts or instructions.
Limits and logging
Allowlisted actions, spending or volume limits where relevant, and where its actions are logged.
How to stop it
Who can suspend it, how, and when the kill switch was last tested.
Review date
When the owner next confirms it is still needed and still within scope.
In the kit, agents and AI systems go into the AI System Register (AGK-TPL-01 v1.0), which already records autonomy level and risk tier per system; connectors and their tools go into the Connector & Tool Registry (AGK-TPL-02 v1.0). Preview the AI System Register
Singapore
Singapore's Model AI Governance Framework for Agentic AI, in brief
IMDA launched the framework in January 2026. Version 1.5 was published on 20 May 2026 and updated on 5 June 2026, adding real-world case studies and new best practices. It is written for organisations deploying agents, whether built in-house or bought from a third party, and sets out four areas.
Area 1
Assess and bound the risks upfront
Choose suitable use cases with a risk assessment that weighs the agent's access to sensitive data and its level of autonomy, then limit its scope through design: autonomy, tools and data access.
Area 2
Make humans meaningfully accountable
Allocate responsibility clearly across everyone in the agent's lifecycle, and design human oversight that resists automation bias, such as approvals at significant checkpoints that are themselves audited.
Area 3
Implement technical controls and processes
Use technical controls in design, test agents for baseline safety and security before deployment, and roll out gradually with continuous monitoring and testing.
Area 4
Enable end-user responsibility
Tell users when and how agents are used, and train them to use and oversee agents responsibly while keeping their own core skills.
How the kit maps it: autonomy levels and connector lanes bound the risk upfront; named owners and AIGC approval keep a human accountable; agent identity, per-action approval, monitoring and the kill switch are the technical controls; training and the acceptable use policy cover end users.
Source: IMDA, Model AI Governance Framework for Agentic AI, v1.5 and IMDA's announcement of the update, checked November 2026. Voluntary guidance; check the current version before relying on it.
Malaysia
Malaysia: the draft AI Governance Bill and agents
Malaysia's AI Governance Bill is a draft under consultation (status as at October 2026). It proposes developer and deployer duties, harm tiers, and incident and near-miss reporting. Nothing in it is in force yet, and the text may change.
If you use vendor agents
The kit treats you as the deployer (Track A): approved connectors, autonomy levels, a registry and an incident log that also captures near-misses.
If you build agents
You are the developer and the deployer of your own system (Track B): agent identity and access, evaluation and release gates, guardrails and monitoring, on top of everything in Track A.
The PDPA already applies whenever an agent processes personal data. For what the draft proposes, read the Malaysia AI Governance Bill explained.
Building agents
Governance is part of the agent build, not a later review
Anchor Sprint builds AI agents for Malaysian and Singapore companies. We set the autonomy level, scopes, approval points and kill switch with you during design, so the register entry exists before the agent runs.
Free AI Governance Lite pack
The documents an organisation starting out needs to govern AI tools in its first 90 days. Word and Excel, ready to edit.
- Lite Quick Start and Control Checklist AGK-001 · Word
- AI Governance Framework and Document Architecture AGK-000 · Word
- AI Acceptable Use Policy AGK-POL-02 · Word
- AI Data Handling Standard AGK-STD-A02 · Word
- AI Discovery and Shadow AI Procedure AGK-PRC-07 · Word
- AI Adoption Roadmap and Use-Case Prioritisation Guide AGK-GDL-C02 · Word
- AI System Register AGK-TPL-01 · ExcelPreview AI System Register
- AI Use Case Intake Form AGK-TPL-03 · Word
- AI Incident, Nonconformity and CAPA Log AGK-TPL-06 · ExcelPreview AI Incident, Nonconformity and CAPA Log
- AI Acceptable Use Acknowledgement AGK-TPL-07 · Word
- Pengakuan Penggunaan AI (Bahasa Melayu) AGK-TPL-07-BM · Word
- AI Use-Case Prioritisation and Benefits Tracker AGK-TPL-12 · ExcelPreview AI Use-Case Prioritisation and Benefits Tracker
Template release v1.0 · ZIP · 990 KB
Download AI Governance Framework and Document Architecture and the Lite pack
Templates for governance purposes, not legal advice.
Planned: the AI Governance Hub will keep a connector and agent registry alongside the AI system register, so the monthly reconciliation runs against a live list. These Member features are planned and not yet available.
AI Governance Hub
AI Governance Hub: the AI risk management platform for your risk team
Templates go stale. The Hub keeps every AI system registered, risk-assessed, owned and evidenced, and answers staff questions from your own policy. Launching soon: join the waitlist and we will contact you before it opens.
| Feature | Free | Member |
|---|---|---|
| Templates | 12 Lite documents | All 48 documents, with version history |
| Pre-read and tier check | ||
| 90-day planner with owners and evidence | ||
| Policy assistant: a pack tailored to your company | ||
| AI system and risk register, with a ready AI risk library | ||
| Control owner register with quarterly attestation and evidence | ||
| Connector, agent and AI vendor registries | ||
| Incidents, exceptions and review calendar | ||
| KRI dashboard and one-click board report | ||
| MCP connection: staff ask Claude, ChatGPT or Copilot and get answers from your own policy | ||
| Regulation and vendor-setting update alerts |
Member features are planned for launch and may change.
Enterprise · deploy in your environment · coming later
Run the same AI risk platform in your own cloud account (AWS, Azure or Google Cloud, with your own AI model account), or fully offline on your own servers with a private AI model. For organisations that cannot use shared cloud software. Pricing on request.
Want it set up with you? We run a governance setup sprint: owners, policy, register and an approved AI tool. Book an online meeting
RM 2,400
per organisation per year
Agentic AI governance FAQ
What is agentic AI governance?
Agentic AI governance is the set of rules, owners and controls for AI that can act, not only answer: agents, connectors, and browser or computer use. It decides what each agent may read and do, at which autonomy level, who approved it, who can stop it, and how its actions are recorded.
What are AI agent autonomy levels?
The AI Governance Kit uses five levels. A0 suggests only. A1 reads data through connectors. A2 prepares actions that a person approves one by one. A3 acts alone within an allowlisted, reversible scope. A4 takes multi-step, irreversible or external-facing actions. Required oversight rises with each level.
Who should approve an AI agent?
Under the kit, the AI Governance Committee approves every A3 and A4 agent, because these count as High-risk use cases. Lower levels follow the use case's risk tier: the AI Governance Lead approves Medium-risk uses, and Low-risk productivity uses are self-service within the acceptable use policy. Every agent still has a named owner.
How do you control AI connectors to email and files?
Approve each connector before it is switched on, connect only company accounts, keep it read-only unless a write tool is approved for a defined use case, and record it in a connector registry. Then reconcile what is actually enabled against that registry every month and disable anything unapproved.
What is a kill switch for AI agents?
A kill switch is a tested way to stop an agent at once, by suspending it or cutting its access. The kit requires one from autonomy level A3, and its incident procedure suspends any agent involved in a P1 or P2 incident unless the incident coordinator documents why running it is safer.
Does Singapore have a governance framework for agentic AI?
Yes. IMDA's Model AI Governance Framework for Agentic AI was launched in January 2026; version 1.5 was published in May 2026. It covers four areas: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. It is voluntary guidance, not law.
Does Malaysia regulate AI agents?
Not specifically, as at October 2026. The PDPA already applies when an agent processes personal data. The draft AI Governance Bill, still under consultation, proposes developer and deployer duties, harm tiers, and incident and near-miss reporting. Recording who built and who runs each agent prepares you for either role.
Part of the AI governance guide for Malaysia and Singapore. See also the AI acceptable use policy template and the template library.
