When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary

Introduction Many security protocols answer a question at a particular point in time. A verifier appraises evidence, an authorization server issues a token, a policy engine returns "allow", an administrator approves a deployment, or an orchestration system validates a concrete operation. The resulting decision can be entirely correct when it is made. The protected consequence, however, can occur later. Between evaluation and effectuation, a policy can be revised, an account can be suspended, a mapping can change, a resource can advance to a new generation, a reference-value set can be replaced, a purpose grant can be narrowed, or an emergency revocation can become active.

The state-continuity gap evaluate under state S17 effect under state S18 Candidate Act | v Policy P17 / Map M17 | v ALLOW + Permit | | policy, mapping, revocation, | ownership, or reference state changes v -------------------- time --------------------> | v External Effect The permit can still possess a valid signature. Its nonce can still be fresh enough for its protocol. Its presenter can still prove possession of the expected key. Those facts do not necessarily establish that the decision basis used to authorize the act remains current. This document calls the required property state and policy continuity: security-relevant state used to authorize an act must remain bound to that act through the point at which the protected consequence first becomes effective, or it must be re-established there under an equivalently strong rule.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivating Scenario: Policy Revision Between Approval and Effectuation Consider an agentic or automated system preparing a high-consequence operation. Policy revision P17 permits operation O for principal A when destination D, amount L, purpose U, and device posture Q satisfy specified conditions. A policy engine evaluates the concrete Candidate Act under P17 and issues a permit bound to the act. Before the operation becomes externally effective, policy revision P18 is made active. P18 can revoke destination D, reduce limit L, withdraw purpose U, change the required device posture, or revoke A entirely. The reasons for the update are not material to this document. What matters is that the security basis changed.

Cryptographically valid but state-stale authorization t0 t1 t2 | | | | evaluate C under P17 | activate P18 | effect C |------------------------|------------------------| | | | v v v +------+ +-----------+ +-------------+ | P17 | -- ALLOW --> | Permit A | | Finality | +------+ | sig valid | | Sink | +-----------+ +------+------+ | if only signature | unsafe and expiry checked v External Effect A simple expiry window does not fully solve the problem. P18 can become active one millisecond after P17 was evaluated. A short-lived permit can therefore be fresh in time and stale in meaning. The same structure appears outside agentic systems. A Relying Party can act on attestation results after reference state changes; a workload can execute under a stale authorization graph; a gateway can use an earlier route-to-policy mapping; a device can restore an older policy snapshot; or a resource operation can use an authorization bound to a previous ownership epoch.

Problem Space State continuity is distinct from message authenticity. A signed policy object can be authentic and old. It is distinct from request freshness. A fresh request can be evaluated against stale state. It is distinct from proof of possession. A legitimate presenter can present authority that no longer applies. It is also distinct from attestation freshness: fresh evidence about a component does not, by itself, identify which application policy revision governs the effect.

Freshness Is Not State Continuity RATS discusses freshness for Evidence, and EAT requires a freshness mechanism to prevent replay and related attacks . This is essential. The continuity problem is different: even freshly produced evidence can be appraised using reference data or policy state that later changes before effectuation. A deployment therefore MUST distinguish at least two questions: whether an input is fresh, and whether the security-relevant decision basis remains applicable at the effectuation boundary.

Signature Validity Is Not Current Applicability Cryptographic authenticity establishes who protected an object and whether the protected bytes were modified. It does not inherently establish that the object is the currently applicable revision. Anti-rollback systems commonly add a monotonic sequence, generation, or equivalent continuity mechanism for this reason. RFC 9124 provides a concrete example in the firmware-update domain: manifests carry monotonically increasing sequence numbers so devices can reject older manifests under the relevant authority's policy . This document generalizes the continuity question to authorization and effectuation state; it does not modify SUIT requirements.

A Policy Name or Location Is Not a Revision Identity A URI, database key, policy name, repository path, or logical mapping identifier can continue to refer to an object whose content has changed. Binding a permit only to such a locator therefore does not necessarily bind the permit to what was evaluated. Where policy or mapping content is security relevant, the evaluated content SHOULD be identified by a collision-resistant digest, authenticated immutable version, protected generation, or equivalent content-specific identity. Two revisions can be intended to be semantically equivalent even though their bytes differ. A Finality Sink SHOULD NOT be required to discover that equivalence dynamically. If cross-revision applicability is permitted, it SHOULD be established by an authoritative, machine-verifiable compatibility statement or by explicit re-evaluation.

Threat Model and Assurance Scope

Direct Question: What Threat Does This Architecture Solve? The direct threat is not merely theft or forgery of an authorization object. The architecture addresses the case in which an authorization can remain authentic, correctly signed, unexpired, and legitimately possessed while the security-relevant state that made it valid has changed before the protected consequence occurs. In the canonical case, Candidate Act C is correctly authorized under Decision Basis B17. Before effectuation, B18 becomes authoritative because policy, revocation, ownership, mapping, reference state, risk state, purpose scope, resource generation, or another load-bearing input changes. An attacker or ordinary requester then presents the still-authentic authorization derived from B17. The architecture solves this class by requiring the Finality Sink to establish that the evaluated basis remains current or explicitly applicable to the effect about to occur; otherwise the act is re-evaluated or remains non-effective. t0 t1 t2 | | | | authorize C under B17 | B18 becomes current | effect C? |--------------------------|--------------------------| | | | | valid authorization | old object still valid | | | cryptographically | | | | +--------------------------+--------------------------+ | v Finality Sink checks B17 -> current/applicable? | | no yes | | v v reject or protected re-evaluate commit The security objective is therefore continuity of authorization meaning through effectuation, not merely authenticity of the authorization artifact. The model also covers rollback, stale-permit replay, revision substitution, split-brain selection, crash or snapshot restoration, revocation races, and alternate-path effectuation when those mechanisms can cause an act to take effect under state different from the state that was actually evaluated.

