In this article
  1. 1. COMPETENCE DOES NOT CREATE AUTHORITY
  2. 2. APPROVAL FOR EVERY STEP IS NOT THE IDEAL
  3. 3. ASSESS THE ACTION, NOT JUST THE AGENT
  4. 4. MAKE PERMISSIONS ENFORCEABLE
  5. 5. REVERSIBILITY MUST INCLUDE THE DOWNSTREAM EFFECTS
  6. 6. EXTERNAL CONTENT CANNOT GRANT ITSELF AUTHORITY
  7. 7. A WORKED EXAMPLE: DELEGATING CUSTOMER REFUNDS
  8. 8. APPROVAL MUST MATCH WHAT WILL ACTUALLY HAPPEN
  9. 9. RELIABILITY MUST BE SHOWN FOR THE DELEGATED TASK
  10. 10. SMALL ERROR RATES CAN BECOME LARGE EXPOSURES
  11. 11. URGENCY CAN JUSTIFY PREAUTHORIZATION, NOT INVENTED PERMISSION
  12. 12. MAKE DELEGATION ACCOUNTABLE AND REVOCABLE
  13. 13. THE STANDARD: BOUNDED AUTHORITY WITH VERIFIED CONDITIONS
  14. AI DISCLAIMER

An AI agent finds a scheduling conflict or suspicious account change. It could act immediately. Should it? Intelligence and a confident explanation cannot alone determine the answer.

Does this action fit authority already granted under still-valid conditions? Acting without fresh approval need not mean acting without permission. Define scope, evidence, consequences and escalation before delegating.

This article proposes authorizing defined actions when benefits justify remaining risk, enforcing boundaries independently where feasible and seeking renewed judgment at those boundaries. This is a proposed framework, not a universal policy.

1. COMPETENCE DOES NOT CREATE AUTHORITY

Identifying a cheaper supplier does not authorize cancelling contracts, disclosing bids or committing to a replacement. Knowing what could help and being entitled to do it are separate questions.

Organizations distinguish expertise from delegated power. Employees could investigate without unrestricted purchasing authority. Apply that distinction to AI, adapting controls to automated speed and scale.

Specify the objective, operations, resources, recipients, limits and duration. “Improve customer service” does not establish authority for refunds or account changes. “Prepare draft replies using approved records” defines a narrower, assessable mandate.

Permission must come from someone entitled to grant it. A request embedded in a document, a third-party message or an agent’s own reasoning cannot silently expand that mandate.

2. APPROVAL FOR EVERY STEP IS NOT THE IDEAL

Approving each search, comparison and draft can erase delegation’s benefits and divert attention from high-stakes decisions. This is a practical case for autonomy.

Anthropic’s containment work describes limitations of repeated approval and emphasizes action boundaries. This developer experience does not prove any design risk-free. Place oversight where it can meaningfully influence consequences.

Preauthorize routine actions and reserve approval for exceptions. An agent could organize private copies without asking about every filename, yet seek permission before deleting originals or sharing externally.

Reviewers need evidence, time and authority. Repeatedly accepting vague prompts is not informed control. Make high-stakes review easier and reduce unnecessary interruption.

3. ASSESS THE ACTION, NOT JUST THE AGENT

Reading an approved document, editing a private draft and issuing a public statement have different consequences. They should not inherit identical permissions because they use the same model.

Consider six dimensions together: authority, possible harm, reversibility, uncertainty, scope and urgency. A cheap action can expose sensitive information. A reversible database edit can trigger an irreversible external commitment. A familiar task can become unfamiliar when the recipient, data or operating conditions change.

Do not collapse these dimensions into an arbitrary score. High predicted success cannot justify exceeding authority. Other conditions involve trade-offs, including acceptable review delays for recoverable changes.

Delegate a class of action in a defined environment when evidence and controls justify it. This does not confer permanent trust.

4. MAKE PERMISSIONS ENFORCEABLE

Where feasible, the execution layer should reject unauthorized requests regardless of the model’s explanation. Written instructions should not be the only barrier to prohibited action.

