An AI assistant is very good at proposing an action. The risk is letting it take that action before anyone has decided it should. A workflow that reads a system state, drafts a reply or prepares a change is useful. A workflow that quietly changes something at 2am, and cannot explain what it did, is not.
The useful question is not "can the model do this?" It is "what happens when it is wrong, and who finds out?" The controls below are worth designing in from the start, rather than bolting on after the first incident.
Give it sight before hands
Start by letting the tool read. Let it look up a record, summarise a queue or report the current state of a system. Reads are easy to grant and easy to check, and they build the case for the next step without risking anything.
Only add a write once someone has watched the read step behave for a while and trusts what it returns.
Make the allowlist the boundary
An assistant should be able to touch only the things you have listed. Not "everything, but carefully" - a specific list of buttons, fields, records or endpoints, held outside the prompt.
The allowlist has to live in configuration the model cannot edit. If the assistant can widen its own permissions, it does not have permissions; it has suggestions.
Default to a dry run
Every write should be able to report what it would do without doing it. Make that the default, so an action is only real when someone passes an explicit flag.
A dry run is not just a safety net. It is the fastest way to check that the assistant has understood the request, especially on the first run against a new system.
Ask before the irreversible
A draft can be undone. A stopped stream, a sent email, a deleted record or a production change cannot. Actions with real consequences should need a second, explicit confirmation, and the confirmation should name the thing being changed - "stop the stream", not "yes".
Keep the list of high-consequence actions short and reviewed. If everything needs approval, nothing does.
One attempt, no guessing
Timeouts are where automation gets dangerous. A request that times out may have succeeded, or it may not have. Retrying blindly can fire the same action twice.
The safer behaviour is to stop and say so: the outcome is unknown, check before acting again. A tool that admits uncertainty is more trustworthy than one that hides it.
Keep a log, and make writes depend on it
Write a line before every real action: what was asked, what was allowed, what happened. If the log cannot be written, the action should not run. That single rule turns "we think it did X" into "here is the record".
Log the decisions, not the customer's data. An audit trail that copies sensitive fields into a second system has created a new problem.
Keep the network small
An assistant that acts on real systems should reach the smallest network it can: local where possible, private ranges otherwise, and no open ports unless a person decided they are needed.
The same idea applies to credentials. Use a key that can only do the one job, and rotate it when it has served its purpose.
Keep a person in the loop
Controls are not there to slow the work down. They are there so a person can stay responsible for the outcome. Review the actions that matter, spot-check the rest, and keep the ability to switch an assistant off quickly.
A short pre-flight list
Before an AI workflow touches real work, it is worth being able to answer:
- What can it read, and what can it change?
- Which actions are listed, and where does that list live?
- Does a write default to a dry run?
- Which actions need an explicit confirmation?
- What happens on a timeout or an unclear result?
- Where is the record of what it did?
- How quickly can it be stopped?
- Who reviews it, and how often?
If some of those answers are "we are not sure yet", the workflow is not ready for the actions that matter. That is not a reason to abandon it. It is a reason to start with the read-only version, prove it, and earn the next step.