AI Agent Authorization: Approval Is Not a Blank Check

TL;DR

AI agent authorization must connect permission to the exact action, executing identity, target, current policy, and validity window. A verified proposal is not permission to deploy, and a human approval should not survive material changes to the plan without reassessment. This article develops an action-bound approval contract for the two-cluster workflow introduced in Part 1. It separates planning from enforcement, addresses policy changes and shared capacity, and explains why an unknown execution outcome requires reconciliation rather than an uncontrolled retry. Approval governs what may happen. Outcome verification establishes what actually happened.

Introduction

The infrastructure assistant has produced a defensible recommendation. The evidence is attached, the deployment plan is clear, and an authorized reviewer approves it. Then the workflow pauses. Before execution resumes, the target resource pool changes, a new restriction takes effect, or the agent adds a network modification to complete the task.

The conversation still contains the word “approved.” The operation about to execute may no longer be the operation that received approval.

Part 1, AI Output Verification: Check Claims Before Acting, ended with a capacity blocker and unresolved validation. For this hypothetical continuation, assume the team has revised the capacity plan, completed the missing checks, and recorded a new evidence assessment. The original failed design does not become acceptable merely because someone approves it.

The next question is different: Is this exact action still authorized for this identity against this target under the conditions that apply now?

This article proposes an action-bound approval pattern for consequential infrastructure changes. It assumes authenticated identities, a controlled execution service, and access to authoritative policy and target-state information. Where those controls are unavailable, keep the assistant advisory rather than relying on a prompt to supply the missing boundary.

AI Agent Authorization Belongs Outside the Model

NIST’s Zero Trust Architecture, Section 3, separates policy decision responsibilities from policy enforcement. OWASP’s LLM03:2026 Excessive Agency similarly calls for authorization enforced in application logic, an independent pre-execution decision point, or downstream systems, rather than by the language model itself.

Apply that separation to the assistant. Let the model propose an operation and explain its evidence. Let the authorization service determine whether the operation is permitted. Let a restricted executor submit the approved request, with the target platform enforcing its available resource-level permissions and constraints.

The proposed architecture below shows logical responsibilities, not a requirement for separate products. Notice that the model has no direct production write path.

Protect the boundary from bypass. In this design, the planner cannot issue approvals, modify policy, read deployment credentials, or invoke a second administrative tool that avoids the broker. An approval check on one path is insufficient when another path exposes the same capability without it.

The distinction is not whether the model can explain the rules. It is whether the surrounding application continues enforcing them when the model proposes something outside those rules.

Bind Approval to the Action, Not the Conversation

“Deploy the two clusters” describes an objective. It does not fully specify the change.

For this workflow, make approval refer to an immutable action manifest. Include the existing target environment and tenant, intended cluster names, component versions, resource allocations, network and storage selections, and permitted downstream steps. Reference the exact evidence assessment used during review.

The following boundaries belong in the proposed contract.

A human review screen should expose the material change, affected resources, evidence limitations, and recovery conditions. Build that view from the same structured manifest the executor will consume, not solely from the agent’s summary. Otherwise, the reviewer can approve one description while the application executes another representation.

A Digest Detects Changes Only to What It Covers

An action digest is a cryptographic fingerprint of the reviewed representation. RFC 8785, JSON Canonicalization Scheme (JCS), describes a repeatable JSON representation suitable for hashing and signing. It does not define infrastructure semantics or grant permission.

For this pattern, validate the action schema, make consequential defaults explicit, and resolve mutable artifact references before calculating the digest. “Latest image” should not resolve to one artifact during review and another during execution. Bind the approved tool contract or executor release where changes to its behavior could change the action.

The executor must calculate and compare the digest using the same rules. A matching digest does not prove that omitted conditions remained unchanged, and an unauthenticated digest is not an approval. Protect the authoritative record separately.

Preserve Delegated Authority Across the Workflow

Keep requester, approver, and executor identities distinct. The requester must be entitled to request the operation. The approver must be entitled to authorize its scope. The executor needs only the technical privileges required to perform the approved steps.

This does not require every requester to hold direct production-administrator permissions. A controlled provisioning service can act under its own workload identity, provided policy explicitly permits that delegation and preserves the originating request’s scope.

OWASP’s 2026 excessive-agency guidance specifically addresses preserving original user context and authorization scope through delegated or multi-agent calls. In this design, that means a planner cannot bypass a denial by asking another agent whose service account has broader permissions.

