How to keep an AI agent under control
A practical Singapore guide to AI agent governance for SMEs, covering ownership, limited access, human approval, testing and activity records you can use.
An AI agent can do more than answer a question. It may read customer records, update a system or send a message. That makes it useful, but it also changes what can go wrong.
For a Singapore SME, AI agent governance can begin with a short working document and a few firm controls. You do not need a new compliance department. You do need to know who owns the agent, what it may do and how somebody can stop it.
What Singapore's AI agent rules mean for an SME
IMDA's Model AI Governance Framework for Agentic AI covers four broad areas: setting boundaries, making people accountable, testing technical controls and being clear with users.
In daily business terms, this means:
- somebody is responsible for the agent
- its job and limits are written down
- access matches that job
- sensitive actions require approval
- staff can review what it did
- customers and employees are not misled about its role
These principles apply whether you build the agent yourself or buy a product. A vendor can provide the software, while your business still owns the decision to connect it to customer data or let it take action.
Keep a simple record of every agent
Start a spreadsheet for agents that can access company information or act on your behalf. One row per agent is enough at first.
| Record | Example |
|---|---|
| Owner | Operations director, with a named backup |
| Job | Prepare overdue-account reminders for review |
| Data it can use | Approved invoices and customer payment history |
| Actions it may take | Draft reminder and add an internal note |
| Actions it may not take | Send email or change payment terms |
| Human approval | Finance employee approves every external message |
| When it must stop | Records conflict or a required source is unavailable |
| Review routine | Weekly check of errors, overrides and delays |
Writing this down exposes vague plans. “Help finance with collections” does not explain what the agent can see or change. Narrow the access until the job is clear.
Match the controls to the possible harm
Begin with the least access the agent needs. Consider reading and changing data separately. An agent preparing a stock report may need to read inventory records, but it probably should not be able to adjust quantities.
Then look at what happens if it is wrong:
- Low consequence: summarising an approved internal document with links to the source
- Moderate consequence: drafting a customer response or suggesting a reversible record change for review
- High consequence: sending money, changing bank details, deleting records or making a decision that affects someone's rights
Keep high-consequence actions under human control unless there is a strong reason to do otherwise. For many SMEs, a permanent approval step is the sensible choice.
Remember that a small change can trigger a larger chain of events. Updating a delivery date may also tell the warehouse to prepare an order and notify the customer. Review the full process before deciding that an action is low risk.
Make approval a proper review
An approval button helps only when the reviewer has enough information to decide.
For an overdue-account reminder, show the invoice, payment history and proposed message together. Highlight any conflict. The finance employee should not have to open four systems and repeat the agent's work.
Place approval before the message is sent or the record is changed. A review after the action is useful for monitoring, but it cannot prevent the mistake.
Keep a short reason when a reviewer changes or rejects the agent's suggestion. Over time, those reasons show whether the instructions need work or whether the process contains an exception nobody documented.
Test the cases people worry about
Before launch, test normal work alongside incomplete and difficult cases. For a supplier-record agent, include changed bank details, a request to skip a check, a document with conflicting information and a failure in one of the connected systems.
Check how the agent reached the result as well as the answer itself. A correct answer drawn from a system it was not allowed to access is still a failure.
OpenAI's guide to building agents recommends several layers of protection and human intervention for high-risk or repeated failures. NIST's AI Risk Management Framework also calls for testing under real operating conditions and continued monitoring after launch.
Keep records that help when something goes wrong
An activity record should answer basic questions: who started the job, which version of the agent was used, what sources it opened, what actions it attempted and who approved them.
Do not keep sensitive content forever simply because storage is inexpensive. Decide what you need for investigation and improvement, limit who can see it and set a retention period.
Review the first month closely. Repeated corrections may point to weak instructions. Long waits for approval may show that the review step is poorly designed. Permissions that are never used can often be removed.
Tell people when an agent is involved
Employees need to know when they are checking agent-prepared work and what responsibility remains with them. Use examples from the actual job during training, including a mistake and the right way to report it.
Customers should not be led to believe they are speaking to a person when a service is automated. They also need a practical way to reach someone when the agent cannot help.
The agent's owner should be able to inspect a case and suspend the system. A generic support inbox is a weak fallback if nobody there knows how the agent works.
Put the controls in place before launch
Permissions, approval screens and activity records are easier to build before an agent is connected to live systems. Adding them after a serious mistake is slower and more stressful.
For a first agent, agree on the owner, job, access, approval points and stop conditions before live use. That gives the business enough structure to learn from a contained deployment without asking staff to trust an invisible decision-maker.