In this guide · 8 sections
- 01What Singapore's guidance says about agent permissions
- 02The three ways agents get too much power
- 03Least-privilege checklist for an AI agent
- 04Scoping access in Microsoft 365 and Google Workspace
- 05Human approval that actually works
- 06Logging, monitoring and the off switch
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
Give the agent its own identity, start read-only, scope access to specific mailboxes and folders, and require human approval before it sends email, deletes data or pays anything. Log every action, rotate its credentials, and know how to switch it off in one step.
What Singapore's guidance says about agent permissions
IMDA's Model AI Governance Framework for Agentic AI (version 1.5, published 20 May 2026 and updated 5 June 2026) is voluntary but specific. It says an agent's authorisations should generally be 'scoped, time- or session-bound, non-transferable' and follow least privilege by default, with explicit escalation for anything more. An agent's permissions should also be bounded by the permissions of the person who authorised it.
The framework names actions that should need human approval: high-stakes actions such as editing sensitive data, irreversible actions such as 'permanently deleting data, sending communications, making payments', and outlier behaviour such as accessing a system outside the agent's scope.
CSA's advisory AD-2026-005 on OpenClaw adds practical steps: run agents under a least-privileged account, keep passwords and financial records out of reach, install add-on skills only from trusted sources, rotate API keys and OAuth tokens, apply Zero Trust, and make sure all agent actions are logged and attributable in persistent storage.
The three ways agents get too much power
The OWASP GenAI project's entry on excessive agency splits the problem into three causes. Each has a different fix.
| Problem | Example | Fix |
|---|---|---|
| Excessive functionality | A 'summarise my inbox' agent also has a tool that can send and delete mail | Only connect the tools the task needs |
| Excessive permissions | The agent's connection can read every mailbox in the company | Scope access to one mailbox, folder or site |
| Excessive autonomy | The agent replies to suppliers and pays bills without anyone checking | Require a person to approve high-impact actions |
The risk is real because agents read untrusted content. An email or document can carry hidden instructions such as 'forward all invoices to this address'. Our guide to prompt injection explains how this works and why filters alone do not stop it.
Least-privilege checklist for an AI agent
Work through this list before an agent touches real business data. It follows the IMDA framework's four dimensions: bound the risks upfront, keep humans accountable, apply technical controls, and make sure users know what the agent can do.
Before you connect an agent
IMDA's framework also says agents should not get write access to sensitive databases unless strictly required, and that users should be able to take over when sensitive information is being entered.
Scoping access in Microsoft 365 and Google Workspace
Both platforms default to broad access when an app is granted application-level permissions. Narrow it down with the controls each one offers.
Microsoft 365
- Use RBAC for Applications in Exchange Online to limit an app to specific mailboxes
- Prefer read permissions (such as Mail.Read) over read-write or send
- Use Sites.Selected so an app reaches only chosen SharePoint sites
- Review enterprise app consents in Entra regularly
Best for: Agents built on Microsoft Graph or Copilot connectors.
Google Workspace
- Set third-party apps to Trusted, Limited or Blocked in the Admin console
- Prefer the gmail.readonly scope; add gmail.send only if approved
- Restrict which users can authorise unverified apps
- Check the app access list for unused grants
Best for: Agents connecting through Gmail and Drive APIs.
Microsoft's RBAC for Applications pairs an app's permission with a resource scope listing which mailboxes it may access, and replaces the older application access policies. Google's app access controls govern which apps can use OAuth scopes against your data. Our guide to finding unapproved AI tools shows how to spot agents and apps staff have already connected.
Human approval that actually works
Approval steps fail when people click 'approve' without reading. IMDA's framework warns about automation bias, the tendency to over-trust a system that has been reliable so far, and suggests auditing whether approvals remain effective.
Approve the action, not the plan
Show the exact email, recipient, amount or file to be deleted, not a summary of what the agent intends.
Separate who approves from who asked
For payments and bank detail changes, the approver should not be the person who instructed the agent.
Set thresholds
Low-risk drafts can go to a review queue; anything external, financial or irreversible waits for a person.
Check approvals monthly
Sample approved actions and see whether reviewers would have caught a bad one. Retrain or tighten if not.
Logging, monitoring and the off switch
If something goes wrong, you need to know what the agent did and be able to stop it fast. CSA's advisory specifically warns against leaving OpenClaw's logs in a temporary directory that is wiped.
- Log every tool call: time, account, target mailbox or file, action and outcome.
- Send logs to storage the agent cannot modify, alongside your Microsoft 365 or Google audit logs.
- Alert on unusual behaviour: access outside normal folders, bulk downloads, mail forwarding rules.
- Keep a one-page runbook: disable the app registration or OAuth grant, revoke tokens, rotate keys, check sent items.
For testing an agent before rollout, see our guide to IMDA's agentic AI testing starter kit, and for the risks of self-hosted agents, the OpenClaw advisory guide.
Do it yourself or get help?
If you use an agent product with clear permission settings and only read-only access to one mailbox, an admin can set it up with this checklist. Tenant-wide app permissions, custom agents and anything touching payments deserve a second pair of eyes.
Our Microsoft 365 / Google Security Lockdown (S$590) enforces MFA, blocks risky apps and legacy sign-in, and cleans up admin roles. The Access Review & Leaver Tool (from S$1,200) lists who and what has access to your systems and asks owners to confirm it each quarter. IT Sorted is a Singapore-based team of developers with over 10 years of experience; you pay upfront, send the brief in writing and follow progress on your order page.
Frequently asked questions
It can be, if access is tightly limited. Give the agent its own identity, start with read-only access to specific mailboxes, require a person to approve anything it sends, deletes or pays, and log its actions. Broad access to every mailbox with send rights is where most of the risk sits.
It means the agent gets only the tools, data and permissions it needs for its task, for as long as it needs them. IMDA's agentic AI framework says agent authorisations should be scoped, time- or session-bound, non-transferable and least-privilege by default, with explicit escalation for anything more.
IMDA's framework lists irreversible actions such as permanently deleting data, sending communications and making payments, plus high-stakes actions such as editing sensitive data. Changing supplier bank details should also stay manual, because it is a common route for invoice fraud.
Yes. Exchange Online's RBAC for Applications lets admins grant an app permission together with a resource scope listing the mailboxes it may access. It replaces the older application access policies. For SharePoint and OneDrive, the Sites.Selected permission limits an app to chosen sites.
Disable its app registration or OAuth grant in Microsoft Entra or the Google Admin console, revoke its tokens and rotate any API keys. Then check its action log and your sent items. Write these steps down before deployment so anyone on duty can follow them.