Preventing Stale Approvals in Agentic Workflows With Authorization Leases

Consider a hypothetical renewal workflow. An executive approves a discount exception at 10:02. The agent gathers account history, generates contract language, waits for a pricing service, and sends the amendment at 10:19.

During those 17 minutes, the deal owner changes, the customer withdraws a requirement, finance revokes the exception, and the contract version advances. The agent still holds a perfectly clear record that says approved.

The problem is not that the approval was fake. It is that the approval outlived the conditions that made it valid.

Autonomous workflows need something stronger than an approval field or a successful OAuth token check. I call it an Authorization Lease: a bounded, revocable grant to perform one defined action against one defined state of the world.

Approval is not authorization

Enterprise systems often compress several decisions into one label:

• a manager approved the business outcome;
• the user has access to the application;
• the integration token has the required scope;
• the record is still in an eligible state;
• the evidence is still current;
• policy still permits the action;
• the proposed payload still matches what was reviewed.

Those claims are related, but not interchangeable.

OAuth can establish that a client holds a token with certain privileges. RFC 9700 recommends restricting token privileges to the minimum required and binding refresh tokens to the consented scope and resource servers. RFC 7009 defines token revocation and acknowledges that revocation can have a propagation delay. These are essential access controls. They do not by themselves prove that a specific business action remains authorized at execution time.

An agent may have API access to update a deal and still lack authority to change this deal to this stage using this evidence after this approval changed.

The Authorization Lease

An Authorization Lease converts approval into a structured capability with an expiry and a final revalidation requirement.

{
  "lease_id": "lease_01K2N4",
  "subject": "agent:renewal-assistant",
  "action": "send_contract_amendment",
  "resource": "deal:184921",
  "resource_version": "v317",
  "payload_hash": "sha256:...",
  "approver": "user:finance_22",
  "policy": "discount-exception-4.2",
  "evidence": ["quote:q_991", "approval:ap_402"],
  "issued_at": "2026-09-17T10:02:11Z",
  "expires_at": "2026-09-17T10:12:11Z",
  "revocation_channel": "policy-events",
  "max_uses": 1
}

The lease is not a credential replacement. It sits above identity and API access. The underlying token answers, "Can this client call the endpoint?" The lease answers, "May this agent perform this business action now, against this exact resource and payload?"

Seven fields that make approval executable

1. Subject

Identify the agent, workflow, delegated human, service account, and tenant. "Automation" is not a useful actor identity when several services share credentials.

2. Action

Authorize a business verb, not broad access. send_contract_amendment is more precise than write CRM or sales automation.

3. Resource and version

Bind the grant to the exact deal, ticket, contract, contact, or account state that was reviewed. If the resource version changes, the lease should be reconsidered.

4. Payload

Hash or otherwise bind the approved recipient-visible or record-changing payload. An agent should not obtain approval for one message and send a materially different one.

5. Evidence and policy

Record the facts and policy version that supported approval. This allows the final gate to detect stale evidence or a changed rule.

6. Time and use

Define a short validity window and maximum execution count. A one-time approval should not become a reusable permission.

7. Revocation

Provide an event or lookup that can invalidate the lease before expiry. A human must be able to stop a queued action without disabling the entire integration.

The check must happen at execution time

The most important control is also the easiest to omit.

Validating a lease when a workflow begins protects the plan. It does not protect the eventual side effect. The agent may spend minutes or hours retrieving data, calling tools, retrying failures, waiting for approval, or sitting in a queue.

Immediately before the irreversible or externally visible action, revalidate:

authenticate the agent
        ↓
verify API scope
        ↓
load the authorization lease
        ↓
compare resource version and payload hash
        ↓
check evidence freshness and policy version
        ↓
check expiry, revocation, and use count
        ↓
execute once or stop
        ↓
write the decision trace

This follows a broader security principle: authorization decisions should be evaluated against current context, not assumed to persist because they once succeeded.

An implementation also needs a policy for an unavailable lease service or delayed revocation feed. A cached "approved" flag is not a safe fallback for an externally visible action. Queue a bounded retry, show the approver why execution stopped, and require a fresh evaluation before resuming. For low-risk internal work, a narrower degraded mode may be acceptable, but it should be explicit in policy and visible in the decision trace. The denial path deserves the same engineering attention as the approval path.

Five ways a valid approval becomes invalid

Change	Why the earlier approval no longer governs	Safe response
Resource version changed	The approver reviewed a different record state	Recompute or request approval
Payload changed	The external communication or write is materially different	Bind and review the new payload
Policy changed	The rule that allowed the action is no longer current	Evaluate the new policy version
Evidence expired	Pricing, consent, ownership, or risk facts are stale	Refresh evidence before proceeding
Revocation arrived	A person or system explicitly withdrew authority	Stop and record the revocation

