An AI agent becomes useful when it can act. It also becomes risky at exactly that moment. The answer is not an approval prompt before every click; it is a small, enforceable permission system that lets routine work pass and reserves human attention for consequential decisions.
Start with the action, not the model. “Connect the CRM” is too vague to approve. Reading a lead, drafting a note, changing a deal stage, exporting 20,000 contacts, and deleting a pipeline are five different permissions with five different consequences.
The shift from answers to authority
A chatbot produces text for a person to interpret. An agent can choose tools, observe results, and repeat actions toward a goal. That difference changes the failure mode. A poor answer may waste time; a poor action can send a customer message, alter a record, expose data, spend money, or stop a production service.
The market is moving from demonstrations to governed workflows. OpenAI's current workspace-agent description, for example, presents role-based access, audit logs, and human confirmation for actions such as messages and record updates as administrative controls. Those product features are useful, but the business still has to decide what each agent may do, under whose authority, and within which limits.
Fresh guidance from the US National Institute of Standards and Technology makes the problem concrete. In an August 27, 2026 NIST article, the authors warn that sharing a person's credentials with an agent creates accountability gaps. They also warn that asking humans too often can create consent fatigue. More approval screens are therefore not automatically more control.
Give the agent its own identity
Do not hand an automation the founder's login, a shared administrator password, or an API key that can do everything. Use a distinct service or agent identity where the platform supports one. Bind it to a business owner and, when it acts for a user, preserve that user's authorization context.
NIST's 2026 agent identity and authorization concept paper frames identification, authorization, auditing, non-repudiation, and prompt-injection controls as connected questions. In plain language, a useful log must answer: which agent acted, which person or process initiated it, which policy applied, what changed, and whether the result succeeded.
- Named identity: one credential set for one agent or tightly related workload.
- Named owner: a person accountable for scope, reviews, incidents, and retirement.
- Narrow entitlements: only required systems, objects, fields, and operations.
- Fast revocation: one documented way to pause the agent without disabling the whole business.
Separate development, test, and production identities. Keep credentials out of prompts and retrieved documents. Rotate secrets and remove unused integrations. An “internal” agent still reads untrusted email, tickets, files, and web pages; internal deployment does not make its inputs trustworthy.
Define a permission in seven dimensions
A tool name is not a permission model. Write every allowed action as a sentence precise enough for application code to evaluate:
Agent: inbound-sales-triage-prod
May: create a follow-up task
Object: lead records owned by EMEA SMB team
Fields: due date, assignee, source link; no email or phone edits
Limit: 100 tasks per hour, one open task per lead
Time: weekdays 07:00–19:00 UTC
Authority: sales-ops policy v3.2
Approval: none inside limits; team lead outside limits
Evidence: initiator, source message, proposed values, result ID| Dimension | Question | Example boundary |
|---|---|---|
| Actor | Which agent, for which user or workflow? | Sales triage, not a shared admin token |
| Action | Read, draft, create, update, send, spend, delete? | Create task; cannot edit contact |
| Resource | Which system, object, record, and field? | Open EMEA leads; three writable fields |
| Volume | How many, how often, and how much money? | 100/hour; refund ceiling of €25 |
| Destination | Where may data or content go? | Internal CRM only; no external export |
| Context | Which time, state, source, or prerequisite? | Only paid orders; only during staffed hours |
| Evidence | What must be logged before and after? | Exact payload, approver, receipt, rollback ID |
The dimensions turn “low risk” from a feeling into a boundary. Creating one internal task may be harmless. Creating 50,000 tasks can disable a workflow. A €10 refund may be routine; 400 refunds are an incident. Risk belongs to the action plus its context, not the verb alone.
Use a four-lane approval matrix
Classify each concrete action by customer impact, data exposure, financial or legal consequence, reversibility, and blast radius. Then choose one lane. Do not let the language model choose its own lane.
| Lane | Default rule | Examples | Required controls |
|---|---|---|---|
| 1. Observe | Allow within narrow scope | Read inventory; summarize tickets; check status | Read-only identity, field filtering, logs |
| 2. Prepare | Allow creation of a private draft | Draft email; propose refund; prepare CRM changes | No external side effect, source links, expiry |
| 3. Act within bounds | Auto-execute only when policy passes | Add tag; create task; pause a failing ad under a cap | Allowlist, limits, idempotency, monitoring, undo |
| 4. Confirm or block | Human confirms exact action, or system refuses | Send contract; publish price; pay supplier; bulk delete | Strong identity, action preview, separation of duties, receipt |
Some actions remain blocked even with a convenient approval: granting itself new permissions, exposing secrets, disabling audit logs, changing the policy that governs its own action, or turning a bounded tool into arbitrary code execution. A person can route exceptional work through the normal administrative process instead.
Reversibility must be real. “We can restore a backup” is not a one-click undo for a customer email, a public post, a bank transfer, or leaked personal data. For reversible writes, store the previous state, use idempotency keys to prevent duplicates, and test the rollback path before calling it a control.
Make an approval worth reading
An approval modal that says “Agent wants to use CRM” asks the reviewer to approve a story. Show the action itself. A good approval packet contains the exact destination, fields or message, amount and currency, affected records, source evidence, policy exception, expected side effects, and rollback or cancellation path.
- What will change? Display an exact diff or final payload, not the agent's summary of it.
- Why now? Link the initiating request and the evidence used.
- How large? Show count, value, recipients, and downstream triggers.
- What is unusual? Highlight the rule or threshold that caused escalation.
- What happens next? State external effects, undo window, and owner.
Approvals must expire when the underlying state changes. If price, recipient, document, quantity, or policy changed after review, request a new decision. Never interpret approval for “refund this order” as permission for a later tool call with different arguments.
Reduce volume by allowing safe work under pre-agreed policy, not by hiding detail. Batch genuinely similar drafts for review, route exceptions to the person who understands them, and provide a daily digest for low-risk actions. Anthropic reports in its 2026 containment engineering note that users approved roughly 93% of its permission prompts in one product context. That product-specific telemetry is not a universal business statistic, but it illustrates why attention cannot be treated as infinite.
Enforce policy outside the model
The model can recommend an action or classify a situation. It must not be the only component deciding whether its own tool call is authorized. OWASP's Excessive Agency guidance recommends granular tools, minimum permissions, approval for high-impact actions, and authorization in downstream systems rather than reliance on the LLM.
Put a deterministic gate between the agent and each consequential system. It validates agent identity, user context, action, resource, limits, current state, approval record, and policy version. The downstream API or database must still reject anything outside the assigned role. Prompt instructions such as “never refund more than €25” are helpful behavior guidance, not an access control.
Prefer create_support_note(customer_id, text) over a generic run_sql(query), and issue_refund(order_id, amount, reason) over unrestricted browser control. A narrow tool is easier to authorize, validate, test, log, and revoke.
Assume outside content may contain instructions aimed at the agent. Anthropic's trustworthy-agents review describes prompt injection as malicious instructions hidden in material such as email and emphasizes that layered defenses cannot guarantee protection. The practical conclusion is simple: untrusted content may inform a proposal, but it cannot expand permissions or bypass the policy gate.
Apply the matrix to real workflows
Sales and CRM
Let the agent read assigned leads and draft notes. Permit it to create a follow-up task with an allowlisted task type and rate limit. Require approval before sending an external message from a person's account. Block contact exports, ownership transfers, and bulk deletion from the agent toolset.
Ecommerce support
Allow order-status lookup after customer verification. Let the agent propose a refund reason and amount. Auto-refund only if the business deliberately accepts a narrow rule—such as a low value, eligible order state, one refund per order, and daily aggregate cap—with immediate logging and anomaly alerts. Escalate everything else. Pair this design with the Rendframe AI-assisted support playbook.
Finance operations
Allow invoice extraction and reconciliation suggestions. Keep bank-detail changes, new beneficiaries, payment release, tax treatment, and ledger-period closure behind existing finance controls. The agent should not approve its own proposal; use separation of duties for material operations.
Software operations
Read logs and draft a patch in an isolated environment. Run tests inside a constrained sandbox. Require normal code review and deployment policy before production changes. Block access to unrelated secrets and prevent the agent from weakening tests, branch protection, or observability to make its task “succeed.”
Roll out autonomy gradually
Build a test set before Stage 3: ambiguous requests, duplicate events, malicious text inside a ticket, stale approvals, changed prices, unavailable APIs, timeouts after a write, partial batch failure, privilege escalation, and attempted action outside business hours. Verify that the system fails closed for authority and fails usefully for the customer.
Every permission needs an expiry or review date. Reassess it when the workflow, model, connector, data fields, owner, or downstream API changes. Keep a kill switch that operations can use without a deployment. Preserve a manual path for the business task, not only a switch that turns the agent off.
Measure control and usefulness
Automation rate alone rewards excessive authority. Review a balanced scorecard:
- successful actions inside policy, with no correction;
- approval rate and rejection reasons by action class;
- approval requests per reviewer and median decision time;
- policy blocks, attempted scope expansion, and prompt-injection tests caught;
- duplicate, rollback, and partial-failure rates;
- customer, financial, or operational outcomes for the workflow;
- time to revoke one agent and reconstruct one action from the audit trail.
A 99% approval rate can mean excellent proposals or a useless gate. Sample approved actions, interview reviewers, and test whether the displayed evidence changes decisions. If nobody rejects, edits, or escalates anything, investigate the interface and routing before declaring success.
Frequently asked questions
Which AI agent actions should require human approval?
Require approval for actions with material customer, financial, legal, privacy, security, or public consequences—especially when they are hard to reverse or affect many records. Use deterministic policy for narrow, reversible actions inside explicit limits.
Is human-in-the-loop enough to make an AI agent safe?
No. People can misunderstand, tire, or approve vague prompts. Combine meaningful review with distinct agent identity, least privilege, granular tools, downstream authorization, limits, logs, monitoring, rollback, and tested failure paths.
Can an AI agent use an employee's account?
Avoid shared credentials. Prefer a distinct agent or service identity and preserve the initiating user's authorization context where possible. This improves least privilege, revocation, and accountability. Platform capabilities vary, so verify the actual identity flow.
How do we reduce AI approval fatigue?
Auto-allow only tightly bounded, reversible work; block prohibited work in code; and interrupt people for exceptions that require judgment. Show the exact payload and change, batch genuinely similar drafts, expire stale approvals, and review low-risk activity in a digest.
Where should AI agent permissions be enforced?
At multiple layers, with deterministic enforcement at the tool gateway and downstream system. The model's prompt may guide behavior, but database roles, API scopes, policy checks, limits, and approval records must decide whether an action executes.
Autonomy is a budget, not a switch
The goal is not to keep a person clicking forever. It is to spend scarce human judgment where consequences are real and let software handle the bounded remainder. Give each agent an identity, turn vague integrations into precise actions, enforce policy outside the model, and expand authority only when the evidence supports it.
Rendframe can map an agent workflow, design its permission and approval matrix, build the policy gateway and audit trail, and run a controlled pilot against real cases. Start with the AI assistant brief template, then see Rendframe's business AI automation service or send us one workflow and its current access map.