Derive downstream authority from the approved operation, not from the union of every participating service account’s permissions. When a later step uses an identifier returned by an earlier step, bind it to that recorded result and verify its tenant and environment. Do not accept an arbitrary replacement resource identifier from generated text.

For a multi-step deployment, approve the defined workflow and enforce each material step. Human review need not be repeated for every status query or predetermined step, but a new operation outside the approved manifest requires a new decision.

A Proposed Action-Bound Approval Contract

The YAML below illustrates a record held by a trusted approval service. It is not a vendor schema, a signed access token, or executable policy. The identifiers and decisions are fictional. The referenced action manifest contains the full plan, including the two intended clusters and their downstream operations.

schema: action-approval/v1
approval_id: approval-042-v2
request_id: cluster-expansion-042
decision: permit

binding:
  action_manifest: cluster-plan-042-v4
  action_digest: "sha256:<computed from canonical action>"
  evidence_record: evidence-042-v3
  requester: workload-owner-07
  approved_by: change-reviewer-12
  executor: cluster-deployer-prod
  audience: infrastructure-change-broker

constraints:
  environment_id: production-site-a
  tenant_id: internal-inference
  policy_epoch: "17"
  valid_from: "<UTC start timestamp>"
  expires_at: "<UTC expiration timestamp>"
  distinct_logical_runs: 1
  maximum_concurrent_mutations: 1
  admission_reservation: reservation-042

revalidate_before_material_step:
  - approval_active_and_identities_valid
  - action_and_tool_contract_match
  - required_evidence_remains_applicable
  - current_policy_permits_action
  - step_specific_target_conditions_match
  - admission_reservation_is_valid

on_mismatch: stop_and_reassess
on_unknown_outcome: reconcile_before_new_submission

Replace the placeholder identities, timestamps, manifests, and constraints with the actual environment’s values. Populate security-relevant identity fields from authenticated context and controlled approval records, not from claims made by the model.

The broker should retrieve the record from the protected store, verify its status and bindings, and reject unknown fields or unresolved references. Presenting this YAML through a tool call must not create permission. A signed-grant implementation is another option, but it still needs issuer validation, audience and identity binding, expiry, and replay controls.

Successful processing permits the reviewed plan under current conditions and rejects a changed target or unauthorized executor. A missing required field should produce a hold with a reason, not a best-effort attempt.

The reservation reference must resolve to a real allocation mechanism. Two requests must not both be admitted against the same unreserved capacity. Also distinguish per-workflow concurrency from fleet-wide limits: setting one concurrent mutation in each of many workflows does not enforce a global limit of one.

Revalidate When Policy or Target State Changes

Here, policy epoch means the revision under which authorization was evaluated. It is a bookkeeping field in the proposed pattern, not a credential format prescribed by NIST.

Suppose the deployment receives approval under policy revision 17. Before it resumes, revision 18 freezes new production cluster creation. The approval has not expired, and the action digest still matches. The next creation step must nevertheless stop because current policy no longer permits it.

A policy revision does not automatically require another human meeting. Reevaluate the applicable rules, preserve the decision and revision used, and seek fresh approval when the changed scope or policy requires it. An unrelated policy edit may leave the action permitted. A production freeze does not.

State Checks Need a Defined Scope

Recheck material target conditions immediately before the affected write. Use step-specific conditions so that legitimate changes made by earlier approved steps do not invalidate every later step against the original snapshot.

Where the platform supports conditional mutation, attach the relevant resource-version condition to the write. Otherwise, define the required reservation, serialization, or locking mechanism. A check performed earlier in the broker cannot guarantee that another actor will not change the resource before submission.

Document the remaining race window and the point beyond which a request cannot be stopped. Revoking approval should prevent further unauthorized dispatch, but it cannot be assumed to reverse a request already accepted by the target platform.

For this pattern, an unavailable policy service holds new material writes. Preserve separately authorized inspection and containment paths so operators can still reconcile work already in flight.

An Unknown Outcome Is Not a Failed Action

The executor submits the first cluster-creation request. The connection times out before a response arrives. The cluster might exist, the task might still be running, or the request might never have reached the platform.

AWS’s Making retries safe with idempotent APIs explains how caller-provided request identifiers distinguish repeated attempts at one operation from separate operations. It also addresses parameter changes and identifier-retention limits. Those guarantees depend on the target API’s actual contract, not merely on the caller generating a key.