Expiry alone is not enough. A long lease can remain valid after a critical change. A short lease can expire harmlessly while nothing changed. Use time as one condition, not the entire model.

A worked CRM scenario

Consider an agent that prepares and sends a renewal offer.

At 09:00, the CRM says the opportunity owner is Maya. The current quote is version 12. Finance approves a 12 percent discount. The customer contact is eligible for the operational message. The agent receives a lease valid for 15 minutes.

At 09:07, a sales manager changes the quote to version 13 and removes one service line. At 09:09, finance revokes the discount exception. At 09:11, the agent completes its draft based on cached version 12 and attempts to send.

A permission-only system sees a valid integration token and a writable CRM record. An approval-field system sees approved = true. The Authorization Lease gate sees:

• resource version mismatch;
• payload hash mismatch;
• revocation event after lease issuance;
• evidence referring to an obsolete quote.

The agent stops before sending and creates a private review task with the decision trace.

{
  "decision": "deny_and_reauthorize",
  "lease_id": "lease_01K2N4",
  "failures": [
    "resource_version_changed",
    "payload_changed",
    "authorization_revoked"
  ],
  "allowed_next_actions": [
    "regenerate_from_quote_v13",
    "request_new_finance_approval"
  ]
}

The control does not require the model to decide whether the old approval is "close enough." The deterministic gate rejects the stale grant.

Separate four layers of authority

An enterprise agent should pass four independent layers:

1. Identity: Is the calling workload the expected agent or service?
2. Technical permission: Does the credential have the minimum required endpoint scope?
3. Business authorization: Does a current Authorization Lease permit the specific action and resource state?
4. Action confirmation: Does the final payload match what the lease covers, and have all revocation checks passed?

Collapsing these layers creates ambiguous audit records. "Access allowed" can mean the token worked, the user role allowed it, the manager approved it, or the policy engine had no rule. Keep each decision visible.

NIST's AI RMF Core calls for defined human-AI roles and responsibilities, accountability for AI risk decisions, and documented oversight. The Authorization Lease is one architectural way to operationalize those ideas for tool-using agents. It is not a claim that NIST prescribes this exact data structure.

Fail closed without freezing the business

Fail closed does not have to mean every expired lease goes to a person.

Classify actions by consequence and define an automatic recovery path:

Consequence tier	Example	Expired or invalid lease response
Low	Add an internal research note	Re-evaluate automatically
Medium	Change an internal lifecycle field	Re-evaluate and log
High	Send a customer message or change a quote	Require renewed authorization
Critical	Execute payment, delete data, change access	Stop and require explicit review

The agent can continue reversible preparation while waiting. It may refresh facts, draft a revised payload, or assemble evidence. It should not cross the action boundary.

The same design principle applies when deciding who can say no in automation: authority must be explicit, scoped, and preserved as evidence. A fast path is valuable only if the stop path is equally real.

Implementation without rebuilding the CRM

Start with a thin authorization service beside existing systems.

1. Define action vocabulary. List the externally visible and high-consequence verbs agents may attempt.
2. Choose binding fields. Decide which resource version, payload representation, evidence, and policy identifier matter for each action.
3. Issue leases. Generate signed, tamper-evident grants after deterministic policy checks or human approval.
4. Publish revocations. Provide a low-latency event channel and a direct lookup for final checks.
5. Enforce at adapters. Place the gate next to the tool invocation so the model cannot bypass it through a different prompt.
6. Record decision traces. Store lease, evidence versions, checks, result, and side-effect receipt.
7. Test race conditions. Change records, revoke approvals, and retry actions between planning and execution.

The tool adapter is the best enforcement point because it controls the side effect. A prompt telling an agent to "check approval" is guidance, not a guarantee.

Metrics that reveal authorization drift

Track:

• leases expired before execution;
• actions blocked by version mismatch;
• payload mismatches;
• revocation propagation time;
• reused one-time leases;
• actions executed without a decision trace;
• reauthorization completion time;
• post-action findings that current evidence should have blocked.

Do not optimize only for approval speed. A faster approval that is detached from execution creates a larger window for state to change.

Approval should decay on purpose

AI agents make the time between decision and action more complicated. They retrieve, plan, call tools, wait, retry, and resume. That makes a timeless approval flag increasingly fragile.

Treat authorization as a lease over a specific action, resource version, payload, evidence set, policy, and interval. Revalidate it beside the side effect. Make revocation first-class. Preserve the trace.

Then an agent can move quickly without pretending that yesterday's permission governs today's reality.

Sources

1. RFC Editor, Best Current Practice for OAuth 2.0 Security
2. RFC Editor, OAuth 2.0 Token Revocation
3. RFC Editor, The OAuth 2.0 Authorization Framework
4. NIST, AI Risk Management Framework
5. NIST AI Resource Center, AI RMF Core
6. HackerNoon, Before You Automate a Task, Decide Who Can Say No