Quick answer
Good AI agent UX makes the boundary between what an agent can suggest, what it may do and what needs a person's approval obvious. Users should be able to grant narrow access, inspect the exact proposed action, approve or reject it, see execution status and take control when something goes wrong. Those controls must be backed by authorization checks in the actual system-not just by buttons in the interface.
Key takeaways
- Reading data, drafting a change and executing a change are different permissions. Design them separately.
- An approval is meaningful only when the reviewer sees the action, target, scope and likely consequence.
- Autonomy should depend on risk and context; a confirmation for every low-risk step creates approval fatigue.
- Handoffs need context and ownership. A button labelled “Escalate” is not a complete handoff.
- Activity history, expiry, cancellation and revocation are part of the main agent experience.
- Backend authorization must enforce every action, even if a user approved it in the UI.
What changes when a SaaS AI assistant becomes an agent?
An AI assistant usually helps a user understand or prepare something. An AI agent can also take actions: update a CRM record, send a customer email, create a ticket, issue a refund or change account settings.
That changes the UX problem.
An answer can be wrong. An action can be wrong and affect other people or systems.
Imagine a CRM assistant suggesting that a customer needs a follow-up. A user can judge the suggestion before acting. Now imagine the agent has permission to email every customer with an overdue renewal. The user needs to know which customers, which message, from whose account, how many emails will be sent and whether anything can be cancelled.
The design question is not just “Does the AI feel trustworthy?”
It is “Can a person understand and control the agent's authority at the point it matters?”
In a September 2026 discussion among AI-agent builders, developers asked where permissions should be enforced and when human approval is required for actions such as refunds, emails and data changes. That is a concrete product-design need, not merely a visual trend.
The Agent Action Contract: six questions every action flow must answer
Before designing agent permissions or approval modals, define the Agent Action Contract. This is a Desisle editorial framework for aligning product, UX, security and engineering around one proposed action. It is not a formal industry standard.
| Question | What the user should understand | What the system must enforce |
|---|---|---|
| 1. Who is acting? | Which agent, for which user or organization? | Authenticated agent identity and delegated authority |
| 2. What will change? | Exact action and intended outcome | Allowed operation, validated parameters |
| 3. Where will it act? | Records, accounts, recipients and connected apps | Resource, tenant and data-access limits |
| 4. When must it ask? | Whether approval is needed and by whom | Risk policy and reviewer authorization |
| 5. What if it fails? | What can be stopped, retried, corrected or reversed? | Execution safeguards, recovery and failure handling |
| 6. Where is the record? | Status, actor, outcome and revocation controls | Durable audit trail and current access checks |
If the team cannot answer these questions, a polished AI dashboard will not solve the core trust problem.
Apply it to a real SaaS action
Proposed action: An AI renewal agent prepares follow-up emails for 34 accounts.
- Who: Renewal Agent, acting for a customer-success manager.
- What: Draft and send an email using a reviewed template.
- Where: 34 eligible accounts in one workspace.
- When: Human approval required before external delivery.
- Failure: Failed messages stay unsent and visible; duplicates are prevented.
- Record: The manager can review recipients, approval and delivery outcomes.
This is an illustrative design scenario, not a claim about an existing Desisle client implementation.
How should AI agent permissions work in B2B SaaS?
AI agent permissions should be specific to the action, resource, role and duration, rather than a blanket “give the AI access” switch. A user-visible consent screen should explain the intended work in plain language; the product's authorization layer must independently enforce the limits.
For example:
| Too vague | Better permission language |
|---|---|
| Allow agent access | Read tickets assigned to your team |
| Manage customers | Draft customer replies but do not send them |
| Full workspace access | Update deal notes in the Sales workspace |
| Automate workflows | Create support tickets; ask before sending messages |
Separate connection, permission and approval
These are three different moments:
- Connection: The user connects a CRM, inbox or workspace.
- Permission: The product establishes what the agent is allowed to read or change.
- Approval: A qualified person authorizes a particular proposed action when the policy requires it.
Connecting an application does not mean permission to do everything inside it. Granting permission to draft an email does not mean permission to send it.
Account for teams, roles and tenants
In multi-tenant SaaS, “the user approved it” is not sufficient. A customer-success manager might be allowed to view a deal but not export the whole customer list. An agent acting for that manager must not gain more access than the user has.
The WorkOS September 2026 agent permission checklist explains the engineering principle of intersecting the agent's permission ceiling with the delegated user's current permissions, checking authorization on each tool call and preserving tenant boundaries. The MCP authorization specification also describes scoped access and step-up authorization for connected tools.
For design, this translates into a permission summary that answers:
- Which workspace is connected?
- Which records can the agent read?
- Which changes can it prepare?
- Which changes can it execute?
- Who can approve higher-risk actions?
- When does access expire, and who can revoke it?
Important: The permission sheet communicates the rule; it must never be the only place the rule exists. Backend services need to enforce access on every relevant request. OWASP's Excessive Agency guidance recommends least privilege, downstream authorization and human approval for high-impact actions.
When should an AI agent act automatically versus ask for approval?
An AI agent should pause when the impact of a wrong action exceeds the acceptable risk for that user, resource or workflow. There is no universal approval rule based only on whether an action can be undone.
A practical starting point is a risk-based policy matrix:
| Example action | Risk considerations | Illustrative UX default |
|---|---|---|
| Summarise documents the user may read | Data sensitivity and access boundaries | Run without an action approval; disclose relevant data use |
| Draft an internal reply | No external effect until sent | Generate draft; user edits or discards |
| Update a reversible internal field | Scope, visibility and rollback | Allow within tight limits or review, depending on policy |
| Send an external customer email | Recipient, content and reputational impact | Review the exact message and recipients first |
| Export customer data | Disclosure and privacy impact | Restrict scope and require authorized approval |
| Issue refund / change billing | Financial impact | Explicit approval, amount limits and applicable verification |
| Delete records or change roles | Destructive/security impact | Authorized checkpoint; sometimes prohibit autonomous execution |
These are product-design examples, not security policy prescriptions. Even a read action can be high risk when data is sensitive. A reversible update can still trigger downstream effects. The security team must define actual limits for the product.
Avoid approval fatigue
If an agent asks permission for every harmless step, people stop reviewing. That does not create meaningful oversight.
A better design groups actions when they share the same task, scope, risk and visible consequence, and makes exceptions obvious. For example, an agent can draft 12 internal notes without 12 pop-ups, while the step that sends an external message gets a separate review.
Avoid broad persistent labels such as “Always allow everything.” If recurring approval is supported, restrict it to a defined operation, account, limit and period, with an easy way to revoke it.
Claude's managed-agent permission policies show that tools can use always-allow, always-ask or evaluated-per-call controls. That is a useful implementation example, not a reason to copy the exact defaults into a different SaaS product.
What should an AI agent approval screen show?
A useful approval screen explains the proposed action and its consequences, not just whether “AI may proceed.” Reviewers should not need to reconstruct the action from a long chat transcript.
Example: approval card for a customer-success agent
Review before sending
Agent: Renewal Follow-up Agent
Requested by: Customer Success / account owner
Action: Send 34 renewal reminder emails
From: success@company.example
Recipients: 34 contacts in the Enterprise Renewals segment
Message: Preview full subject and body; edit draft if permitted
Excluded: 3 accounts marked “Do not contact”
Effect: Customers will receive an external email
Controls: Review recipients · Review message · Reject · Approve sending
The counts and email in this fictional UI example are illustrative, not measured product data.
Six elements worth designing
- Intent: What goal the agent is trying to achieve.
- Action: What will happen next, using verbs such as send, update, delete or publish.
- Target: Exact records, accounts, recipients or systems affected.
- Change: Before/after preview, draft or diff where relevant.
- Decision: Clear approve, reject, cancel or request-change actions.
- Consequence: What happens immediately and whether the action can be undone.
Use clear button copy: “Approve and send 34 emails” is better than “Continue.” For a destructive action, state what cannot be restored. For a high-risk action, give the reviewer a real chance to inspect the details.
Approval is not a blank cheque
The approval must correspond to the exact proposed action and parameters. If the target, amount or recipient changes after approval, the system should re-evaluate authorization and obtain a fresh approval when required.
OpenAI's Agents SDK human-in-the-loop guide describes pausing sensitive tool calls before execution and warns that the reviewer must be authenticated and authorized against server-owned pending actions. A browser-supplied decision ID is not proof of permission.
Which states must the approval and execution flow handle?
A trustworthy AI agent experience must show more than “Running” and “Done.” The team should map the full action lifecycle before designing the happy path.
| State | What the interface should communicate | Useful action |
|---|---|---|
| Proposed | What the agent wants to do | Inspect |
| Awaiting approval | Who needs to decide and what is blocked | Approve, reject, request change |
| Approved | Approval recorded; action not necessarily finished | Track execution |
| Executing | What is happening now | View progress, stop where supported |
| Succeeded | Confirmed result, not just “AI says done” | Open affected record |
| Partially completed | Which items succeeded and which did not | Retry failures safely / review |
| Failed | What failed and whether any side effect occurred | Retry or escalate |
| Rejected | Who rejected; action not taken | Edit/replan |
| Cancelled | Whether cancellation happened before or during execution | Review any remaining effects |
| Expired / stale | Approval no longer valid or underlying data changed | Refresh and review again |
Do not confuse approval with completion
“Approved” means the reviewer authorized a proposed action. It does not prove the external API completed the action.
Likewise, “Cancelled” does not necessarily reverse a message already sent. Use separate labels for stopped before execution, cancelled pending work and reverted a completed change. An undo button should appear only when a real, supported reversal is possible.
Make long-running agents understandable
For tasks that run for minutes or longer, show:
- current step and completed steps,
- when the agent is waiting for a person,
- which tools or systems it is using (at an appropriate level),
- safe stop/pause behaviour,
- whether the user can leave and come back,
- what happens if the connection is lost.
A spinning icon is not a status system.
How do you design a human handoff that does not lose context?
A human handoff works when a person receives the reason, the current state, the evidence and the next decision. “Talk to support” without context is not a handoff; it is making the user start over.
There are three handoff moments to design.
1. Human to agent: delegation
Before the agent starts, the user needs to know:
- what job has been delegated,
- what data the agent may use,
- what it can do without further approval,
- when it will stop and ask,
- how to pause, cancel or revoke access.
2. Agent to human: review or escalation
When the agent needs a decision, present a structured handoff:
Task: What was requested.
Completed: What happened already.
Blocked: Why work stopped.
Evidence: Source records, changes and uncertainties the reviewer is authorized to see.
Proposed next action: Specific decision and consequences.
Owner: Who is authorized and responsible for the next decision.
Deadline/expiry: Only where the workflow has a genuine time requirement.
For example, a support agent should not simply say “I cannot refund this.” It could show the eligible amount, applicable policy, evidence, requested exception and reviewer route without exposing information that the reviewer is not authorized to access.
3. Human back to agent: resume
After a person decides, the interface should show whether the agent:
- resumed from the paused step,
- needs fresh information,
- must recheck changed permissions or records,
- will retry only the failed part,
- or cannot continue and must transfer the task to an owner.
Avoid invisible restarts and duplicate actions.
This separation matters for products using multiple agents or nested tools. OpenAI's agent documentation describes approval interruptions arising even from nested agents, while authorization of the human reviewer remains an application responsibility.
What should users see about agent activity, mistakes and revocation?
An AI agent's activity view should make it possible to answer: What happened, why, on whose behalf, and what can I do now? That is more useful than a decorative transcript of internal agent thoughts.
For each meaningful action, display:
- agent name and user/organization it acted for,
- affected resource,
- proposed versus completed action,
- approval or denial where relevant,
- status and time,
- outcome or error,
- available correction or escalation.
The underlying system should maintain accurate logs with actor, resource, permission decision and policy context. The user-facing version should respect the viewer's own permissions and redact sensitive information.
Give users a clear off switch
A settings page can include Connected accounts, Agent permissions, Activity, Pending approvals and Pause / Revoke agent access.
But revocation cannot be cosmetic. It must stop future unauthorized tool calls and, where applicable, invalidate delegated sessions or credentials. Previously completed actions may remain completed; the interface should say so.
For enterprise tenants, separate what a workspace administrator can manage from what an ordinary user may delegate. No design should imply that a normal user can authorize organization-wide changes they do not control.
The WorkOS checklist covers audit logs, cascading revocation and agent identities in depth. Desisle's contribution in this article is the user-facing interaction and decision clarity, not an authentication product replacement.
Example: an agent that updates customer records and sends emails
Consider a fictional B2B SaaS account-management agent asked:
“Prepare renewal follow-ups for accounts due this month.”
A safe, understandable flow could work like this:
Step 1 - Interpret the request. The agent identifies the relevant account group and shows the user which records it will use.
Step 2 - Gather permitted data. The system enforces role, workspace, resource and tenant boundaries. Records the user cannot access are not exposed through the agent.
Step 3 - Draft. The agent prepares recipient-specific emails. Drafting itself has no external send effect.
Step 4 - Review. A qualified reviewer sees the recipient list, proposed messages, excluded accounts and any limitations.
Step 5 - Approve the exact send. The server checks reviewer authority and binds approval to the action that will execute.
Step 6 - Execute and report. Show which emails were sent, failed or were skipped. Prevent duplicate sends on retry.
Step 7 - Escalate exceptions. If a high-value customer needs approval from a different role, route only that exception to the correct owner with context.
Step 8 - Record and recover. Keep an auditable activity history and show any supported follow-up actions.
The value of the agent is not “it can send email.” It is that the user can delegate a bounded job with clear control over external consequences.
Common AI agent UX mistakes to avoid
| Weak pattern | Why it fails | Better direction |
|---|---|---|
| One “Allow full access” button | Hides scope and consequences | Plain-language, narrow permissions |
| All actions run on chat instruction alone | Confuses user intent with executable authority | Server-side checks and risk-based action gates |
| “AI wants to continue - Approve?” | Gives reviewer no real information | Exact action card with targets and changes |
| Approval required for every small step | Encourages blind clicking | Bound, risk-aware approvals |
| Agent says “Completed” after an API request was made | Can conceal failure or partial success | Confirm result from the target system |
| “Undo” where no reversal exists | Misleads users | Honest cancellation/recovery language |
| Human escalation without context | Makes reviewers start again | Structured task/evidence handoff |
| Approval expires but button remains active | Creates stale or unsafe decisions | Expiry state, revalidation and fresh approval |
| Revocation hidden in admin settings | Users cannot regain control | Clear pause/revoke controls for authorized roles |
| Agent executes with user's full token | Overscoped, poor attribution | Narrow delegated identity and downstream enforcement |
How should product teams test AI agent UX before shipping?
Do not test only whether participants like the agent. Test whether they can predict and control what it will do.
Run scenario-based sessions with representative roles and risk levels.
Five tasks to test
- Permission comprehension: Can a user explain what the agent may read, edit or send after reviewing the consent screen?
- Approval comprehension: Can they identify exactly what will change before approving an action?
- Unauthorized request: What happens when a lower-permission user asks the agent to perform an admin action?
- Interrupted workflow: Can a reviewer understand a paused task and safely resume, reject or redirect it?
- Recovery and revocation: Can users find an action that failed, identify whether it had effects and stop future agent access?
For each test, record observed behaviour, not only preference ratings.
Useful product measures
- percentage of reviewers who correctly predict the action before approval,
- approval decisions reversed because the preview was misleading,
- percentage of blocked or unauthorized actions correctly denied,
- time to resolve a handoff,
- repeat approvals without inspecting material details,
- duplicate or partially executed actions,
- user ability to locate activity and revoke permissions,
- end-to-end task completion with acceptable error and intervention rates.
A rejection is not necessarily a bad outcome. It may show that the control worked. Treat “few human interventions” as a goal only when the agent is operating within a genuinely safe scope.
NIST's AI RMF Playbook recommends defining human oversight responsibilities in the context of organizational risks. It does not prescribe one approval UI for every SaaS product.
From Desisle's AI product work: reduce hidden complexity, not human control
Desisle's published Clair AI case study describes the redesign of a conversational-agent SaaS platform. The team simplified a complicated setup into Upload Data → Train Agent → Customize Brand → Deploy, provided previews and made deployment activity easier to inspect.
That case study is evidence of Desisle's work on conversational agent setup and operational UX. It does not establish that Desisle designed the specific authorization/approval architecture proposed in this article.
The relevant design lesson is that complex agent behaviour needs an understandable product interface. In an action-taking agent, that principle extends to the ability to define authority, see consequences and hand control back to a person.
For related trust and review patterns, Desisle's AI SaaS UX Playbook provides broader guidance. This article focuses on the smaller but critical problem of acting on someone's behalf.
A practical AI agent UX checklist for your next sprint
Before approving an agent feature for release, ask:
Permissions
- Can every user tell which data and actions the agent can access?
- Are organization-level and user-level permissions clearly separated?
- Can authorized users narrow, pause and revoke access?
Approvals
- Does a checkpoint show the exact action and affected objects?
- Is the right person being asked to approve?
- Does approval expire or require refresh if the action changes?
- Have you avoided both silent high-risk actions and pointless confirmations?
Execution
- Do users see proposed, pending, executing, partial, failed and completed states?
- Do you distinguish cancellation from reversal?
- Are retries safe from duplicate side effects?
Handoffs
- Does the human receive the task, current state, evidence and next decision?
- Can work resume without losing context or silently repeating actions?
- Is there an accountable owner when the agent cannot proceed?
Governance
- Does the backend enforce authorization independently of UI and model text?
- Can an administrator audit actions and stop the right agent?
- Have roles, resources and cross-tenant boundaries been tested?
A useful review output is not a “trust score.” It is a list of which action, role, state or handoff remains ambiguous or unsafe.
The bottom line
Good AI agent UX is not a chatbot with an Approve button added later.
It is a complete interaction system in which people know who is acting, what can change, when they must decide and how control returns to them.
Start with the six-question Agent Action Contract. Map the permission scope, approval rules, pending and failure states, human handoff and audit trail before polishing the interface.
If your SaaS product has an agent that reads, edits, sends, approves or triggers workflows, Desisle's AI Product UX service is a relevant next step. For a focused evaluation, the free 3-day design trial can start with one real agent action, approval screen or human handoff flow. Confirm the current offer details on the live site.
FAQ
Q: What is AI agent UX design?
AI agent UX design defines how people delegate tasks to action-taking AI, understand its authority and review results. For SaaS products, this includes permission settings, action previews, approval checkpoints, execution status, human handoffs, recovery and activity history. The interface explains control; backend systems must still enforce authorization.
Q: When should an AI agent ask for human approval?
An AI agent should request approval when a proposed action exceeds the risk the product and user have agreed to accept. External messages, financial changes, sensitive data disclosure, bulk edits, deletions and permission changes often need tighter checks. The exact policy depends on user roles, affected records, reversibility and organizational rules.
Q: What should be displayed in an AI agent approval dialog?
Show the agent and requesting user, exact action, affected records or recipients, material changes, likely consequence and clear approve/reject controls. Where relevant, include a draft or before/after preview. The application should verify that the reviewer is authorized and that approval still matches the action executed.
Q: How do permissions differ from approvals in an AI agent?
Permissions define the actions and resources an agent is allowed to access in general. An approval authorizes a particular proposed action at a particular moment when policy requires it. A connected account does not grant unlimited authority, and one approval should not silently authorize a different action or changed parameters.
Q: How should an AI agent hand control to a human?
The agent should pause the relevant action and provide the human with the task, completed steps, reason for escalation, supporting context, proposed next action and clear ownership. After the decision, the product should show whether execution resumed, failed or requires updated information rather than restarting work invisibly.
Q: Can an AI agent perform actions without asking every time?
Yes, within a clearly defined and enforced scope. Low-risk actions may run automatically, while higher-impact actions can require human approval. The policy should consider data sensitivity, user role, external effects, reversibility and scale. Persistent approval should never be broader than the user and organization intend.
Q: Does an approval button make an AI agent secure?
No. A confirmation screen helps humans understand a decision, but it does not enforce permissions. The server must authenticate the reviewer, verify their authority, check the agent's scope and target resource, bind the approval to an exact action and reject stale, changed or unauthorized calls.
Q: How do users revoke AI agent access in SaaS?
Provide an accessible permissions area where an authorized user or administrator can pause or revoke a connection or agent role. The backend must then invalidate or narrow the relevant delegated access. The interface should explain that revocation prevents future access but does not automatically undo actions already completed.