Approve the action, not the AI agent

An approval prompt is not a permission system

A current r/AI_Agents discussion asks whether permissions should live inside the agent runtime or outside it. The highest-leverage answer is operational: hard rules such as “cannot merge to main,” “cannot access payroll,” or “cannot send money” must survive a compromised model, poisoned tool description, prompt injection, or mistaken plan. The model may propose an action. It cannot be the final authority that decides whether the action is allowed.

This is not a theoretical distinction. Public agent frameworks now expose approval middleware, literal tool parameters, read-only auto-approval rules, and staged writes. VS Code shows the tool and input parameters before approval. OpenAI's Agents SDK passes parsed parameters and a tool-call ID to approval callbacks. AWS warns that wildcard trust grants remove oversight. An official n8n skill says the approval message should display the actual parameters sent to the wrapped tool, not a paraphrase generated by the model.

The convergence is useful but incomplete. A parameter dialog can still approve stale data. A tool can use a shared credential with broader scope than the request. A retry can repeat the effect. A sub-agent can ask a more privileged agent to act. Two individually permitted actions can combine into a prohibited outcome. Operations needs change control around the full action lifecycle, not only a button before execution.

Put hard authorization outside the model

OWASP's Excessive Agency guidance separates model behavior from system authority. Minimize tool functionality, permissions, and autonomy; execute in the user's context; and require human approval for high-impact effects. The target database, API, identity provider, policy engine, gateway, or deterministic workflow should enforce the boundary even when the agent confidently argues for an exception.

Use layers because no single control sees everything:

NIST's AI Agent Standards Initiative treats identity and authorization as enterprise infrastructure. That framing avoids a common mistake: describing an agent as if it were one stable person. A single workflow may involve a requesting employee, service account, orchestrator, model, sub-agent, connector, and downstream application. Every hop must preserve or reduce authority. None should silently broaden it.

Inventory operations, not product names

“Sales agent,” “finance copilot,” and “HR assistant” do not describe permission. Record the smallest operation the system can perform. A connector described as “manage CRM” may include reading all contacts, exporting attachments, changing ownership, deleting records, and triggering customer emails. If the intended task is to summarize one account, only the read path for that account belongs in the permit.

Read-only is not automatically safe. A read can reveal confidential data, aggregate records into a new sensitive dataset, or supply inputs for a harmful write elsewhere. Inventory target, fields, row set, tenant, volume, retention, export, and downstream use.

Normalize every tool call into an action envelope

Tools describe the same business effect differently. One uses update_vendor, another sends an HTTP PATCH, and a third clicks a browser form. Normalize them before policy. The policy engine should reason about “change vendor bank account” with a target and payload, not about whether the route came from MCP, a browser, or an SDK.

apiVersion: operations.example/v1
kind: AgentAction
requester:
  human: user-1842
  agent: ap-processor-v3
  service: erp-tool-gateway
action: finance.vendor_bank.change
target:
  tenant: eu-prod
  vendor_id: V-20481
source_state:
  version: 7712
  current_iban_digest: sha256:old...
parameters:
  new_iban_digest: sha256:new...
  effective_date: 2026-08-24
effect_class: FINANCIAL
idempotency_key: vendor-V-20481-bank-20260823
rollback: finance.vendor_bank.restore
expires_at: 2026-08-23T10:30:00Z
policy: require_dual_approval

The envelope contains literal machine-resolved facts. The agent can attach a reason and source documents, but the approval must not depend only on its summary. Hash or immutably version the envelope so the payload cannot change after approval. At execution, verify that the vendor record is still version 7712 and that the approvers still hold the required roles. Any mismatch invalidates the permit.

Include an idempotency key before the first attempt. If the network fails after the target accepted the change, the workflow must reconcile the key or resulting state before retrying. Approval for one effect is not approval for two copies of that effect.

Design the approval around the reviewer decision

A useful approval screen answers what will change, where, under whose authority, based on which current evidence, with what consequence, and how it can be reversed. It should make disagreement easy and preserve the literal decision object.

Do not ask the same overloaded employee to approve every low-risk read. Risk-tiered policy should auto-allow narrow actions with a trace, require review where judgment adds value, require dual control where segregation matters, and prohibit actions that cannot yet be made inspectable or reversible. Approval fatigue is a control failure, not a reason to remove boundaries.