Adversary Capabilities The adversary MAY control or compromise the requester, agent, application process, orchestration layer, ordinary host software, caches, untrusted persistent storage, and communication paths outside the protected enforcement boundary. The adversary MAY capture and replay previously valid authorization objects, present authentic but stale policy or mapping objects, restore snapshots, substitute mutable references, race policy changes against effectuation, exploit crash recovery, induce or exploit network partitions, and attempt to reach the protected consequence through an alternate effectuation path. The adversary MAY possess legitimate credentials and MAY have been legitimately authorized under an earlier Decision Basis. The security property therefore does not depend on proving malicious intent or on detecting credential theft. A principal that was correctly authorized at time t1 can be unauthorized at time t2, while still holding an authentic artifact issued at t1. The requester is not authoritative for current policy, mapping, revocation, ownership, or generation state. Security-critical current-state information MUST be obtained from protected state or from an authority whose authenticity and applicability satisfy the deployment's threat model.

Baseline Continuity Profile In the baseline profile, the requester, network path, untrusted storage, cached authorizations, application software, and previously issued authorization objects are considered potentially hostile or stale. The authoritative current-state source and the Finality Sink remain within the trusted computing base. The Finality Sink MUST NOT accept requester-supplied claims of current policy or generation without independently protected evidence. This profile is suitable where the principal risk is reuse or substitution of authorization after a legitimate decision, while the policy authority and enforcement boundary themselves remain trustworthy.

High-Assurance Continuity Profile Higher-assurance deployments MAY additionally assume compromise of the agent runtime, host application, orchestration software, general-purpose operating system, hypervisor, policy-distribution cache, or snapshot and recovery environment. Under such a threat model, those components MUST NOT be able to reset the authoritative continuity generation, fabricate current-state evidence, restore consumed authority, or directly create the protected consequence outside the Finality Sink. Current-generation state, continuity evidence, authorization consumption, and the final protected commit can be anchored in a protection domain not writable by the compromised components, such as an appropriately isolated TEE, security processor, HSM, DPU, SmartNIC, protected firmware component, or equivalent protected enforcement boundary. This document does not require one particular hardware technology; the requirement is protection of the load-bearing state and effectuation path against the adversary defined by the deployment.

Trust Assumptions and Out-of-Scope Compromise The model assumes that the cryptographic primitives protecting digests, signatures, MACs, authenticated state, and continuity evidence remain secure and that at least one configured root of authority or protected enforcement root required by the deployment remains uncompromised. Compromise of every ultimate policy authority, every configured trust anchor, or the Finality Sink itself is outside the base threat model. Deployments requiring tolerance of authority compromise MAY use independent authorities, threshold authorization, replicated protected state, transparency mechanisms, independent appraisal, or separation of duties. Those mechanisms strengthen the trust model but do not change the continuity invariant defined here. This architecture does not claim to determine whether a policy is substantively correct, infer human intent, eliminate implementation bugs, eliminate all side channels, resist physical destruction of trusted hardware, or protect a consequence reachable through a path outside the defined enforcement boundary. Such mechanisms can be complementary controls.

Availability and Denial of Service An adversary can attempt to make current state unavailable by attacking the policy-head service, continuity-evidence path, quorum, or protected state source. This can deny or delay protected operations. The architecture does not convert inability to establish current applicability into authorization: for operations whose threat model requires current continuity, unknown state MUST remain non-authorizing unless an explicit bounded- staleness or emergency rule has itself been authorized by policy.

Design Goals and Non-Goals The design goal is to prevent an act authorized against one security-relevant state from silently becoming effective under materially different state. The protected binding covers the concrete act and the decision basis required by the deployment, and the binding is checked at the boundary where the protected consequence first becomes effective. This document does not define a universal policy language, universal policy equivalence algorithm, new attestation format, new OAuth grant type, distributed consensus protocol, blockchain, or mandatory transparency service. Those systems can provide inputs to the model. The model also does not require that every policy update invalidate every pending act. A deployment can define explicit compatibility or transition rules. The requirement is that such applicability be established by authority and evidence, not guessed by the executing component after the decision basis changes.

Terminology Candidate Act: A proposed operation capable of producing an external, persistent, financial, administrative, physical, disclosure, or other protected consequence, but which has not yet been permitted to produce that consequence. Non-Effective State: A condition in which a Candidate Act can be computed, queued, validated, and authorized, while the requester still lacks the means to create the protected consequence without final enforcement. Decision Basis: The security-relevant state against which the Candidate Act was evaluated. It can include policy content, mappings, reference values, ownership, revocation state, account state, purpose grants, resource generations, risk data, or other mutable inputs. Decision-Basis Digest: A cryptographic commitment to the canonical representation of the Decision Basis, or to a protected root that unambiguously identifies the relevant state. Policy Generation: A monotonically advancing epoch, sequence, generation, or equivalent protected continuity value associated with an authoritative policy state. Continuity Evidence: Protected evidence establishing the relation between the state used at evaluation and the state applicable at effectuation. Execution Handle: Narrowly scoped authorization bound to a Candidate Act, its Decision Basis, and execution constraints. Possession of the handle is not intended to create unconstrained bearer authority for a different act or materially different state. Finality Sink: The protected functional boundary controlling the first operation that makes the Candidate Act externally effective. It can verify, reconstruct, or re-establish security-relevant state immediately before allowing effectuation. The term denotes a role, not a required physical location. Rollback: Presentation, restoration, or use of an older security state as though it were the currently applicable state, contrary to the relevant authority's continuity policy. Revision Substitution: Replacement of the evaluated policy, mapping, or state object with a different revision after evaluation but before effectuation.

Continuity Binding Model Let Candidate Act C contain the concrete security-relevant act parameters. Let B represent the security-relevant Decision Basis used to evaluate C. C = (subject, operation, object, destination, parameters, nonce, constraints) B = (policy_digest, mapping_digest, reference_state_digest, revocation_generation, resource_generation, authority_set_digest, policy_generation) A deployment need not use every field above. It MUST include or re-establish every mutable field whose change can alter whether the Candidate Act is permitted. A canonical authorization binding can be represented as: D_C = H(Encode(C)) D_B = H(Encode(B)) EH = Protect(D_C, D_B, UseConstraints, Freshness, IssuerContext) The semantic requirement is not tied to a particular token format. It is: Authorization(C, B17) does not imply Authorization(C, B18) when B17 and B18 differ in a security-relevant way. If B18 is explicitly declared compatible for C by an authority recognized by the deployment, continuity can be established through that declaration. Otherwise the act requires re-evaluation against B18.

