Before you give an AI agent tools, bound what it can do

01

What changed

Singapore's IMDA framework for agentic AI organises responsible deployment around four dimensions: assess and bound risks before deployment, keep humans meaningfully accountable, apply controls across the lifecycle, and equip end users through transparency and training.

For an operator, the useful shift is simple. An AI agent is not only a chat interface. It may plan, call tools, read or change records, and continue through several steps. The operating question is therefore not only whether the model gives a good answer. It is whether the system can act safely when the answer is incomplete, wrong, or unexpected.

02

1. Bound the job before choosing the tool

• Write the exact outcome the agent may produce and the outcomes it must never produce.
• List the tools, folders, systems, and data it may access. Deny everything else by default.
• Separate read, draft, recommend, approve, and execute permissions. They are different risk levels.
• Set time, cost, retry, transaction, and volume limits before the first production run.
• Define stop conditions for missing context, conflicting instructions, sensitive data, or an unavailable reviewer.

03

2. Put approval where the consequence changes

Human review is useful only when the reviewer has enough context and authority to stop the action. Place checkpoints before irreversible or externally visible steps, not after the workflow has already sent, published, paid, deleted, or changed a customer record.

• Name one accountable owner for the workflow and one operational backup.
• Require approval before money moves, messages leave the organisation, permissions change, or records are deleted.
• Show the reviewer the input, proposed action, material assumptions, source evidence, and expected side effects.
• Record who approved the action and which version of the workflow produced it.

04

3. Run controls through the full lifecycle

• Test normal cases, edge cases, adversarial instructions, unavailable tools, and partial failures before launch.
• Keep credentials outside prompts and logs. Give each integration the minimum permission required.
• Capture enough event history to reconstruct a failure without storing unnecessary personal or confidential data.
• Monitor cost, latency, tool errors, repeated loops, unusual output volume, and human override frequency.
• Create a kill switch and a manual fallback that the team has actually rehearsed.
• Review the workflow again when the model, prompt, connected system, data source, or business rule changes.

05

4. Make the system legible to the people using it

• Tell users when they are interacting with an agent and what it can do.
• Explain which actions still require a person and how a user can request review.
• Train operators on known limits, safe escalation, and the difference between a confident output and a verified one.
• Keep instructions near the workflow. A policy that nobody sees at the decision point is not an operating control.

06

A 30-minute preflight

Before approving an agentic workflow, ask the owner to demonstrate one successful run, one blocked run, one human escalation, one tool failure, and one recovery. If any of those paths are unclear, the workflow is still a prototype.