Decide what the agent is allowed to do
A practical control matrix for AI agents: data access, permitted actions, human approval, audit trails, and a way to stop a workflow when it misbehaves.
Before an AI agent touches live work, specify what it may read, prepare and change. Put those limits in the connected systems and approval flow. An instruction in a prompt is not an adequate permission boundary.
For an operations leader, the practical starting point is one permissions table per workflow, agreed with the system owner and the people reviewing the work.
Separate reading, drafting and acting
The table below is an illustrative starting policy for a support agent. Adapt it to your service, data and existing authorization rules.
| Capability | Suggested boundary | Review or control |
|---|---|---|
| Read a customer record | Only fields needed for the assigned request. | Access enforced for the relevant customer and user. |
| Draft a reply | Prepare within the support workspace. | Employee can see the supporting records before sending. |
| Issue a refund | Propose the amount and original transaction. | Authorized person approves the specific transaction. |
| Change a payment destination | No agent authority. | Use the organization's separate verification process. |
Reading access and action authority deserve separate decisions. A tool that retrieves an order should not automatically gain permission to delete it. OWASP's excessive agency guidance recommends limiting tools and permissions, requiring approval for consequential actions, and enforcing authorization outside the model.
Make approval a real decision
A reviewer should see the target record, proposed change, relevant evidence and expected effect. “Approve this action” is insufficient if the person cannot tell which account or amount will change.
Bind the approval to that specific proposal. If the amount, recipient or other material detail changes, require a new decision. Define what happens when the reviewer rejects the work or does not respond. Keep unapproved items in a visible queue with an owner.
A support system can bring company context and operational tools together while retaining human approval. Put the employee’s decision inside the workflow itself.
Keep enough evidence to investigate
For a completed action, you should be able to establish which request triggered it, which record it affected, what was proposed, who approved it and what the connected system returned. Agree what to retain and who may inspect it; avoid collecting unrelated customer information just because logging is available.
Assign someone to review failed actions and recurring corrections. For a broader structure, the voluntary NIST AI RMF Playbook organizes suggested risk-management activities around governing, mapping, measuring and managing. A workflow table is one operating artifact within that wider work.
Rehearse the stop procedure
Test how the team disables an action, routes queued items back to people, identifies affected records and handles incomplete work. Name the person who can pause the system and the person who decides whether it can resume.
Our workflow optimization approach starts with supervised work. Revisit the authority boundary when tools, data access or responsibilities change. A good first release demonstrates that people can inspect and control the system before it receives a larger role.