Formal Mathematical ModelThis section makes the continuity requirement explicit independently of any token format, policy language, or storage mechanism. The model distinguishes the Candidate Act from the mutable Decision Basis under which that act was evaluated. Let: C = concrete Candidate Act B_t = authoritative Decision Basis at time t D_C = H(Canonical(C)) D_B(t) = H(Canonical(B_t)) EH = execution authority / Execution Handle CE = Continuity Evidence G_t = protected current generation at time t S_now = protected current state at the Finality Sink Representative basis: B_t = ( policy_digest, mapping_digest, reference_state_digest, revocation_generation, resource_generation, authority_set_digest, policy_generation) Only load-bearing mutable fields need to be represented.

Authorization at Evaluation TimeAn authorization decision is always relative to a particular Decision Basis, even when an implementation does not expose that basis explicitly. AuthorizedAtEvaluation(C, B_e) := PolicyAllows(C, B_e) AND ActWellFormed(C) AND EvaluationInputsTrusted(B_e) Issue(EH) only if AuthorizedAtEvaluation(C, B_e) = TRUE.

Decision-Basis IdentityNames, URLs, object identifiers, or mutable storage locations are insufficient as the sole identity of a load-bearing basis when their contents can change. The continuity model uses content identity or another protected immutable revision identity. BasisIdentity(B) := H(Canonical(B)) ExactBasisMatch(B_e, B_now) := BasisIdentity(B_e) = BasisIdentity(B_now)

Candidate-Scoped CompatibilityExact content identity is the safe default, but a deployment can permit a basis revision without full re-evaluation when an authority recognized by policy issues a machine-verifiable compatibility statement scoped to the Candidate Act or act class. CompatibleFor(C, B_e, B_now, CE) := VerifyCompatibilityAuthority(CE) AND CE.old_basis_digest = BasisIdentity(B_e) AND CE.new_basis_digest = BasisIdentity(B_now) AND CE.scope_covers(C) AND CE.generation = CurrentProtectedGeneration() AND CE.not_expired ContinuityOfBasis(C, B_e, B_now, CE) := ExactBasisMatch(B_e, B_now) OR CompatibleFor(C, B_e, B_now, CE)

Continuity PredicateThe continuity predicate joins exact-act binding, basis continuity, mutable-state currentness, authorized-use constraints, and path authorization at the Finality Sink. ContinuityValid(C, EH, B_now, CE, S_now) := EH.act_digest = H(Canonical(C)) AND ContinuityOfBasis(C, EH.evaluated_basis, B_now, CE) AND PolicyGenerationCurrent(B_now, S_now) AND MappingRevisionApplicable(C, B_now) AND RevocationStateCurrent(C, B_now, S_now) AND ResourceGenerationCurrent(C, B_now, S_now) AND AuthoritySetCurrent(C, B_now, S_now) AND FreshnessValid(EH, S_now) AND AuthorizedUseValid(EH, C, S_now) AND EffectuationPathAuthorized(C, S_now)

Safety Invariant Effective(C) => ContinuityValid(C, EH, B_now, CE, S_now) = TRUE Strict prevention form: NOT ContinuityValid(C, EH, B_now, CE, S_now) => NOT Effective(C)

Bounded Prevention ArgumentAssume that the Finality Sink controls every modeled path capable of making C effective; the exact pending act is observable there; current Decision Basis and generation state are protected against rollback; compatibility evidence cannot be forged for an untrusted authority; and the continuity check is coupled atomically or equivalently to the protected commit. Under those assumptions, a Candidate Act evaluated under stale basis B_e cannot become effective under materially different B_now unless exact continuity, an explicit authorized compatibility relation, or a fresh re-evaluation establishes applicability.Proof sketch: if B_now differs materially and neither ExactBasisMatch nor CompatibleFor is true, ContinuityOfBasis is false. Therefore ContinuityValid is false, and by the strict prevention rule Effective(C) must remain false. A successful stale-authority effect must therefore break an explicit assumption: basis integrity, current-generation integrity, compatibility authenticity, path completeness, or commit ordering.

Continuity Decision Diagram

Finality Predicate and Safety Invariant Immediately before effectuation, the Finality Sink evaluates a predicate Phi over the concrete Candidate Act, current protected state, the Execution Handle, and continuity evidence. Phi(C, S_now, EH, CE) = ExactActBinding AND DecisionBasisBindingValid AND CurrentGenerationAcceptable AND MappingRevisionApplicable AND RevocationStateCurrent AND ResourceGenerationCurrent AND FreshnessValid AND AuthorizationUseValid AND ContinuityEvidenceValid AND EffectuationPathAuthorized The fundamental safety invariant is: Effective(C) => Phi(C, S_now, EH, CE) = TRUE It is insufficient that Phi would have been true at an earlier time. If state material to authorization can change, the Finality Sink MUST establish that the evaluated basis remains applicable, or MUST trigger re-evaluation before allowing the act to become effective.

State Machine A deployment can collapse internal implementation states, but it MUST preserve the property that policy or state drift cannot silently turn previously valid approval into current execution authority.

Decision-Basis Continuity DiagramsThe following diagrams separate three different failure surfaces: stale-basis reuse, semantic-revision ambiguity, and a race between the final continuity read and protected commit.

Stale basis survives from evaluation to effectuation t0 t1 t2 | | | | evaluate C under B17 | B18 becomes authoritative| Finality Sink | issue EH bound to B17 | | receives C + EH |--------------------------|--------------------------| | v If B17 is no longer applicable: old EH is NOT current authority.

Exact revision identity versus open-ended semantic guessing SAFE DEFAULT Mapping M17 content ------> digest D17 Mapping M18 content ------> digest D18 D17 == D18 ? | yes ---> exact continuity | no v explicit machine-verifiable compatibility proof? | | yes no | | v v candidate-scoped RE-EVALUATE compatibility (do not guess equivalence) The Finality Sink compares protected identities; it does not perform an open-ended semantic judgement.

Generation race at protected commit Finality thread Policy thread --------------- ------------- read generation G17 verify C against B17 publish B18 advance generation G18 attempt protected commit | v compare expected G17 with current G18 | +---- mismatch ----> abort / re-evaluate Only a commit that proves the observed generation is still current may make the act effective.

Continuity evidence as an explicit bridge, not bearer authority B17 evaluation | | issue EH bound to C + B17 v NON-EFFECTIVE C | B18 becomes current | +--> exact identity? ------------------ yes --> final check | +--> authoritative compatibility CE? -- yes --> final check | +--> otherwise ------------------------------> re-evaluate CE proves only the permitted continuity relation. Possession of CE alone does not make C effective.

