Guardrails for AI agents that take real actions
An agent that only writes text is low-stakes. An agent that can send emails, move money or change records is a different animal. Here's how we make action-taking agents safe enough to trust.
There is a bright line between an agent that answers questions and an agent that does things. The first can be wrong and waste your time. The second can be wrong and issue a refund, delete a record, or email the wrong customer.
Once an agent has hands, correctness is no longer enough — you need containment. The question stops being 'is the model smart?' and becomes 'what is the worst thing this can do, and what stops it?'
Constrain what the agent can reach
The strongest guardrail is the one the agent cannot talk its way past. Give each tool the narrowest scope that does the job: a read-only credential where it only needs to read, a spending limit baked into the payment tool, a query interface that can never touch tables it has no business seeing.
Enforce these limits in the tool layer, not the prompt. A prompt that says 'never refund more than a hundred' is a suggestion; a refund tool that rejects anything over a hundred is a rule. Assume the model can be talked into anything, then make sure the things that matter are impossible rather than discouraged.
Gate high-stakes actions behind a human
Not every action deserves the same level of trust. Sort them by blast radius. Low-stakes, easily reversible actions can run autonomously; irreversible or expensive ones should pause for a human to approve.
The trick is to make the human step cheap. Present exactly what the agent intends to do, why, and what it will affect — a single clear approval, not a wall of logs. Done well, the human handles the 20% that carries real risk while the agent runs the routine 80% unattended.
- Auto-run: read-only lookups, drafting, reversible internal changes
- Approve first: sending external messages, moving money, deleting or overwriting data
- Never automate: irreversible actions with legal, financial or safety consequences
- Always: a confirmation step that shows the exact action before it fires
Treat retrieved content as untrusted input
An agent that reads emails, web pages or documents is reading text an attacker can write. Prompt injection is not a hypothetical — a hostile instruction buried in a page the agent fetches can hijack its behavior if you let tool output flow straight into the plan.
Keep a firm boundary between instructions and data. Content the agent retrieves is information to reason about, never commands to obey. The privileged actions an agent can take should be fixed by your system, not expandable by whatever the agent happens to read mid-task.
Make every action reversible and logged
Assume the agent will occasionally do the wrong thing, and design so that mistakes are cheap to undo. Prefer soft deletes over hard ones, drafts over immediate sends, staged changes over direct writes. An undo button is worth more than an extra point of accuracy.
Every action the agent takes should leave a trail — what it decided, what it called, with what arguments, and what came back. When something goes wrong you need to reconstruct the decision exactly, and when a regulator or a customer asks, you need to answer with a record, not a shrug.
Bound the loop and fail closed
Agents can get stuck — retrying, looping, burning tokens on a task they will never finish. Put hard ceilings on steps, tool calls, time and spend, so a confused agent stops instead of spiraling. A run that ends is recoverable; one that runs away is an incident.
And when the agent is uncertain or hits a limit, the safe default is to stop and escalate, not to guess. An agent that hands off gracefully with a clear summary of where it got stuck is far more trustworthy than one that pushes through on a coin flip. Users forgive 'I need a hand with this'; they do not forgive a confident wrong action.