Why agents change the policy problem
A chat assistant produces text. An agent takes actions: it calls tools, reads and writes data, sends messages and sometimes spends money. That moves policy from what a system may say to what a system may do. The central control question becomes which actions an agent can take, on whose authority and within which limits.
Agents also chain steps. A harmless permission in one step can combine with another to produce an outcome nobody approved. Guardrails must therefore apply to the sequence as well as to each call.
Give every agent its own identity
Start with identity. An agent should authenticate as itself, not borrow a person's long-lived credentials. A distinct identity lets you grant narrow permissions, see exactly what that agent did and revoke access without disrupting anyone else. Prefer short-lived credentials issued for a specific task over standing access.
Record who is accountable for each agent. If an agent acts on behalf of a user, the policy should evaluate both the agent and the user, and the more restrictive of the two should win.
Guardrails worth defining
- Tool allow-lists: the specific tools and endpoints an agent may call, denied by default.
- Parameter limits: bounds on arguments, such as maximum payment amount or permitted recipient domains.
- Data scope: which datasets and records the agent may read or modify.
- Rate and budget ceilings: maximum calls, tokens or spend per task and per day.
- Approval gates: actions that require a human decision before they proceed.
- Kill switch: a tested way to halt an agent immediately.
Where humans belong
Human approval is a control, not a decoration. Reserve it for actions that are irreversible, costly or externally visible, such as sending a customer message, deleting records or moving funds. If every step needs approval, reviewers will click through without reading, so tune the threshold and measure how often approvals are changed or rejected.
Audit and review
Log each tool call with the agent identity, the policy decision, the parameters and the result. Keep the reasoning trace where available, but do not treat it as proof, because a stated explanation may not match actual behavior. Review a sample of agent runs regularly and use findings to tighten policy.
Start with a narrow deployment: one agent, a small tool set, strict limits and full logging. Widen permissions only when the logs show the agent behaves within bounds.
A staged rollout for agents
A sensible rollout begins in observe mode, where the agent proposes actions and a human executes them. Once reviewers agree with the proposals most of the time, allow low-risk actions automatically while keeping approval for costly ones. Track the rate of reversed or rejected actions, because a rising rate means the permissions are wider than the agent's reliability supports.
Reduce permissions again if a new model version, new tool or new data source changes the agent's behavior. Guardrails are not a one-time setup. They are a standing review that follows the agent through its changes.
Common mistakes to avoid
Avoid giving an agent a shared service account because it is convenient, since that erases accountability. Avoid approval prompts that show only a summary and hide the parameters, because reviewers cannot judge what they cannot see. Avoid launching with broad permissions and promising to tighten later, as later rarely arrives. Each of these is easy to prevent at design time and expensive to repair after an incident.