Solution Overview

Prepare The system constructs a Candidate Act and a canonical representation of the security-relevant act parameters. Preparation MUST NOT itself create the protected consequence.

Evaluate The policy or validation function evaluates the Candidate Act against the Decision Basis. The Decision Basis SHOULD be represented by content-specific identities and protected continuity values rather than mutable names alone.

Bind The system issues an Execution Handle or equivalent authorization bound to the exact Candidate Act and to the Decision Basis used to approve it. A security-relevant basis field MUST either be bound into the authorization or be re-established at finalization under an equivalent protected invariant.

Finalize At the Finality Sink, the system reconstructs or observes the concrete act, determines the current protected generation and state, verifies continuity from the evaluated basis to the current basis, and enforces authorized-use semantics. If continuity cannot be established, the Candidate Act remains non-effective.

Illustrative Pseudocode The following pseudocode is non-normative. It separates evaluation, protected basis identity, compatibility evidence, concurrent generation handling, finalization, invalidation, and crash recovery so that the continuity invariant is implementation-visible rather than implied.

Build the Load-Bearing Decision Basis function build_decision_basis(candidate): return DecisionBasis( policy_digest = digest(current_policy_for(candidate)), mapping_digest = digest(current_mapping_for(candidate)), reference_state_digest = digest(current_reference_state(candidate)), revocation_generation = current_revocation_generation(candidate), resource_generation = current_resource_generation(candidate), authority_set_digest = digest(current_authority_set(candidate)), policy_generation = protected_policy_generation())

Evaluate and Bind Candidate Act function evaluate_and_bind(candidate): C = canonical(candidate) B = build_decision_basis(candidate) if !policy_allows(C, B): return DENY return issue_execution_handle( act_digest = H(C), basis_digest = H(canonical(B)), evaluated_basis = protected_reference(B), policy_generation = B.policy_generation, resource_generation = B.resource_generation, revocation_generation = B.revocation_generation, authority_set_digest = B.authority_set_digest, nonce = secure_random(), use_constraints = derive_use_constraints(C, B), expiry = bounded_expiry())

Validate Candidate-Scoped Compatibility Evidence function validate_compatibility(candidate, handle, B_now, CE): if CE == NONE: return FALSE if !verify_signature_and_authority(CE): return FALSE if CE.old_basis_digest != handle.basis_digest: return FALSE if CE.new_basis_digest != H(canonical(B_now)): return FALSE if !CE.scope_covers(candidate): return FALSE if CE.generation != current_protected_generation(): return FALSE if CE.expired: return FALSE return TRUE

Check Continuity Against Current Basis function continuity_check(candidate, handle, CE): B_now = protected_current_basis(candidate) if H(canonical(B_now)) == handle.basis_digest: return CONTINUITY_EXACT if validate_compatibility(candidate, handle, B_now, CE): return CONTINUITY_EXPLICITLY_COMPATIBLE return REEVALUATION_REQUIRED

Finalize with Protected Generation Check function finalize(observed_candidate, handle, CE): begin_protected_finality_section() C = canonical(observed_candidate) if handle.expired or handle.consumed: reject("expired or consumed authority") if H(C) != handle.act_digest: reject("exact-act mismatch") observed_generation = current_protected_generation() B_now = protected_current_basis(observed_candidate) continuity = continuity_check(observed_candidate, handle, CE) if continuity == REEVALUATION_REQUIRED: return reevaluate_or_reject(observed_candidate, B_now) if current_revocation_generation(observed_candidate) != B_now.revocation_generation: reject("revocation state changed") if current_resource_generation(observed_candidate) != B_now.resource_generation: reject("resource generation changed") if digest(current_authority_set(observed_candidate)) != B_now.authority_set_digest: reject("authority set changed") if !authorized_use_valid(handle, observed_candidate, B_now): reject("use constraints violated") if !effectuation_path_authorized(observed_candidate): reject("alternate or unmediated effectuation path") atomic { assert current_protected_generation() == observed_generation assert H(canonical(protected_current_basis(observed_candidate))) == H(canonical(B_now)) protected_consume_once(handle) commit_effect(observed_candidate) } return SUCCESS

Invalidate or Revalidate After Basis Change function on_decision_basis_change(change): if !change_can_affect_authorization(change): record_non_load_bearing_change(change) return new_generation = advance_protected_generation() publish_new_basis_identity(change, new_generation) for pending in affected_pending_candidates(change): mark_continuity_unknown(pending, new_generation) if authoritative_compatibility_exists(pending, change): attach_scoped_compatibility_evidence(pending) else: require_reevaluation(pending)

Handle a Concurrent Policy Update function commit_if_generation_unchanged(candidate, handle, expected_generation): atomic { if current_protected_generation() != expected_generation: return RETRY_WITH_CURRENT_BASIS if !handle_still_applicable(candidate): return REEVALUATE protected_consume_once(handle) commit_effect(candidate) } return SUCCESS

Crash and Recovery Handling function recover_finality(record): if record.effect_committed: mark_handle_consumed(record.handle) return EFFECT_ALREADY_FINAL if record.handle_consumed and !record.effect_committed: # Deployment-specific recovery must not blindly replay. return REQUIRE_IDEMPOTENT_RECOVERY_OR_MANUAL_RESOLUTION if record.generation != current_protected_generation(): return REEVALUATE_UNDER_CURRENT_BASIS return SAFE_TO_RETRY_FINALIZATION

Continuity-Finalization Flow Diagram

Detailed continuity-finalization flow Candidate C + EH | v exact C digest? ----- no ----> reject | yes v current basis B_now | +--> exact digest match -------- yes ---+ | | +--> scoped compatibility CE --- yes ---+--> current-state checks | | +--> neither ---------------------------> re-evaluate / reject | v capture generation G | v atomic compare G == current? / \ no yes | | retry consume-once + commit

End-to-End Architecture

