1. An agent's risk comes from its power to change the external world
Separating two kinds of work clears up much of the confusion at once. One is assistance: AI summarises meeting notes, compares two documents, drafts an email, or assembles a list of candidates from public material. Once the person receives the result, they still decide whether to use it and still place it into an external system themselves. The other is delegation of action: while it is running, AI chooses tools on the basis of the information already available, reads email, queries databases, alters tickets, creates calendar events, sends messages or triggers payments. The latter is not simply generating more text. It changes system state on behalf of an identity.
Anthropic's distinction between workflows and agents offers a useful reminder. Workflows are generally orchestrated through predefined code paths, whereas agents let the model decide dynamically what to do next and which tools to use. An agent continues to judge and act on the results returned by its tools. The practical issue, then, is not whether a product is called an “assistant”, an “automation” or an “agent”, but how far it can choose its own path, encounter external input and make changes through write operations. The article also notes that greater autonomy brings cost and potentially compounded errors, so checkpoints and stopping conditions are needed. [1]
External input deserves separate attention. It is easy to imagine content returned by a tool as a trusted database field. In practice, it may be an email body, a web page, an attachment, a customer message or text synchronised from a third-party system. AgentDojo constructs this kind of environment with 97 tasks and 629 security test cases. Its subject is agents that read untrusted data and call tools; its abstract reports that prompt injection can affect such systems, and that then state-of-the-art models failed many tasks even without an attack. [2] This does not show that every AI connected to tools is unsafe, still less that a benchmark result can be extrapolated into a real-world incidence rate. It does establish an engineering fact: content that appears merely to be input can shape the action the agent takes next.
For that reason, a task name does not explain very much when assessing delegation of action. “Handle my email” may mean grouping unread messages by subject, but it may also include scanning attachments, drafting replies, sending them in someone's name, synchronising content into a CRM system and adding labels to contacts. Errors in the first action can usually still be seen in the interface. The later actions transmit information outward, alter records and may lead other people to act on false information. Calling them all one task hides the highest-risk step behind a convenient description.
A more useful approach is to draw an action chain before connecting a system: where does the input come from; which tools can the model choose; under which account does each tool run; which objects can it read; what can it write, send, delete or buy; and can returned tool data enter the next round of reasoning? This does not require a complex architecture diagram. Even a simple one-page table can force a team to identify permissions it had not made explicit. “Draft” and “send”, for example, should be separate capabilities; “search customers” and “export a customer list” should not share default permissions either.
This also explains why not every multi-step system needs to be treated as a high-risk agent. For work with a clear definition, fixed path and results that a programme can validate, a predefined workflow may be more predictable than letting a model choose the next step openly. Extracting dates every day from public notices with a fixed format, then stopping when format validation fails, is not the same kind of autonomy as letting a system browse the web freely, select contacts and decide whether to send an email. The concern here is not to label products, but to identify the capability that actually carries a decision into the external world.
Seen this way, the phrase “delegate to AI” in the title has a precise meaning. It does not mean offering advice for you. It means using permissions in your name or your organisation's name to place other people, accounts, data or resources in a different state. That is where the boundary should begin.
2. Consequences, permissions and reversibility should jointly determine delegation levels
A task that looks simple is often the point at which vigilance drops most easily. Deleting a record takes one click. Adding access for someone may require only a choice from a drop-down menu. Forwarding a file to the wrong address takes one press of Send. These actions are simple at the operational level, yet their consequences may be substantial. Conversely, a complex read-only analytical task may take time without being a better candidate for reduced human control than an irreversible write.
Risk-management frameworks do not equate risk with whether a model may make a mistake. In the NIST AI Risk Management Framework (AI RMF), risk is framed as a combination of the likelihood of an event and the magnitude of its consequences. It also stresses that acceptable risk depends on the specific application, context and risk tolerance; where clear negative effects are approaching, serious harm is occurring, or risk is unacceptable, a system should be able to stop development or deployment safely. The framework also calls for the intended use, context of use, affected people, potential impacts and application scope to be documented. [3] [4]
This framework does not supply an individual user or small team with a universal “automation score”. Its value is that it requires the context to be written down first. On that basis, this article offers an editorial recommendation: whenever an action is to be handed to AI, take no more than ten minutes to examine four variables. This is not a compliance form and should not be compressed into a seemingly precise aggregate score. If any one of the four rises, autonomy should be reduced or the action should be separated into parts.
The first variable is consequence and irreversibility. Will the action create a commitment, transfer funds, alter a service, affect a third party's arrangements, or leave a record that is difficult to remove? The difference between “AI changes the title of my meeting” and “AI cancels a meeting that participants have already accepted” is not the quality of the wording, but whether the consequences can spread. When judging irreversibility, do not ask only whether the system has an undo button. Even if a database field can be changed back, it may not be possible to restore the relationships and expectations changed by an email already delivered, information already disclosed, or a commitment on which someone else has already made arrangements.
The second variable is the scope of permissions. Whose identity does it use, and does it have read-only, limited write or administrator-level permissions? Can it operate on one project, or on every customer, folder and account? The broader the scope of its permissions, the further a single error in judgement can reach. Many systems are connected straight to a primary account during a trial because that is convenient. From a risk perspective, that amounts to handing over the hardest-to-recover capabilities first and hoping a prompt will be enough to constrain them. Permissions should be designed before prompts.
The third variable is data sensitivity. To complete the action, will the system see identifying information, private communications, health records, financial data, customer information, source code, business plans or contract content? Will its output give that material to a new recipient? Read-only does not mean harmless: the act of reading can itself create exposure. Not writing to a database does not eliminate external consequences either. If an analysis reaches someone who should not have seen it, the harm has already occurred. The distinction between authorised internal handling and disclosure to a new service, contact or system matters especially here.
The fourth variable is observability, stoppability and recoverability. Can an error be discovered independently, rather than only because the system says it acted correctly? Is there a clear pause point that can stop the process before its effects grow? Can a write be previewed beforehand and rolled back afterwards, and who takes over when something unusual occurs? All three matter. Even an action that is theoretically reversible may still be effectively uncontrollable in practice if its logs cannot be read, its trigger conditions are unclear, or an administrator will not see an alert for several hours.
Applied in this way, the same kind of work can fall into different levels. Low-impact, reversible work whose results can be verified can usually be delegated with more confidence. Examples include asking a system to classify public material under predefined themes, or to produce a candidate list from internal read-only tickets for human review. The point is not that the model is “very intelligent”, but that the output can be compared, the task rerun, and an error will not directly change a third party's rights or resources.
The second category is bounded external action: the result has an effect, but the target, scope, amount, data destination and alternatives can be shown clearly before execution. These actions suit AI preparing the work up to the final step and then passing it to a responsible person for approval. Examples include drafting an external email, generating a purchase request below a preset amount, proposing a change to a non-critical CRM field, or arranging a calendar alteration pending confirmation. Approval here is not a courteous nod. It keeps the actual commitment at a point where it can be assessed.
A third category should not be quietly cleared by a general “risk score”. Where an action would create a major or difficult-to-reverse commitment, use overly broad permissions, disclose new sensitive material, or make a substantive ruling on contested interests, it should remain within explicit human control. AI may help to find material, summarise evidence, check established rules or draft several options. It must not be allowed to take final responsibility for someone merely because the task has a short name or few execution steps.
One uncomfortable but necessary fact must remain. No universal table can replace professional, legal or business judgement. NIST likewise warns that risk measurement is limited by data, metrics and context; some impacts are difficult to quantify fully, and metrics may simplify or obscure important differences. [3] The point of the four-variable check is not to create the illusion that “anything below 60 may be automated”. It is to make a team see the most important questions before permissions are connected: who will be affected, who will remedy an error, and why do we think the consequence is bearable?
3. Approval is a gate before a commitment, not a nod after the fact
Many products already have a “please confirm” button, but confirmation does not automatically amount to control. Some confirmation windows say only “the operation is about to be performed”, without showing the target, amount, permissions, changes or data destination. Some pack a dozen unrelated actions into one bulk tick box. Others require assent before a user can see the final content. Such approval asks a person for a gesture that leaves accountability unclear after the system has effectively made the decision. It neither helps the person identify an error nor resists becoming a reflex in frequent use.
OWASP identifies high-impact actions taken without independent verification and approval as a typical excessive-autonomy problem. It recommends limiting extended functionality and permissions, executing in the user's own context, retaining human approval for high-impact actions, and logging and monitoring activity in extensions and downstream systems. [5] These are security-practice recommendations, not proof that adding a confirmation dialogue makes a system safe. On the contrary, they suggest that approval matters only when the approver can see information sufficient to change the decision.
This article recommends designing approval as an approval package rather than an isolated button. Before entering the execution queue, the system should present at least the following in terms an ordinary person can understand: what this step will do; the final parameters, text or changes; the identity and permissions under which it will run; which objects it will affect, what amount is involved and how many records will change; which data will leave the current system and where it will go; how long the window for reversal is, if the action can be reversed; and whether a more conservative alternative exists if it is not carried out. For batch operations, it should also make the total, sample results and exceptional items clear, rather than displaying only “500 items processed”.
This may look laborious, but it tests whether the system actually knows what it is about to do. If an agent cannot say “which version of the text will be sent to which three contacts”, “which account will be charged how much”, or “which fields will be changed to what”, it is not yet in a position for a person to approve meaningfully. Asking someone to click Confirm at that point is not human oversight. It transfers invisible complexity to a person without enough information.
Actions that suit an approval queue share a feature: their consequences can be presented concretely before they occur, and their scope can be bounded. External email is a common example. AI can draft a reply from already approved facts, list recipients, and identify attachments and cited sources; after seeing the final version, the responsible person decides whether to send it in the organisation's name. Content publication, low-value payment requests and non-critical record changes can follow the same pattern. The key is not the class of operation, but whether the approver can understand the result before execution and has a real opportunity to amend, refuse or request more information.
That requires one large task to be separated into different actions. In procurement, for example, AI can collect quotations, organise requirements, check budget rules and produce a purchase-order draft. It can also remind people who has not yet approved where the rules are clear. But “select a supplier”, “alter the price”, “accept payment terms” and “make a commitment on behalf of the organisation” must not be hidden inside the phrase “help me place an order”. The first part can be prepared automatically; the latter should have real gates set according to the amount, contractual terms, relationship effects and authorisation rules.
The frequency of approval should serve judgement, not liability avoidance. For frequent, low-impact actions that can be checked again, confirmation one by one may encourage automatic clicking. More appropriate measures may be value caps, rate limits, dual review, a small-scale trial first, or sampling checks of batch actions under clear rules. Conversely, for an infrequent but consequential action, a critical confirmation should not be skipped simply because the system is “usually accurate”. System accuracy is background information, not an authorisation to outsource commitments.
The limits of approval must also be acknowledged. A responsible person cannot judge the appropriateness of medical advice from a summary on a page alone, nor can they stand in for legal or procurement expertise without understanding contractual risk. An approver must have both the authority and the facts and capacity to take responsibility for what is approved. Otherwise the right action is not to add another confirmation box, but to give the matter to the appropriate person or return AI to a preparatory and explanatory role.
4. Some decisions must retain human responsibility and room for appeal
“Should not be delegated” does not mean AI is useless in these fields. It can organise long documents, extract defined fields, mark where material is missing, set rules and cases side by side, and generate options for comparison. What cannot quietly be handed over is the final power to decide that causes someone to lose an opportunity, gain access, assume an obligation or be assigned a consequential label. At those moments, what is needed is not an output that merely looks plausible, but an actor able to explain its reasons, answer questions, be corrected and bear the consequences.
NIST's account of human-AI relationships is more accurate than saying that every AI system must be reviewed by a person. Human-AI configurations can range from fully autonomous to fully manual; some systems may need oversight and others may not. But where AI participates in decision-making and oversight, human roles and responsibilities should be clearly defined and differentiated. [6] NIST's AI RMF also includes mechanisms by which users and affected groups can report problems and appeal system outcomes among the matters to be established and assessed. [4] This does not automatically yield a universal list of activities that must never be automated. It does set a floor for responsibility design: when an outcome can reasonably be contested, it must be clear who made the decision, on what basis, and how a review can be sought.
This article recommends treating the following four categories of action as responsibility red lines. This is not legal advice and does not claim that automation can never be used in every jurisdiction or circumstance. It means that AI may assist, but final control and an accountable decision must remain with a specifically identified person.
The first category is binding legal, financial, employment, medical or external commitments. Entering into or ending a contract, agreeing payment terms, making a hiring or termination decision, or stating a medical or legal position on behalf of an individual all put a person or organisation into a relationship that an “undo operation” cannot readily remove. AI can summarise differences between terms, check whether existing approvals are complete, and draft communications. It should not make a commitment effective on its own. The issue here is not whether the model is clever enough, but who can explain why the commitment was made and take responsibility for correction, compensation, communication or review when a dispute arises.
The second category is granting, expanding or withdrawing access. Giving a new employee access to a production system, adding an external collaborator to a shared space, elevating an account to administrator privileges, or freezing a user's access all change what others can see and do, and whether they can continue to work. Access control is often the starting point for other risks: one erroneous grant may make later reading, deletion or external sending of data possible; one erroneous withdrawal may prevent someone from doing urgent work. AI can collect application material, compare it with predefined role matrices, and point out conflicts and omissions. But the final granting, expansion or withdrawal of high-privilege or exceptional access should be made by a person with responsibility for authorisation.
The third category is disclosing identifying information, private communications, customer information or trade secrets to a new recipient. A particular illusion needs to be resisted here: the system is merely “helping to forward” something or “finding someone to collaborate with”, so no substantive decision is involved. In fact, choosing the recipient, the external service or whether to attach the original files is itself a disclosure decision. Even where the content is not altered, harm may not be fully recoverable once the scope of disclosure expands. AI can redact, classify and prepare material within an authorised scope, and flag its sensitivity level. Whether particular content should be given to a new party should be decided by someone who understands the purpose, authority and consequences.
The fourth category is a contested substantive judgement that changes another person's opportunities, rights, treatment or reputation. Recruitment screening, performance handling, insurance- or credit-related recommendations, customer-complaint handling, content enforcement and decisions about academic eligibility can all involve incomplete facts, differing interpretations and matters that affected people have reason to challenge. AI can extract explicit fields from a CV, flag missing material or organise candidate information under public rules. But without a basis that can be examined, a clear accountable person and an accessible route for review, it should not independently eliminate, refuse, downgrade or attach a characterising label.
Some will say that people too are biased, tired and arbitrary, and that retaining a person does not automatically produce fairness or accuracy. That is right. Human review is not magic; under time pressure, it may even become a mechanical stamp on a machine's recommendation. This article emphasises human responsibility not because people are always more correct, but because some consequences require a role that can understand evidence, give reasons, accept challenge, change a decision and bear responsibility. The design aim is not to shift every error on to one signatory. It is to make the system's judgements, evidence, permissions and routes to remedy visible and open to correction.
This also requires “the final decision is made by a person” to be stated more precisely. Who is the decision-maker, who merely offers advice, who may override a recommendation, who receives an appeal, what the handling time is, and where exceptional cases go should all be specified before a system goes live, rather than improvised once someone is affected. In regulated sectors, employment relationships, medicine and other professional fields, applicable law and professional processes must also be followed; this article cannot substitute for them.
5. Revocable authorisation, traceable actions and rehearsable recovery are the conditions for autonomy
Even when an action has been judged delegable, connecting permissions does not mean it can be left to run unchecked. Genuine autonomy is not “it can call tools”. It is “it calls tools within limited capabilities, while someone can still reconstruct what happened, pause the system and take over when something unexpected happens”. If a team cannot answer three basic questions — under which identity did it do what, what can it still do now, and who can stop it and how when it goes wrong — the automation has not reached the operating conditions for delegation.
Authorisation design offers concrete material. OAuth 2.0 describes an access token as a credential, approved by a resource owner, with specific scope, lifetime and access attributes; scope constrains access requests. [7] RFC 8707 further explains that resource indicators let an authorisation server restrict a token to a specific resource audience, and that a more specific resource URI can help reduce the opportunity for a token to be misused at other resources. [8] The MCP authorisation specification dated 2025-06-18 likewise requires servers to validate that a token was issued for them, prohibits accepting or forwarding other tokens, and notes that token theft can let an attacker access protected resources through requests that appear legitimate; short-lived tokens can shorten the exposure window. [9]
These specifications show that permissions can be designed to be narrower, shorter-lived and closer to a particular resource. They do not show that a product using OAuth or MCP is safe by default. A product may package every permission into a long-lived token, or fail to validate the audience properly. Even with fine-grained tokens, an agent may take an inappropriate action that its permissions allow when it is led by bad input. Protocol capability is not a substitute for responsibility design, but it gives that design mechanisms that can be implemented.
This article recommends writing the minimum operating conditions for automatically executable actions as a set of checkable engineering conditions. First, use separate, least-privilege identities that expire. Do not make an agent share an administrator account, or connect it to a company-wide primary token merely to avoid one more authorisation. An identity that reads tickets should not also be able to delete files; an identity that can create a draft in one project should not automatically be able to publish in every project. The identity should be revocable separately and reassessed after expiry, rather than continuing silently forever.
Second, tools should be narrow. A set of clearly specified actions is more trustworthy than a universal connector that says “do anything for me”: read a named queue, create a draft, submit an application awaiting approval, or add labels in a bounded directory. An open-ended shell, arbitrary URL requests and high-privilege connectors that can be freely combined across systems expand one task into an action space that is difficult to enumerate. OWASP's mitigations for excessive agency likewise include least privilege, fine-grained functionality, logging and monitoring. [5]
Third, every action should be traceable in terms a person can understand. A log should not be merely a string of machine error codes. At minimum, it should link the triggering input, identity used, tool called, target object, final parameters, execution time and result. Giving each action a unique correlation ID lets someone connect “why was this email sent?”, “why was this record changed?” and “who approved this request?” along the same path. For sensitive writes, previews and delayed queues matter more than immediate execution: they leave a real window for finding an error, cancelling a task and awaiting human judgement.
Fourth, recovery must not exist only in product marketing or as a wish list after an incident. Before routine use begins, verify whether current authorisation can be revoked; whether the agent's identity can be frozen; whether queued actions can be stopped; how far written records can be rolled back; and, after an irreversible outbound action, who takes over notification, correction and remediation. A single exercise can reveal many otherwise invisible problems: a log cannot locate the specific object, a rollback overwrites later human changes, or a pause switch can stop only new tasks and not items already dispatched from a queue. Recovery that cannot be rehearsed should not be treated as reliable recovery.
Fifth, use failures regularly to withdraw or reduce autonomy. The focus of a weekly or monthly review should not be only to make prompts longer. It should also include which inputs led the system to misunderstand intent, which actions people rejected, which alerts arrived too late, which permissions did not need to exist at all, and which exceptions should move a process from automatic execution back to read-only advice. A genuinely mature system treats failure as evidence for adjusting permissions, tools and stopping conditions, rather than explaining each incident away as an occasional fluctuation in the model.
In practice, not every external service supports fine-grained permissions, revocable operations, complete logs or transactional rollback. This is not a gap that a stronger prompt can fill. Where a service can provide only global administrator permissions, outgoing content cannot be recalled, or operations leave no searchable record, the cautious answer will often be to permit read-only assistance only, require human approval, or not connect that system to an agent at all. Logs can help establish accountability, but cannot put disclosed information back. Revoking a token can stop the next access, but cannot cancel a commitment already made to someone outside.
Finally, the boundary should not be understood as a permanent list of “what AI can do” and “what AI cannot do”. New tools, new permissions and new input sources all change the action chain and what consequences people can responsibly accept. Before every integration, set out which identity it will use, which external changes it can cause, at which step approval takes place, who will find an error, how it will be stopped and how recovery will work. Before asking AI to do more, make sure people can see those actions, pause those actions and take responsibility for those actions. That is the starting point for gradually expanding the scope of delegation.
