How Much Should an AI Agent Be Allowed to Do?

AI agent authority should not be one master switch labelled "may automate." It should be separated into five action levels: read, generate, modify, execute and send externally. The output of one level may feed the next, but authority must not carry forward automatically. Permission to read a customer record does not imply permission to edit it; permission to draft an email certainly does not authorise the company to send it.

Approval strength follows three properties: how easily an error can be reversed, how quickly it will be noticed, and how far its impact can spread. The less reversible, less visible and more widely consequential an action becomes, the earlier a person should confirm it. This remains a useful rule even as models and tools change, because the consequences of a bad action do not vanish when the underlying AI improves.

Permission belongs at the action boundary, not inside the model

An agent usually acts by having the model propose a structured tool request and ordinary software execute it; the full function-calling mechanism explains that chain. The control point is therefore not a sentence in the prompt saying "be careful." It is the tool boundary, where every request rechecks the initiator, task purpose, target object, permitted fields, quantity limits and expiry. The model recommends the next step; the policy component decides whether that step may occur.

A sound default is that a person's authority does not grow merely because an agent acts on their behalf, and an agent cannot grant itself another tool or waive an approval. Approval should bind this action, on this object, with these exact parameters, not permanently open a vague capability. Approving one previewed notice to three selected customers does not approve future autonomous broadcasts to the whole customer base.

The read gate: limit what it may see before discussing use

Reading leaves business records unchanged, but that does not make it harmless. An agent with simultaneous access to every customer, payroll data, contracts and private messages has already expanded the exposure surface, even if its final output is only a summary. The read gate restricts sources, records, fields, time range and purpose, while inheriting the initiating person's identity permissions. A task needing customer name and order status should not also return identity numbers, private phone details or full payment data.

Automatic release fits queries with fixed boundaries, filtered fields and controlled volume. Cross-department data, bulk export, sensitive fields or exploratory retrieval unrelated to the current purpose should be denied or sent for approval. The approval screen must say more than "allow CRM access": it should show data categories, estimated record count and purpose. Managers can define the prohibited zones using data boundaries for company material used with AI, then turn those decisions into enforceable read rules.

The generation gate: automate drafts, verify facts and commitments

Generation produces text, tables, plans or code without yet changing a business system or reaching an external audience. The essential boundary here is storing and displaying a draft separately from approved content. Internal ideation and format conversion can run automatically. Material containing prices, dates, policy interpretations, customer commitments or high-impact judgments should carry its sources, flag uncertainty and enter human review.

That does not mean signing every paragraph. Generation is tiered by use. The same summary may be low risk in a person's notes and high risk in a board paper or customer response. Record the source versions and generation time so the reviewer knows what they are confirming. Teams can adapt the tiered checklist for reviewing AI output into machine checks, business review and specialist sign-off. Generation produces a candidate result, not an authorised result.

The modification gate: show the diff, not merely an approve button

Modification writes back to an existing record: filling CRM fields, changing a ticket category or updating a document's status. It is more consequential than generation because downstream processes may treat the error as true data. Automatic modification fits a field allowlist, machine-checkable formats, local impact and reliable rollback. Deletion, overwriting source text, bulk edits or changes to a key business status should require approval.

The reviewer needs the before-and-after difference, evidence for the change, affected objects and rollback method — not a blind message saying "agent requests record update." The write must also check versions. If a person changed the record after the agent prepared its suggestion, the stale suggestion must not overwrite the newer state. A safer path submits a patch, confirms the target version still matches, writes once and records the change. Approval binds the diff; rollback binds the version.

The execution gate: control real side effects and their chains

Execution starts a business action that continues moving: creating a purchase request, booking a service, launching a batch job, closing a ticket or submitting a refund process. Even if the initiating action can be cancelled, it may notify people, reserve stock or trigger another system. The gate must control action type, amount, batch size, frequency, operating window and prerequisites, and should show a dry-run result where possible.

Duplicate execution is a practical failure mode. A network timeout leaves the agent unsure whether the first call succeeded, so it tries again and creates two requests. The execution interface should recognise repeated requests from the same task and return an explicit state: completed, failed or outcome unknown. Money movement, privilege changes, deletion, formal processes and large operational interruptions should not be released because model confidence is high. The agent can assemble evidence and prefill forms; the accountable person performs the final submission.

The external-send gate: approve audience, channel and commitment

External sending deserves a gate separate from execution because information that crosses the organisation's boundary is rarely fully retractable and may create customer expectations or company commitments. Check recipient origin, channel, final body version, attachments, sensitive fields and any price, delivery, refund or service promise. Approval of internal generation is not approval to send. If the body or recipient list changes afterwards, the original approval should expire.

A low-risk notice with a fixed template, valid subscription relationship and small audience may send automatically inside policy. Personalised sales promises, complaint responses, contract correspondence, public publishing and broad campaigns should be previewed by the responsible owner. Rate and total-volume limits prevent one error from spreading quickly. The record should answer who approved which version, for which recipients and through which channel — not merely say "success."

Approval and human takeover must work under pressure

Ask for approval on every action and people soon click mechanically. Omit the evidence and they cannot make a responsible judgment. A useful approval packet contains only what the decision needs: what the agent wants to do, why, where the evidence came from, who will be affected, the worst plausible result and whether rollback exists. Pre-approved policy can release routine low-risk actions, preserving human attention for anomalies, boundary crossings and high-impact steps.

Human takeover is more than a stop button. The person must be able to pause future calls, inspect the current state and completed actions, change the plan, perform one step personally, and resume from an explicit checkpoint. If approval times out, the owner is unavailable or system state is uncertain, the task should pause and escalate rather than silently lower the bar. After takeover, ownership must be visible so the person and agent do not edit the same object at once.

Human in the loop means that before a consequential action occurs, a person has the evidence to decide, enough time to reject, and a practical way to take control.

Validate all five gates with abuse and failure cases

Permission design cannot be accepted only along the happy path. Testers should deliberately request an unauthorised field, replace approved copy, submit twice, expand a recipient list, create a version conflict during modification and let an approval expire unanswered. If the system merely gets the task completed but cannot prove that the gates held under abnormal conditions, it is not ready for production.

1. Read: deny identity, field, volume or purpose outside policy and record the reason.
2. Generate: mark high-impact content as draft and carry sources and uncertainties into review.
3. Modify: bind approval to the exact diff, stop on version conflicts and preserve a tested rollback path.
4. Execute: ensure retries create one side effect, while hard limits hold on amount, rate and high-risk actions.
5. Send externally: invalidate approval when content, attachments or audience change, and let a person pause before release.

The five-level model also reveals when a task does not need much autonomy. Fixed, rule-bound sections are often simpler as an auditable workflow; reserve the agent for the node that genuinely needs judgment. How to choose between an AI workflow and an AI agent works through that decision. The goal is not maximum authority. It is verifiable work completed under the minimum authority required.