Decision-basis continuity through the Finality Sink +--------------------+ | Requester / Agent | +---------+----------+ | | Candidate Act C v +--------------------+ +---------------------+ | Policy / Decision |<-------| Policy, mapping, | | Function | | reference state | +---------+----------+ +----------+----------+ | | | ALLOW under basis B17 | revisions advance v v +--------------------+ +---------------------+ | Execution Handle | | Current Basis B18 | | H(C) + H(B17) | | protected epoch | +---------+----------+ +----------+----------+ | | +--------------+---------------+ | v ===================================================== FINALITY SINK ===================================================== exact act binding evaluated basis identity current protected generation revocation / ownership / mapping state explicit compatibility OR re-evaluation replay / use constraints | +-----+-----+ | ALL TRUE? | +--+-----+--+ | | no yes | | v v REJECT PROTECTED COMMIT | v EXTERNAL EFFECT Components above the boundary can compute, recommend, attest, authorize, or cache decisions. They do not make stale state current merely by preserving a valid permit. The Finality Sink controls whether the authorization remains applicable to the state under which the consequence will occur.

Attack Analysis

Policy Rollback An attacker restores signed policy P16 after the authoritative state advanced to P18. Signature verification succeeds because P16 is authentic. A protected current-generation requirement causes the rollback to fail because authenticity does not satisfy current applicability.

Mapping Revision Substitution Candidate Act C is evaluated using mapping M17. Before effectuation, an intermediary changes the mapping target to M18 while keeping the same logical mapping name. If authorization binds the content digest or immutable revision of M17, M18 is not silently treated as the same evaluation basis. The act requires an explicit compatibility proof or re-evaluation.

Reference-State Rollback Fresh attestation Evidence is appraised against an older but authentic reference-value set that accepts a software state no longer accepted by current policy. State-continuity verification requires the applicable reference-state generation or equivalent authority context, not merely a fresh nonce in the Evidence.

Stale Permit Replay An authorization was valid before revocation and remains inside its wall-clock expiry. An attacker presents it after the relevant revocation generation has advanced. The Finality Sink rejects it because the bound Decision Basis does not correspond to current applicable state.

Split-Brain Authority State Two enforcement nodes observe different policy heads or revocation generations. Both can hold authentic state. A deployment requiring a single authoritative head MUST define how the Finality Sink determines the acceptable protected generation or consistency rule. This document does not prescribe a consensus algorithm.

Semantic-Equivalence Confusion An attacker argues that M18 is "equivalent" to authorized mapping M17 while M18 changes a security-relevant rule. The Finality Sink does not infer equivalence from labels, paths, or human-readable descriptions. Cross-revision applicability requires an authoritative compatibility statement or re-evaluation.

Crash and Snapshot Rollback A virtual machine, enclave, policy service, or local database is restored from a snapshot containing an older accepted generation. If the Finality Sink relies only on snapshot-local state, old permits can appear current again. Higher- assurance deployments SHOULD anchor current generations in protected monotonic state, an external authority, or another continuity mechanism not rolled back by the same snapshot.

Bounded and Non-Bearer-Like Authorization Sender-constraining a token can prevent an unauthorized party from presenting it, but the legitimate sender can still hold a permit whose decision basis is stale. The execution-finality binding therefore includes both who or what can present authority and the exact act and state basis for which that authority applies. For a handle EH issued for Candidate Act C under Decision Basis B17, the desired property is: Finalize(C, B18, EH[C,B17]) = SUCCESS only if B18 is the same applicable basis, an authoritative compatibility relation exists, or C is re-evaluated under B18. This property is complementary to proof-of-possession and sender-constraining mechanisms such as OAuth DPoP .

The Alternate-Path Requirement State continuity is ineffective if an alternate effectuation path can bypass the continuity check. A legacy API, emergency interface, direct device command, privileged database write, local actuator path, or second resource server can recreate the same protected consequence without observing the current policy head.

State-continuity bypass +--> continuity check --> effect Candidate Act ---+ +----------------------> effect bypass Every mechanism capable of creating the protected consequence MUST either pass through the Finality Sink or enforce an equivalent state-continuity invariant.

Concurrency, Generations, and Policy Heads Multiple policy updates and effectuation attempts can race. Implementations MUST define what constitutes the authoritative current state for the operation being finalized. A protected generation, epoch, version vector, signed head, or equivalent mechanism can provide this ordering. current_policy_generation = g evaluate(C) under g advance policy to g+1 finalize(C, permit[g]) => reject, re-evaluate, or prove explicit compatibility with g+1 A generation number by itself is not sufficient if an attacker can reset the generation store. The continuity value must be protected according to the threat model.

Applicability Beyond a Single Policy Engine The continuity model applies wherever a security decision and a protected effect are separated in time or by components. Examples include agentic tool calls, payment or administrative operations, workload admission, device assignment, network control, AI output release, secure software lifecycle operations, data- purpose enforcement, and industrial actuation. The exact Decision Basis differs by domain. For a payment it can include limits, payee authorization, fraud state, and account status. For a RATS-based decision it can include reference-value or appraisal-policy identity. For AI output release it can include requester scope, purpose grant, model/output class, and current safety policy. For a device transition it can include resource generation, ownership, lifecycle state, and destination authorization.

Industrial Relevance and Complementary Standards Alignment This section identifies protocol and deployment classes where state continuity is relevant. The examples are alignment points only. Nothing in this document asserts that any referenced product, service, standard, vendor architecture, or deployment is vulnerable, incomplete, or non-conformant. Existing identity, authorization, attestation, confidential-computing, and policy products remain useful inputs and enforcement components; the proposal adds a separate continuity invariant for the interval between decision and protected effectuation.

Agentic and Automated Tool Execution Agent systems can obtain authorization before the final concrete operation is effectuated. Revocation, user consent, account state, routing mappings, and tool policy can change during that interval. Exact-act binding and state-continuity checking can therefore be composed with existing agent authorization, API security, tool-permission, and policy systems rather than replacing them.

Microsoft Entra Continuous Access Evaluation Microsoft Entra Continuous Access Evaluation (CAE) is an industrial example of reevaluating access when critical events such as account disablement, password change, explicit revocation, risk change, or relevant Conditional Access state changes occur . CAE demonstrates the practical value of reducing the gap between token issuance and later enforcement. The continuity model in this document is complementary: it generalizes the question to arbitrary Decision Basis inputs and binds that applicability to an exact Candidate Act at its protected effectuation boundary. No claim is made that CAE should adopt this architecture or that CAE fails to provide its documented protections.