Delegated authority must become narrower at every hop

The new Bounded Agents paper proposes an Agentic Principal Chain that carries delegated scope and budget through a stateful session. In the authors' evaluation, the framework blocked all 544 InjecAgent data-stealing cases and reduced several attack outcomes, while decreasing utility by 8.6 to 13.9 percentage points in two AgentDojo settings. The result is promising and the tradeoff matters: stricter authorization may block legitimate work when restriction sets are incomplete or context is ambiguous.

Operations should take the architectural claim, not treat a new paper as a certification. Authorization must consider prior actions and delegation, not only the current call. An agent allowed to read a customer list and separately allowed to send an external email may combine those permissions into exfiltration. A procurement agent with a $1,000 transaction limit should not split a $5,000 purchase into five calls or delegate the purchase to another agent with a larger budget.

Test three invariants:

1. Scope monotonicity: every sub-agent receives equal or less data, action, amount, duration, and delegation authority.
2. Composition safety: a sequence of individually allowed actions cannot produce an explicitly prohibited combined outcome.
3. Independent enforcement: a compromised model cannot modify the policy, mint its own approval, change the receipt, or use a more privileged shared identity.

Serialize admission for conflicting high-impact actions or use resource locks. Parallel agents can each pass a stale balance, quota, or version check and violate the combined limit when both execute.

Worked example: an agent changes vendor bank details

An accounts-payable agent reads a supplier email, extracts a new bank account, and proposes an ERP update. The email is untrusted input. Even a perfect extraction does not prove the request is authentic. The workflow separates preparation from authority.

A generic “approve ERP update” button would miss the fraud risk, shared identity, stale source, duplicate retry, and first-payment control. Exact-action change control makes those questions visible before the effect.

Failure modes to include in the pilot

A 30-day pilot should prove one write-capable workflow

1. Days 1-3: select one recurring workflow with a real system-of-record write. Freeze scope, owner, affected people, and prohibited actions.
2. Days 4-6: inventory every tool operation, identity, credential, data class, side effect, delegation hop, volume, and cost.
3. Days 7-9: normalize calls into action envelopes and classify each as deny, auto-allow, human approval, dual approval, or prohibited/special review.
4. Days 10-12: implement enforcement outside the model at gateway, identity, and target-system layers. Remove unused scopes and shared credentials.
5. Days 13-15: build an approval view with literal parameters, before/after state, evidence, consequence, idempotency, expiry, and rollback.
6. Days 16-18: test prompt injection, poisoned tool descriptions, scope escalation, sub-agent delegation, and a confused-deputy request.
7. Days 19-21: test composition attacks, concurrent limits, stale approvals, state changes, and policy-service outage.
8. Days 22-24: test timeout after execution, duplicate suppression, receipt integrity, reconciliation, credential revocation, and task termination.
9. Days 25-27: reverse or compensate for an approved test action. Measure recovery time, residual effects, and missing authority.
10. Days 28-30: close exceptions and make a named RELEASE BOUNDED PILOT, REDESIGN, RESTRICT, HOLD, or STOP decision with automatic expiry.

Measure denied unsafe actions, false denials, approval time, override rate, stale approvals, duplicate suppression, rollback time, orphan permissions, and accepted outcomes. A high prompt count or a low number of approval clicks says little about control quality.

Frequently asked questions

Where should the permission policy live?

Hard boundaries belong outside the model at the tool gateway, identity layer, downstream API, and target system. The agent may use policy to plan, but enforcement must survive a compromised or mistaken agent.

Does human approval make an action safe?

Only when the reviewer sees the literal target, parameters, current state, evidence, consequence, and rollback, and the decision is bound to that exact object with an expiry. A generic yes/no prompt can be a rubber stamp.

Can bounded reads be auto-approved?

Yes, after testing field, row, tenant, volume, sensitivity, aggregation, export, and downstream-use boundaries. Preserve a policy trace and revoke on drift or anomalous use.

Should an approval survive a resource update?

Usually no. If a material source or target version changed, invalidate the permit and rebuild the action envelope. The reviewer approved one action against one known state.

How long should a permission last?

Use the shortest useful scope: one call, one task, one session, or a bounded pilot. Reapprove after tool, model, skill, identity, data, target, workflow, policy, consequence, or jurisdiction changes.