Saltzer and Schroeder’s classic work on computer security established principles including least privilege and complete mediation: grant only necessary access and check authority when resources are accessed. Applied to agents, the implication is to limit credentials, tools and accessible destinations to the job actually delegated.

Report preparation may require selected records but no publishing or account-editing access. Refunds can use a restricted operation checking eligibility and limits instead of unrestricted payment administration.

Configuration errors, broad tools and compromised dependencies can undermine enforcement. Nevertheless, restricting operations limits consequences more directly than relying on the model’s promise of compliance.

5. REVERSIBILITY MUST INCLUDE THE DOWNSTREAM EFFECTS

Calling an action reversible requires more than an undo button. A sent message can be deleted from one interface without removing copies already read or forwarded. A restored record may not cancel a shipment that another system started because of the earlier change.

Identify what changes, who sees it and how other processes react. Recovery may require compensation rather than reversal, leaving costs, inconvenience or disclosure behind.

An agent may revise a private draft within its mandate. Publishing that draft exposes it to an audience with different consequences. Identical text does not mean identical action.

Limited, observable and recoverable changes support delegation without independently authorizing it. Small reversible actions can still violate confidentiality or restrictions.

6. EXTERNAL CONTENT CANNOT GRANT ITSELF AUTHORITY

Agents often read webpages, documents and messages while completing a task. Those materials can contain useful evidence and malicious instructions in the same place. An attacker may try to make a request appear necessary for the legitimate objective.

A document may guide a task when an authorized user has delegated that role to it; it cannot independently expand permissions.

AgentDojo, introduced in 2024, evaluates prompt-injection attacks and defenses in tool-using agents. It highlights testing hostile content alongside ordinary tasks, not a universal attack rate for deployed systems.

Suppose an illustrative supplier attachment tells an agent to upload internal quotations to a new website for “mandatory verification.” The attachment cannot grant disclosure rights. The system should distinguish information being examined from instructions issued by an authorized user.

Changed destinations, recipients or access requests matter more than suspicious wording. A polite request can violate confidentiality. Destination restrictions and access controls limit exposure when interpretation fails.

7. A WORKED EXAMPLE: DELEGATING CUSTOMER REFUNDS

Consider a hypothetical retailer delegating routine refunds. These rules illustrate choices, not recommended thresholds. Management authorizes refunds up to €50 for verified orders meeting a defined policy, returned through the original payment route.

The agent may inspect the records and request missing information. Execution also requires checks for order identity, policy eligibility, previous refunds and the remaining aggregate budget. A successful conversation does not establish that these conditions hold.

A €35 eligible refund can proceed without fresh approval if every required check passes. A €35 request to a newly supplied bank account cannot use that same permission, because the destination is outside the mandate. A €75 request requires escalation even if the customer’s case appears persuasive.

Limit cumulative exposure: one thousand €49 refunds total €49,000. A per-transaction cap cannot prevent a costly wave of permitted mistakes. Rate limits, total budgets and monitoring of unusual patterns therefore matter alongside the amount of each refund.

After execution, the system verifies the resulting state and records the transaction reference. If a timeout leaves success uncertain, it checks whether the refund occurred before retrying. Respond to uncertainty with reconciliation, not blindly repeating a consequential action.

This design delegates a bounded operation. It does not authorize the agent to rewrite refund policy, increase its budget or treat a previous exception as standing permission.

8. APPROVAL MUST MATCH WHAT WILL ACTUALLY HAPPEN

“Proceed?” is insufficient. Show the action, affected resource, destination, amount where relevant and uncertainty. Distinguish evidence from assumptions.

Bind approval to the proposal. Recheck coverage if the recipient, amount or state changes. Approving €40 to the original payment method does not authorize a different transfer.

This also addresses delay between checking and acting. Another process may have refunded the order after the agent prepared its proposal. Relevant conditions should be checked at execution, with suitable coordination to prevent duplicate or conflicting operations.

Some decisions require specialist judgment. Review should expose consequential differences, not turn a click into a ceremonial transfer of responsibility.

9. RELIABILITY MUST BE SHOWN FOR THE DELEGATED TASK