Amazon Verified Permissions and Cedar Amazon Verified Permissions provides fine-grained application authorization using Cedar policies and evaluates whether a principal may perform an action on a resource in context . Such a policy decision point can serve as an authorization input to this model. Where the protected operation occurs later, a deployment can additionally bind the relevant policy-store state, policy generation, or authenticated decision basis to the Candidate Act and re-establish applicability at effectuation. This is an additional end-to-end invariant, not a replacement for Verified Permissions or Cedar.

Google Cloud IAM Policy Enforcement Google Cloud IAM supports allow and deny policy mechanisms for controlling access to resources . In a deployment using such policy systems, current IAM state can be one of the authoritative inputs to the Decision Basis. The execution-finality continuity model is complementary: it specifies how load-bearing policy state can remain cryptographically or transactionally connected to a later consequence when the decision and effect are separated in time or across components.

OAuth and Resource-Server Enforcement Rich Authorization Requests allow fine-grained authorization data to be carried in OAuth messages . DPoP can sender-constrain access and refresh tokens . These mechanisms can be useful inputs to an execution-finality deployment. This document focuses on the separate question of whether the state basis against which an exact operation was authorized remains applicable when the resource server or downstream sink makes that operation effective. The model is complementary to OAuth and does not redefine OAuth token semantics.

RATS and Attestation-Based Decisions RATS separates Attesters, Verifiers, and Relying Parties and describes freshness and appraisal concepts . EAT provides claims and freshness mechanisms for attestation tokens . A Relying Party can additionally require continuity of the policy, reference state, or authorization mapping used to turn an Attestation Result into permission for a consequential act. This document therefore treats attestation as a valuable trust input, not as a competing mechanism.

NVIDIA Attestation and Arm Confidential Compute Architecture NVIDIA documents an attestation suite for cryptographically verifying GPU hardware and software integrity . Arm CCA and RME provide hardware-backed isolation and attestation for Realm-based confidential computing . Such mechanisms can protect or supply trust information for continuity state, validators, or effectuation components in higher-assurance deployments. The proposal here is complementary: it consumes or protects those trust signals while asking whether the exact authorization basis remains applicable to the exact consequence being committed.

SUIT and Anti-Rollback Patterns RFC 9124 requires monotonically increasing manifest sequence numbers in its firmware manifest information model to mitigate rollback under the relevant firmware authority . The continuity model in this document is compatible with that pattern while applying it to broader authorization state and to the interval between evaluation and effectuation.

Confidential and High-Assurance Computing Confidential-computing systems can protect code and data while policy and lifecycle state remain mutable outside or across protected components. A protected environment can therefore host the continuity verifier, protected generation state, or Finality Sink. The architecture is intentionally composable with such platforms and does not require changes to a particular vendor's silicon, firmware, or confidential-computing programming model.

Open Questions, Critique, and Corrections Invited This document is offered for technical scrutiny. Criticism, corrections, counterexamples, implementation experience, prior-art pointers, and references to existing standards that already provide equivalent properties are explicitly invited. The intent is to refine or falsify the proposed invariant where evidence supports doing so, not to characterize existing industrial or standards work as deficient. This document intentionally separates the continuity invariant from any single token format, policy language, storage technology, hardware vendor, cloud platform, or consensus mechanism. In particular, review is requested on the following open questions:

Do existing IETF, W3C, OpenID, confidential-computing, cloud-authorization, interconnect, or vendor mechanisms already provide an equivalent end-to-end invariant from authorization under a particular Decision Basis through the first externally effective consequence? If so, at what boundary and under what threat model?
Is the adversary model stated in this document appropriate for both the Baseline and High-Assurance Continuity Profiles? Which components should be trusted, independently protected, or explicitly considered compromisable?
Which mutable inputs are genuinely load-bearing for authorization and therefore require effect-time binding or protected re-establishment? Are policy generation, mapping revision, revocation state, resource generation, authority set, and reference state sufficient, excessive, or incomplete?
Can an authentic and unexpired authorization issued under basis B17 safely remain usable after basis B18 becomes authoritative without re-evaluation? If so, what machine-verifiable compatibility relation is sufficient to establish that result?
Is exact content identity an appropriate safe default for policy and mapping revisions? Where semantic equivalence is required, can it be represented without requiring the Finality Sink to make an open-ended semantic judgement?
What protected mechanism should establish the authoritative current generation in deployments exposed to rollback, snapshot restoration, compromised host software, split-brain authorities, or recovery from crash?
Which alternate effectuation paths could bypass continuity enforcement in real deployments, including administrative APIs, recovery tooling, direct storage or device access, privileged host paths, or independently reachable resource servers?
What atomicity, locking, compare-and-swap, transactional, or equivalent property is required between the final continuity observation and the protected commit when policy state can change concurrently?
What latency, availability, cache-coherency, and state-distribution costs would make the proposed invariant impractical on a hot path, and which bounded-staleness or compatibility techniques preserve the security objective without requiring a synchronous global policy lookup for every operation?
How should this architecture compose with existing industrial mechanisms such as continuous access evaluation, fine-grained cloud authorization, attestation, confidential computing, and hardware-protected state without duplicating functions those mechanisms already provide?

Concrete counterexamples are especially useful. A useful test is to identify a system in which authorization is evaluated under basis B17, basis B18 becomes authoritative before effectuation, and the system can demonstrate that use of the old authorization cannot create a consequence forbidden by B18 without relying on an unverified semantic assumption. Evidence that an existing protocol already closes that interval is equally useful and should be treated as a correction or refinement to this document.

Questions to the IETF Community The author requests community review not only of the mechanism but also of whether the problem statement is correctly scoped for IETF work. The following questions are intentionally direct. Negative answers, references to existing equivalent mechanisms, and proposals to narrow the work are useful outcomes.

