Guardrails for AI agents that take real actions
An agent that can only read is a search feature. One that can write needs permission boundaries, approval gates and an audit trail.
- Written by
- Xalicon Engineering · AI practice
- Reviewed by
- Xalicon Editorial · Technical review
- Published
- Updated
- Reading time
- 8 minutes
Draft article
This article is written by the Xalicon team and is in editorial review. The reasoning reflects how we work today; the draft label means it has not yet had a final technical and editorial pass.
The gap between reading and acting
A retrieval assistant that returns a wrong answer is a quality problem. An agent that issues a wrong refund is a financial one. The engineering requirements are different in kind, not just in degree.
The useful mental model is not "how do we make the model reliable" but "what happens when it is wrong" — the same question you would ask about any component that can fail.
Scope permissions to the task
An agent should operate with the permissions of the user it acts for, never with a service account that can do everything. If a user cannot refund an order, neither can an agent acting on their behalf.
Tools should be explicitly allow-listed per task rather than exposing an entire API surface. Narrow tools with validated parameters are far easier to reason about than a general-purpose endpoint.
Approval gates for irreversible actions
Classify every action by reversibility. Reading data, drafting a message and creating a draft record are safe to automate. Sending money, deleting records and contacting customers are not.
For irreversible actions, the agent prepares and a person confirms. Done well this is still a large efficiency gain — the work of assembling context is what took time, not the click.
- Reversible and low impact: execute automatically
- Reversible but visible to customers: execute, notify, allow undo
- Irreversible or financial: prepare, require explicit human approval
- Outside defined scope: refuse and escalate with context
Treat retrieved content as untrusted
If an agent reads documents, emails or web pages, it is reading text that someone else wrote — and that text may contain instructions aimed at the model rather than the reader.
Defences are layered: keep retrieved content clearly separated from instructions, validate tool parameters against a schema before execution, and never let content read during a task expand the tools available to it.
Log everything, replayably
Every agent run should produce a complete trace: inputs, retrieved context, model responses, tool calls, parameters and results. When something goes wrong, the first question is always what the agent actually saw.
Replay capability turns incidents into test cases. A failure that can be reproduced can be fixed and then added to the evaluation set so it never recurs silently.
- AI
- Agents
- Security