How should a business control AI agent actions?
Separate the agent’s ability to recommend an action from its authority to execute it, then grant authority gradually according to consequence, reversibility, and evidence.
An agent differs from a normal assistant because it can choose steps and use tools. It may search records, update a CRM, issue a refund, schedule work, send a message, or trigger another system. That action surface creates value and risk.
Strategic Brief
The core design decision is not how autonomous the agent can be. It is where the business wants judgment, permission, and accountability to sit for each action.
What are the levels of agent authority?
Use a simple authority ladder:
- Observe: read authorized data and explain.
- Recommend: propose an action with evidence and rationale.
- Draft: prepare the action but require human submission.
- Confirm: execute only after a user reviews critical details.
- Act within limits: execute reversible, low-impact actions under policy.
- Escalate: route unfamiliar, high-impact, or conflicting cases.
- Prohibit: deny actions outside approved purpose.
Autonomy is not one system-wide setting. An agent may update a low-risk internal tag automatically, draft a customer credit for approval, and be prohibited from changing bank details.
Choose an approval posture by action type
Allow automatic retrieval with visible evidence
The action does not change a system of record, but data access and unsupported conclusions still matter.
Enforce user permissions, show sources, log access, and provide an escalation path.
Read access can still expose restricted data or combine harmless facts into sensitive information.
How should the approval policy be designed?
Evaluate at least six dimensions:
- Action: what tool and operation is being requested?
- Subject: which customer, employee, account, or system is affected?
- Magnitude: what amount, volume, duration, or reach is involved?
- Evidence: are required facts present, current, and consistent?
- Reversibility: can the action be undone completely and quickly?
- Authority: does this user and agent have permission under current policy?
Use deterministic policy for hard limits. The model can extract context and propose an action; code should enforce permissions, transaction ceilings, required fields, and prohibited destinations.
What should the approver see?
An approval interface should present:
- the exact action and affected record;
- material parameters, amount, recipient, and deadline;
- the evidence used and any conflicts;
- the rule or policy that applies;
- what the agent is uncertain about;
- expected downstream effects;
- options to approve, edit, reject, or escalate.
Do not ask “Approve?” below a long conversation. Put the decision itself at the center.
Explore common agent control failures
Untrusted content attempts to redirect the agent, reveal data, or misuse a connected tool.
Retrieved text or external input contains instructions unrelated to the user's authorized task.
Treat external content as data, constrain tool arguments, isolate sensitive tools, validate policy outside the model, and test adversarial cases.
How do you evaluate an agent?
Test the complete trajectory, not only the final answer.
Task success
Did the workflow reach the intended state? Inspect whether the agent selected the correct tools, supplied valid arguments, handled tool failure, and stopped at the proper condition.
Policy compliance
Did it respect access, monetary, geographic, and approval rules? Test near-boundary values and conflicting instructions.
Safe failure
Did it ask for missing information, abstain, retry safely, or escalate? An agent that completes every task may be bypassing necessary controls.
Operational behavior
Measure latency, loop length, tool error, duplicate action, cost per completed workflow, human intervention, and rollback.
Adversarial behavior
Include malicious documents, indirect prompt injection, manipulated tool results, stale data, confused identity, and attempts to split a prohibited action into smaller permitted actions.
How should authority expand?
Increase authority only after stable evidence at the current level. Do not move from demonstration to autonomous action in one release.
Expand agent authority through evidence gates
Observe real work without influencing the production decision.
- Run on historical or mirrored cases.
- Compare proposed trajectories with expert actions.
- Build failure, policy, and adversarial evaluations.
The agent's recommendations and tool choices meet thresholds on representative cases.
What should an owner ask before launch?
- What is the narrow job and which actions are out of scope?
- Which identity acts, with what exact permissions?
- What conditions require approval or escalation?
- Can every action be attributed, explained, and reversed?
- What prevents duplicate, runaway, or split transactions?
- What happens when data, tools, or models fail?
- Who monitors behavior and can stop the system?
- Which evidence would justify more authority?
The safest useful agent is not powerless. It is powerful within a deliberately small, observable, and revocable boundary.