Is there an existing IETF mechanism that already guarantees that an authorization evaluated under Decision Basis B17 cannot create a protected effect after B18 becomes authoritative unless B17 remains explicitly applicable? If so, which protocol and which enforcement boundary provide that invariant?
Should current policy, revocation, reference-value, ownership, or resource-generation state be represented directly in an authorization object, reconstructed at the Resource Server or Relying Party, or carried as separately verifiable Continuity Evidence?
Can existing RATS epoch, freshness, reference-value, or Attestation Result mechanisms express the required continuity relation without defining a new protocol object, or is an additional effectuation-time binding required?
For OAuth-protected operations, is the correct enforcement point simply the Resource Server, or are there important deployments in which the first externally effective consequence occurs below or beyond the Resource Server and therefore requires a distinct final enforcement boundary?
For WIMSE-style multi-service chains, which workload should be authoritative for the Decision Basis when identity, policy, or authorization context changes across service boundaries? Is end-to-end continuity achievable using existing workload credentials and token-exchange patterns?
Would a minimal interoperable representation of Decision-Basis identity, generation, compatibility, and consume-once state be useful, or should this document remain purely architectural and allow application protocols to define their own encodings?
Where bounded staleness is operationally necessary, what properties are required so that a deployment can accept a bounded window without silently converting stale authority into current authority?
Should this work ultimately be Informational architecture, a Best Current Practice, a Standards Track protocol element, or input to one or more existing Working Groups?
Which IETF venue is the most appropriate home for further discussion: SEC-DISPATCH, RATS, OAuth, WIMSE, SEAT, another existing Working Group, or a separate effort? The author explicitly invites guidance on disposition rather than presuming Working Group ownership.

Relationship to Existing Work

RATS and EAT RATS provides an architecture for Evidence, appraisal, Attestation Results, and Relying Party decisions . EAT specifies a token format and requires a freshness mechanism . This document does not redefine those mechanisms. It addresses continuity between the state basis of a decision and the later effect controlled by a Relying Party or another protected sink.

SUIT The SUIT architecture and manifest information model address secure firmware update and include explicit rollback considerations . The monotonic-sequence pattern is closely related to one class of continuity mechanism. This document generalizes the problem to mutable authorization and policy state, where multiple independent state inputs can change after an allow decision.

TEEP The TEEP architecture describes lifecycle management for Trusted Applications in Trusted Execution Environments . TEE protection can be used to protect a policy generation, continuity store, or Finality Sink, but a TEE is not required by the abstract model.

OAuth Fine-Grained and Sender-Constrained Authorization RFC 9396 supports fine-grained authorization details, while RFC 9449 constrains token use to a presenter proving possession of a corresponding key . The state-continuity problem can still arise when an otherwise valid exact or sender-constrained authorization outlives the decision basis under which it was issued. This document is intended as a complementary effectuation invariant, not a replacement for OAuth.

Related Execution-Finality Internet-Drafts This document is a focused member of a broader set of individual execution-finality submissions. The architectural overview is described in . Hardware-rooted enforcement is discussed in ; agentic tool dispatch in ; attestation-bound execution finality in ; purpose-bound data use in ; and AI interoperability in . The present document is intentionally narrower: its load-bearing subject is continuity of mutable state and policy between evaluation and effectuation. These documents are individual Internet-Drafts and works in progress. Cross-reference here indicates technical lineage and scope separation; it does not imply IETF adoption, consensus, endorsement, or standards status.

Public Implementations and Companion Engineering Material Public repositories provide executable or explanatory material for related portions of the execution-finality architecture. The general architecture repository is . An attestation-bound GPU and confidential-workload implementation is available at . Challenge-bound AI interoperability hardening is available at , and a purpose-execution-finality validator is available at . A separate AI-interoperability implementation is available at . These repositories exercise related properties such as exact-act binding, challenge or context binding, replay resistance, protected validation, and Finality Sink enforcement. They are cited as companion engineering material and are not represented as implementing every state- and policy-continuity requirement in this document unless a repository explicitly says so.

IETF Security-Area Relevance The problem crosses attestation, authorization, secure software lifecycle, protocol state, and high-consequence automated execution. Discussion can therefore be relevant to the Security Area even where no existing Working Group owns the complete cross-layer effectuation invariant.

Potential IETF Discussion Venues and Scope Boundaries This document is an Individual Submission and does not presume adoption by any Working Group. Because the proposed invariant crosses authorization, attestation, workload identity, protected state, and effectuation, no single existing charter is assumed to own the complete problem. The venues below are identified for technically relevant review and routing, not as claims of charter ownership.

SEC-DISPATCH: Security Dispatch is the most natural initial venue for determining disposition of cross-cutting Security Area work. Its role includes assessing whether proposed work is appropriate for the IETF, identifying overlap with existing protocols, and directing work to an existing Working Group, a BOF or new charter, AD sponsorship, or another outcome .
RATS: RATS is directly relevant where the Decision Basis contains Evidence, Attestation Results, Endorsements, Reference Values, freshness state, or epoch information. The present document's additional question is whether those inputs remain applicable at the later effectuation boundary. Review by RATS is therefore particularly valuable for avoiding duplication and for testing whether existing attestation constructs already express the required continuity relation .
OAuth: OAuth is relevant where a concrete operation is authorized through access tokens, Rich Authorization Requests, sender-constrained credentials, transaction tokens, token status, revocation, or automated-agent delegation. The OAuth Working Group's current work explicitly includes complex delegation for automated agents. The present document does not propose to redefine OAuth; review is requested on whether existing or emerging OAuth mechanisms already provide equivalent state continuity through effectuation .
WIMSE: WIMSE is relevant to workload identity, least-privilege access across multiple service platforms, token exchange, and multi-hop workload contexts. It is a useful venue for examining whether Decision-Basis continuity must survive workload and administrative-domain transitions, and whether existing workload credentials can carry or reference the required state .
SEAT: SEAT is relevant when continuity evidence or attestation state must be bound to a secure channel. Its charter focuses on binding remote attestation to TLS or DTLS connections, so it is a complementary review venue for transport-bound state rather than an assumed home for general authorization finality .
SCITT: SCITT is relevant where signed statements, receipts, transparency, provenance, or integrity of Decision-Basis material are used as Continuity Evidence. SCITT's focus is trustworthy and transparent digital supply chains, not general execution authorization; accordingly, its relevance is primarily compositional and evidentiary .
SUIT: SUIT provides an important standards precedent for authenticated manifests, generations, and anti-rollback behavior. Its charter is firmware-update-specific, so it is more naturally a source of review and reusable continuity patterns than the primary home for a general state-and-policy-continuity architecture .
SAAG: The Security Area Advisory Group is an open forum for cross-area security and privacy discussion and can provide broad architectural feedback. SAAG is not a Working Group and does not adopt or publish documents, so it is a discussion venue rather than a document home .