General benchmarks do not establish readiness for local tools and permissions. Test the workflow on representative cases, exceptions, hostile inputs, missing records, tool failures and ambiguous outcomes.

The original τ-bench evaluated agents interacting with simulated users, domain tools and policies, including whether resulting database states matched intended outcomes. Its repeated-trial approach highlights the difference between an attractive demonstration and consistent task completion. Results remain specific to the evaluated models and environment.

Track unauthorized attempts, wrong recipients, policy violations, failed recovery and unnecessary escalation. Refusing everything delivers no value; completing everything may conceal ignored constraints.

Expand from bounded exposure as evidence permits. Observation or drafts reveal defects but cannot fully test unexecuted actions. Live trials need limits and monitoring matched to possible effects.

10. SMALL ERROR RATES CAN BECOME LARGE EXPOSURES

Suppose a system has a hypothetical harmful-action probability of 0.1% per operation under stable conditions. Across 10,000 operations, the expected number of harmful actions is ten. This illustrative expectation is not a measured rate or prediction for a real agent.

Failures need not be independent. One incorrect policy interpretation or faulty data feed can affect many cases together. That is why an average historical error rate cannot by itself establish the safety of high-volume execution.

Frequency and consequence both matter. A wrong label and a confidential disclosure need different treatment. Detect growing patterns and limit execution before mistakes spread.

Budgets, rate limits and bounded access reduce the amount at stake while uncertainty is investigated. Limits should apply across cooperating agents too: distributing work must not accidentally multiply each agent’s authority into unrestricted collective access or expenditure.

11. URGENCY CAN JUSTIFY PREAUTHORIZATION, NOT INVENTED PERMISSION

Sometimes waiting for approval is itself harmful. An illustrative service may need to switch to a earlier tested standby system when a defined fault occurs. If the response has been authorized in advance and remains within tested conditions, demanding fresh permission can defeat its purpose.

Define emergency triggers, responses, limits, notification and recovery in advance. An agent must not declare its own exception to authority. A fallback should avoid creating a larger problem through unrestricted intervention.

A familiar condition may suit a simpler controller or fixed workflow. Use agentic reasoning when adaptation is needed, not merely because a task is important or fast.

The relevant comparison includes the risk of action, the risk of delay and available alternatives. Where an agent lacks authority for a necessary response, the solution is better advance delegation or escalation design, not silent expansion of its powers.

12. MAKE DELEGATION ACCOUNTABLE AND REVOCABLE

NIST’s AI Risk Management Framework and Playbook emphasize roles, oversight and lifecycle responsibility. They do not certify autonomy policies. Someone must have authority to change limits, investigate failures and stop execution.

Connect requests, policy, actions and results in records sufficient to reconstruct events, respecting privacy and retention limits. Logs that omit actual changes or receive no review cannot provide effective accountability.

Revocation must be operational. Stopping new requests may leave queued actions, active sessions or delegated credentials in place. The system should define what cessation means and how pending work is handled without causing avoidable inconsistency. Recovery needs testing alongside ordinary operation.

Review permissions when models, tools, data or objectives change. Past success does not grant permanent authority for a materially different task or system.

13. THE STANDARD: BOUNDED AUTHORITY WITH VERIFIED CONDITIONS

An agent should act without asking again when the action is already authorized, current conditions satisfy the mandate, consequences are within accepted bounds and the result can be checked. Monitoring and recovery should match the speed and scale of execution.

It should seek renewed judgment when authority is unclear, an assumption fails, the recipient or scope changes, or consequences exceed the accepted boundary. Some actions may remain prohibited regardless of confidence or convenience. Approval requests help only when recipients can resolve uncertainty or grant missing authority.

Useful autonomy completes a defined job without unnecessary interruption and stops at changed boundaries. That combination makes delegation understandable and accountable.

AI DISCLAIMER

This article is AI-generated and intended mainly for educational and entertainment purposes. It does not constitute technical, financial, consulting, legal, commercial, investment or other professional advice. Conduct your own research and seek suitably qualified advice where required. Examples identified as illustrative or hypothetical are not deployment instructions or guarantees of safety. © 2026 Datasuperiority. All rights reserved.