Use a durable operation record for each material step. This simplified lifecycle shows why the uncertain branch is distinct from confirmed failure.

For asynchronous operations, treat a returned task identifier as an in-progress record. Mark success only after checking completion status and the relevant target postconditions.

In the proposed implementation, atomically associate approval consumption with the local run record before dispatch. A worker restart resumes that run; it does not restore the approval to an unused state and start again. This local transaction does not make the remote change atomic with the ledger.

Reconcile through operation status, target-state inspection, or a supported idempotent retry. Retain the same logical operation identity and unchanged parameters. Treat a negative inventory lookup cautiously when its consistency guarantees do not establish that the original operation is absent.

A further write attempt still needs current authorization. An idempotency identifier is not permission to bypass an expired or revoked grant. When the result remains unresolved, hold dependent steps and escalate rather than allowing the agent to announce success or begin a replacement deployment.

Recovery Requires Its Own Authority

Creating a cluster may involve network updates, DNS records, inventory changes, and notifications. Declare material side effects in the plan rather than treating them as invisible consequences of one approved tool call.

Microsoft’s Compensating Transaction pattern explains why recovery in a multi-step workflow can require application-specific actions and need not restore the exact original state. Compensation can itself fail and needs recorded progress.

For this deployment, removing a newly created, unused resource might be appropriate under a narrowly defined recovery rule. Deleting it after another workload has started using it is a different action with different consequences. A notification already delivered cannot simply be made unread by rolling back infrastructure.

Give recovery its own explicit authority and preconditions. Preauthorize well-defined containment or compensation where appropriate, and require review for destructive or ambiguous cases. “Fix the failed deployment” should not become a general administrative grant.

When one cluster exists and the other does not, report partial completion, preserve the identifiers and observed state, and let the authorized recovery process decide whether to continue, compensate, or leave the environment contained.

Prove the Boundary Before Expanding Authority

Begin with one action class, one controlled executor, and a small target scope. Use the existing identity, change, and allocation systems where they can enforce the required contract. Introducing a second, weaker approval process inside the chatbot would undermine that work.

For this workflow, require tests that change a target after approval, replay the record through another executor, revise policy while the task waits, and lose a response after the target accepts a request. Inspect actual downstream activity, not just the assistant’s refusal message. These are proposed acceptance tests, not reported test results.

Assign ownership alongside the controls. The policy owner defines approval and revocation semantics. The platform owner maintains the executor’s permissions and resource conditions. Operations owns reconciliation and recovery. The application owner ensures that changes to tools, prompts, and workflows cannot introduce a bypass.

Record denials, changed-action mismatches, unresolved-operation age, and post-action verification failures separately. Keep credentials and unnecessary sensitive payloads out of those records. Preserve enough structured evidence to reconstruct the decision without relying on the model’s narrative.

Use per-action human approval where the consequences justify it. For repeatable, low-impact operations, a preapproved action class with enforced constraints may be more practical. In either case, the approval path should be no broader than the organization can inspect, operate, and recover.

Conclusion

AI agent authorization is not the moment someone types “approved.” It is an enforceable decision about a specific operation, identity, target, and set of current conditions.

The evidence contract from Part 1 establishes what supports the proposal. The action-bound approval contract limits what may execute. The operation record and post-action checks establish what happened. Keeping those responsibilities separate makes changed plans, stale authority, and partial outcomes visible.

Start with one consequential write path. Bind its approval to the reviewed manifest, remove alternative execution paths, and verify that a changed target or revised policy stops the next unauthorized action. Then exercise the uncertain-outcome path before trusting automatic recovery.

A verified proposal is not permission to act. An approval is not permission to improvise.

The final installment, AI Agent Evaluation: A Passing Test Is Not Production Proof, examines how to test these boundaries, introduce bounded production exposure, and decide when the evidence no longer supports expanding the agent’s authority.

External References

• NIST: Zero Trust Architecture
• OWASP GenAI Security Project: LLM03:2026 Excessive Agency
• RFC Editor: JSON Canonicalization Scheme (JCS)
• Amazon Builders’ Library: Making retries safe with idempotent APIs
• Microsoft: Compensating Transaction pattern

The post AI Agent Authorization: Approval Is Not a Blank Check appeared first on Digital Thought Disruption.