The intended sequencing is therefore: seek technical criticism and overlap analysis, use SEC-DISPATCH for routing if the work remains cross-cutting, and pursue discussion in the relevant specialist Working Groups where their existing charters cover particular components. This document does not request that any named Working Group expand its charter solely to accommodate the architecture.

Operational and Deployment Considerations

Choosing the Decision-Basis Scope Binding every possible state variable can make authorization unnecessarily fragile and expensive. Deployments SHOULD bind only state whose change can alter the authorization outcome or the protected consequence. The threat model SHOULD document which inputs are load-bearing.

Digest Granularity A digest of an entire policy repository is simple but can invalidate unrelated operations whenever any rule changes. Merkle roots, scoped policy objects, immutable policy modules, versioned decision graphs, or other structures can reduce unnecessary invalidation while retaining content-specific identity.

Latency Re-evaluating a complete policy at every sink can be expensive. Deployments can use protected current-generation checks, prevalidated policy artifacts, local revocation summaries, authenticated compatibility statements, or bounded caches. Such optimization MUST NOT make stale cached state independently sufficient to create the protected consequence.

Distributed State and Temporary Inconsistency Large systems can temporarily disagree about the newest policy revision. Deployments MUST define the acceptable consistency model for protected effects. Some low-risk operations can tolerate bounded staleness. High-consequence operations can require a strongly current authority head or explicit recheck. This document does not mandate one consistency model for all applications.

Failure Handling If a required continuity predicate cannot be established, high-consequence deployments SHOULD keep the Candidate Act non-effective. Missing policy-head state, unavailable revocation information, ambiguous mapping revision, or rollback-detection failure SHOULD NOT silently become authority to proceed.

Security Considerations The security of the model depends on protecting both the effectuation path and the state that defines current applicability. A perfect content digest provides no continuity if an attacker can reset the trusted current-generation register; a protected generation provides no effectuation security if the protected consequence can bypass the Finality Sink.

Compromised Requester The requester is not assumed to provide truthful current policy, mapping, epoch, or revocation state. The Finality Sink MUST obtain security-critical continuity information from protected state or an authority appropriate to the threat model.

Compromised Policy or Mapping Service A compromised authoritative policy service can issue malicious current state or compatibility statements. Higher-assurance deployments MAY use threshold control, independent policy authorities, transparency or audit mechanisms, hardware-protected roots, or other separation of duties. This document does not claim to protect against compromise of every ultimate authority.

Time-of-Check to Time-of-Use This document directly addresses a TOCTOU class in which authorization state can change after a decision. The Finality Sink SHOULD minimize the interval between the last continuity check and the protected commit. Where state can change concurrently, the check and commit require atomicity, generation locking, compare-and-swap semantics, transactional protection, or an equivalent invariant.

Rollback Protection Policy generations, revocation generations, and other continuity values SHOULD resist rollback, snapshot restoration, wraparound, reset, and cross-domain reuse. An authentic old state MUST NOT automatically be accepted as current state.

Canonicalization and Content Identity Policy and mapping objects MUST have an unambiguous representation before a digest is treated as revision identity. Equivalent textual encodings, ordering, whitespace, included files, external references, environment variables, and dynamically resolved dependencies can otherwise make a digest fail to represent the actual semantics used during evaluation. Where evaluation depends on external data, the binding SHOULD cover the resolved load-bearing data or an authenticated root representing it. Hashing a top-level policy file while leaving mutable referenced data unbound does not provide the intended property.

Semantic Equivalence Determining whether two arbitrary policies are semantically equivalent can be computationally difficult, environment-dependent, or undecidable in the general case. The security model therefore does not require the Finality Sink to solve semantic equivalence. Exact content identity is the safe default; explicit authoritative compatibility or re-evaluation is the escape mechanism.

Revocation Race A revocation can occur after an Execution Handle is issued and immediately before effectuation. If revocation is load-bearing for the operation, the Finality Sink MUST verify a current revocation generation, protected revocation result, or equivalent state as part of the protected commit.

Split-Brain and Partitioned Authorities Network partitions can create multiple apparently current policy heads. Systems MUST define whether effectuation fails closed, uses quorum or consensus, accepts bounded staleness, or follows another explicit rule. An attacker MUST NOT be allowed to choose whichever reachable stale authority produces the desired authorization unless that behavior is intentionally part of policy.

Non-Bypassability Debug paths, emergency controls, administrative APIs, direct storage writes, alternate resource servers, recovery tooling, and privileged host interfaces require explicit analysis. Every path capable of creating the protected consequence MUST preserve an equivalent continuity invariant.

Crash Consistency Authorization consumption, policy-head observation, continuity verification, and effectuation can span multiple components. A crash MUST NOT restore an older policy generation or make a consumed stale authorization reusable. Protected journals, monotonic counters, idempotent recovery, transactional stores, or equivalent mechanisms SHOULD be used where required by the threat model.

Fail-Closed Behavior and Denial of Service Requiring current state can create availability pressure. Attackers can target the policy-head service or continuity evidence path to prevent protected actions. Availability engineering, replication, and cached evidence can reduce this risk, but recovery mechanisms MUST NOT silently convert "state unknown" into "state authorized" for operations whose threat model requires current continuity.

Privacy Considerations Decision-Basis records can reveal user identity, account status, organizational relationships, policy membership, purpose, risk classification, workload identity, location or jurisdiction, and timing. Implementations SHOULD minimize retained state and SHOULD avoid exposing raw policy inputs when a digest, keyed commitment, selective-disclosure proof, or scoped continuity statement is sufficient. Stable policy or mapping digests can themselves become correlators across systems. Deployments SHOULD consider whether global content identifiers are necessary or whether domain-scoped commitments provide the required enforcement property with less linkability.

IANA Considerations This document has no IANA actions.

Conclusion A valid authorization object can become stale without becoming cryptographically invalid. Freshness, signatures, attestation, sender-constraining, and fine-grained authorization remain necessary mechanisms, but they answer different questions. State and policy continuity adds an effectuation-time invariant: the exact act that becomes effective must still correspond to an applicable decision basis, or it must be re-evaluated under the basis that is current. A policy or mapping revision is identified by what was actually evaluated, not merely by a mutable name or location, and semantic equivalence is not silently inferred at the Finality Sink. In short: authorization valid then is not automatically authority now.