Give the minimum permissions the job needs
The first rule is least privilege. An agent that answers order-status questions should be able to read orders, but not delete them or issue refunds. Create a dedicated account or API key for the agent rather than borrowing a staff member's login, which keeps the scope narrow and makes the trail easy to audit.
Split tools into read-only and state-changing groups, and enable the changing ones only as needed, with limits and conditions attached. For example, refunds up to a set amount per transaction.
Put approval steps where the risk is
Not every action needs a human click. If everything waits for approval, the agent saves no time. Sort actions by risk: reading and drafting go straight through, while sending messages outside the company, changing customer data and anything involving money should pause for a person.
The approval screen should say what the agent will do, to which record, why, and what happens if you approve. When people lack the information to decide, they approve by habit, and the step turns into theatre.
- Automatic: read data, draft text, summarise.
- Needs approval: send external messages, edit customer records, anything with money.
- Never allowed: permanent deletion, changing user permissions.
Log every step so you can replay it
Each time the agent acts, record the instruction it received, a short summary of its reasoning, which tool it called with which parameters, the result, and who approved. When something odd happens you can trace it in minutes instead of guessing from the final symptom.
Be careful not to log more personal data than needed. Mask sensitive fields, set a retention period, and limit who can read the logs, in line with PDPA principles.
Make actions reversible
Design the agent to do reversible things first, such as creating a draft or a pending state instead of deleting or sending at once. Systems with soft delete, version history and an undo window turn a serious mistake into a fixable one.
For actions that cannot be undone, like an email that has left the building, add a short delay before sending or always require approval.
If a mistake cannot be undone, ask first. If it can, act and tell afterwards.
Test in a sandbox before touching the real system
Build a test environment with fake data and fake tools, such as email that is never delivered and a payment system in test mode. Run the agent through many scenarios, including users who try to push it past its permissions and documents with hidden instructions inside them, known as prompt injection.
Rerun these scenarios whenever you change a prompt, a tool or the model, just as you would run regression tests on ordinary software.
Monitor after launch and keep an emergency stop
Set up dashboards and alerts for warning signs: tool calls per hour spiking, an agent looping without finishing, an unusual rate of rejected approvals, or costs climbing fast. Also cap the number of steps and the spend allowed for a single task.
Keep a switch that stops the agent immediately without a new deployment, and rehearse who presses it and who gets told. During an incident is the wrong moment to work that out.
Key takeaways
- Give the agent minimum permissions through its own account or key.
- Require approval only for risky actions, and design the approval screen so people can really decide.
- Log every step, but mask personal data and restrict who can read the logs.
- Prefer reversible actions, and delay or require approval for irreversible ones.
- Test in a sandbox, monitor after launch, and keep an emergency stop.
FAQ
Related services
Have a project like this in mind?
Tell us where you are today and we will suggest a sensible first step, with no obligation.
Talk to us
