Policy-Mediated Autonomy with Resumable Action Attempts

Admission control is not execution authority

A tool invocation has at least three distinct questions: who submitted it, whether tenant policy admits an attempt, and whether the requested resource will authorize the effect at execution time. Collapsing these questions into one role check produces either an agent that cannot initiate governed work or a broad capability that ignores tenant risk posture. A policy decision should therefore mediate admission to a particular action attempt while authentication, tenant scoping, credential validation, and effect-level authorization remain independent boundaries.

The relevant unit is not an abstract capability detached from context. It is an invocation envelope associated with a tenant, an authenticated requester, a credential identity, a route, and a request body. A tenant may allow this invocation, deny it, or require an eligible human decision before it proceeds. If the policy requires review, the system must either retain enough request and identity information to resume that particular attempt or refuse to create a hold. A response that says “pending” without a recoverable subject would be an invalid protocol state.

This model also separates decision ownership from effect ownership. The human reviewer decides whether the held request may proceed. The operation handler remains responsible for executing the requested effect under the requester’s current authority. Approval does not mint a credential, transfer identity, or turn a reviewer into an executor.

Policy evaluation and precedence

Authentication and tenant-scope checks precede tenant-policy evaluation. The owning service derives the policy keys applicable to the operation and evaluates them in the requester’s tenant context. A shared HTTP route can represent several tool operations, so each applicable tool name is evaluated. The restrictive join is deny ≻ require-review ≻ allow: one denial dominates a review request, and review dominates an allow. If no explicit tenant policy applies, the platform default is allow. This default is a policy-composition rule; it does not bypass the preceding authentication and tenant boundaries or the handler’s resource-level checks.

For a given eligible invocation, the decision branches into three paths. Deny terminates admission. Allow enters the owning effect path, where normal live authorization still applies. Require-review attempts to persist a replayable request envelope and a binding to the requester’s credential identity. If persistence or replay is unsupported, the request is refused rather than represented as a resumable hold. A policy lookup failure also refuses execution because the service lacks a decision; it is not reinterpreted as an allow.

A review hold is a deferred invocation, not a queued promise that execution will eventually succeed. The persisted envelope preserves the request needed for replay, while its identity binding prevents a different tenant, principal, credential, method, path, or query from selecting the saved attempt. The operation’s effect is not performed at hold time. The hold records an admission state that requires an eligible human resolution before the configured replay path can consider dispatch.

authenticated request → tenant policy → deny | allow | require-review
require-review → persist request envelope → pending human decision
approved pending request → replay-time identity check → live authorization → effect handler

Requester, approver, and executor separation

Let R denote the requester, H the human approver, and E the effect-owning handler. R submits the invocation and remains its principal across deferral. H resolves the review subject under human approval authority. E receives the approved saved request and attempts the effect under R’s identity. These roles can be composed in one system, but they are not interchangeable: H does not become the caller, and R cannot manufacture H’s approval. A permit holder can be a fourth authority where the operation contract requires one.

The approval service records the resolution through its configured audit recorder, including the approver reference and decision context. That audit establishes that a review decision occurred. It is not proof that the effect ran. The effect result is recorded by the owning operation path after replay. This distinction matters for failure analysis: a request can be approved and later fail because the requester’s credentials expired, a grant was revoked, a resource changed, or a dependency became unavailable.

Replay applies to held authoring actions; credential-administration collect attempts are not replayed. Replay validates that the saved attempt is approved and has no recorded result, then checks that the replay request matches the saved tenant, principal, credential, method, path, and query. The saved JSON body is dispatched through the composed handler. The handler re-resolves the requester’s credential and performs current role, scope, grant, and resource checks. The saved approval is scoped to the saved invocation; it is not a durable authorization token for arbitrary future calls. A changed request must be evaluated as a new attempt.

Trace: publish a customer report

An agent submits a JSON authoring request to publish a report. The service authenticates the agent, resolves the tenant, and derives the policy key for the requested operation. Tenant policy returns require-review. The route supports replay, so the service stores the request envelope and requester credential identity, then returns a typed held response that identifies the saved attempt. If it cannot persist a recoverable envelope, it refuses the request and performs no report publication.

An eligible human inspects the held subject and approves it. The approval service records the decision and approver reference; it does not call the report publisher as the human. The replay service loads the saved attempt, confirms the approved and result-free state, and checks request identity. It submits the stored request to the owning operation handler with the original agent as requester. The handler resolves the credential again and checks current tenant, role, scope, grant, and resource conditions before dispatch. If those checks pass, it invokes the publisher and records the typed result on the attempt. If a credential has expired or authority has changed, the handler refuses the effect and records the resulting failure. Approval is preserved as a decision; execution remains a separate event.

State transitions, TOCTOU, and limits

A useful abstract state machine is: submitted → denied; submitted → admitted → executing → completed or failed; or submitted → held → approved or rejected. Only an approved, unresolved held attempt is eligible for the configured replay transition. Replay then branches to identity-mismatch refusal, live-authorization refusal, effect dispatch, or a typed dependency failure. These labels describe the protocol at a conceptual level; they do not imply that every route exposes the same persisted state names or that every action is replayable.

The central time-of-check/time-of-use issue is that approval and execution occur at different times. Authorization may change after the human review, so replay-time reauthorization is necessary. It closes the stale-credential gap at the point the handler checks the requester. It does not, by itself, prove that authorization and an external side effect are atomic. If resource state or grants can change between the handler’s check and the downstream commit, the effect-owning system must provide suitable transactional, conditional, or idempotent semantics. This architecture makes no general exactly-once claim: a timeout after an external effect but before result persistence can leave the caller uncertain, and retry behavior depends on the operation’s own idempotency contract.

Evaluation should exercise the three policy outcomes, precedence across multiple applicable keys, missing-policy default behavior, and policy-service failure. For review paths, verify that unsupported or non-persistable requests are refused, that a held attempt does not execute before approval, and that only the matching approved request can be replayed. Revoke or alter the requester’s credential and grants between approval and replay; the live handler check must prevent an effect when current authority is absent. Exercise changed request identity, duplicate replay, dependency failure, and a timeout around external commit to characterize the operation-specific recovery semantics.

The broader literature places governance at several points in agent systems, including planning, tool invocation, and human approval. Our narrower contribution is an admission and resumption protocol around an effect-owning service. It allows a tenant to pause an agent-authored attempt without transferring authorship or execution identity to the reviewer. It does not establish that a policy is wise, that a reviewer is correct, or that tenant isolation and resource authorization are solved by policy mediation.

Related sources: [2]