Freshness, Revocation, and Anti-Rollback Controls: Preventing Stale Authority

Mechanism

Freshness of governance authority is enforced as an objective eligibility precondition that is evaluated before instantiation of any execution context for a proposed action. The disclosed systems treat a resolved policy object as authoritative only when it satisfies freshness controls, so an agent object cannot rely on stale, revoked, superseded, downgraded, or replayed authority, including under caching, intermittent connectivity, partial replication, or distributed dissemination. The controls are not a separate subsystem layered on top of authorization. Freshness determinations are evaluated as part of the alias-resolution pipeline and may be re-evaluated immediately prior to authorization, so the final authorization decision reflects the evaluation time basis and the current revocation and monotonicity state rather than whatever authority happened to be cached.

For a given proposed action, a governance gate deterministically outputs either an authorization permit enabling instantiation or a denial outcome constituting valid non-execution. The denial outcome is produced without instantiating an execution context. Three freshness controls govern this decision: validity-window semantics, revocation as negative authority, and anti-rollback constraints. If any of the three fails for a required canonical policy alias, the gate denies the proposed action and prevents instantiation. Ethical, safety, regulatory, and operational constraints are example classes of governance constraint subject to the same controls.

Validity-Window Semantics

A policy object may include a validity component defining an activation boundary and an expiration boundary, expressed as notBefore and notAfter semantics. A policy object is treated as non-authoritative prior to activation and after expiration regardless of authenticity, declared scope, or remaining cache availability. The governance gate evaluates validity-window satisfaction during authorization and denies authorization when the evaluation time falls outside the defined window. A cryptographically valid signature is not sufficient: a genuinely signed but expired policy object confers no authority, because validity is a separate precondition from authenticity.

Alias resolution is itself validity-aware. Candidate policy objects discovered for a canonical alias are filtered by excluding candidates that are non-active or expired under the evaluation time basis, and by preferring candidates whose validity window encompasses the evaluation time. A validity-window failure may be recorded in an append-only audit record as a freshness-related denial event, including the evaluation time basis and the boundary data used to determine non-authoritativeness.

Revocation as Negative Authority

Revocation operates as negative authority. A revocation artifact renders a policy object non-authoritative notwithstanding authenticity, scope applicability, or remaining validity duration. Revocation may be expressed through revocation anchors, revocation lists, revocation epochs, or other artifacts verifiable under the applicable trust model and resolvable via canonical aliases or associated publication substrates. During authorization, the governance gate evaluates applicable revocation artifacts and denies instantiation of an execution context if a resolved policy object is determined to be revoked.

As with validity, the check is pushed down into resolution. Alias resolution is revocation-aware: candidate policy objects discovered for a canonical alias are filtered by excluding candidates determined to be revoked under the applicable trust model. Revocation determinations may be recorded in the append-only audit record, including identifiers or fingerprints of the relied-upon revocation artifacts and the resulting denial outcomes.

Anti-Rollback Constraints

Anti-rollback constraints prevent reliance on an older authority instance when a newer authorized successor exists, or when a policy-defined minimum acceptable version is required. The disclosure describes several expressions of this constraint, used individually or in combination: monotonic version indicators associated with canonical aliases, verifiable continuity chains between successive authority instances, hash commitments to a latest-known-good authority instance, and policy-defined minimum acceptable version constraints. The governance gate rejects a resolved policy object whose version indicator is less than the minimum for the canonical alias, where that minimum may be recorded as governance-relevant memory in the embedded memory of the agent object or in an append-only audit anchoring record.

Two further requirements harden the constraint. Successor policy objects may be required to include a verifiable continuity reference to a prior authoritative instance, and a candidate lacking a required continuity reference is treated as non-authoritative even if it is authentic. Separately, a latest-known-good fingerprint stored in embedded memory or in an append-only audit record may establish a checkpoint constraint against which subsequent candidates are evaluated, preventing stale-policy downgrade attempts. An anti-rollback failure may be recorded as a freshness failure that includes the rejected version indicator, the rejected continuity reference, and the applicable minimum or checkpoint constraint.

Filtering Before Verification

The three controls are applied as candidate-set filtering during alias resolution, and may be rechecked immediately prior to authorization. Alias resolution yields a candidate set of policy objects for a canonical alias, and that candidate set is filtered based on the freshness constraints, validity-window satisfaction, revocation state, and anti-rollback monotonicity, to produce a selected set of policy objects eligible for cryptographic verification and authorization evaluation. The ordering matters: filtering precedes verification. This permits deterministic denial in cases where candidates are stale or revoked without relying on cryptographic verification of ineligible candidates, and it reduces the risk of authorization based on cached but outdated authority.

Concretely, in the disclosed control flow the governance gate extracts the canonical policy aliases required for the proposed action and issues a resolution request to a Dynamic Alias System. The request carries an evaluation context comprising at least a time basis, a trust-zone indicator, and a substrate-class indicator, which the Dynamic Alias System uses to evaluate validity-window satisfaction, revocation state, and anti-rollback monotonicity. Candidate discovery obtains the candidate set, a validity-window filter excludes candidates whose notBefore or notAfter semantics do not encompass the evaluation time, a revocation check resolves revocation artifacts and excludes revoked candidates, and an anti-rollback evaluation compares candidate version indicators to a monotonicity constraint and validates required continuity references. The Dynamic Alias System outputs the selected policy objects that satisfy all three controls.

Deterministic Permit or Deny

The selected policy objects are submitted to a verification module, which produces verification results indicating authenticity and integrity under the applicable trust model. The governance gate then performs an applicability evaluation that includes re-evaluation of validity-window satisfaction and freshness constraints at the time of authorization, and evaluates a latest-known-good checkpoint stored in embedded memory or in an append-only audit record, denying candidates that violate the checkpoint constraint. If any validity-window, revocation, or anti-rollback control fails for a required canonical policy alias, the gate produces a denial outcome and prevents instantiation of an execution context. Only when all required aliases satisfy the validity-window controls, are not revoked, satisfy anti-rollback constraints, and are verified authentic does the gate produce an authorization permit enabling the execution substrate to instantiate an execution context.

A denial is a structured result rather than an opaque failure. In one embodiment the structured denial result comprises at least an identifier of the proposed action or action class, identifiers or fingerprints of the evaluated policy objects and associated revocation artifacts, and a failure basis indicator identifying the freshness failure type, namely validity-window failure, revocation failure, or anti-rollback failure. The structured denial result may be stored in the memory field of the agent object as governance-relevant memory and recorded in an append-only audit record, and it may serve as an objective input to subsequent authorization evaluations such as eligibility gating, quarantine state, or revalidation requirements, without requiring model alignment scoring or outcome prediction.

Audit Recording and Checkpoints

The control flow includes an append-only audit ledger that records freshness-relevant events and, in embodiments, a freshness failure record and a latest-known-good checkpoint record corresponding to the authorization decision. The ledger may record resolution results, candidate filtering outcomes, validity-window failures, revocation determinations, anti-rollback determinations, and the resulting authorization decisions including denial outcomes. A freshness failure record may include an alias identifier, a candidate policy fingerprint, the evaluation time basis, and a failure type indicating validity-window, revocation, or anti-rollback failure.

The checkpoint record closes the anti-rollback loop. After a successful authorization permit is produced, the audit ledger records a latest-known-good checkpoint associated with the canonical policy alias. That recorded checkpoint enables subsequent monotonicity enforcement and detection of stale-policy downgrade attempts, because a later candidate that regresses below the recorded checkpoint can be rejected on that basis. Freshness enforcement therefore leaves verifiable evidence both of the controls applied and of the resulting non-execution outcomes.

Disclosure Scope

The freshness, revocation, and anti-rollback controls described here, comprising validity-window semantics expressed as notBefore and notAfter boundaries, revocation as negative authority expressed through revocation anchors, lists, or epochs, anti-rollback constraints expressed through monotonic version indicators, verifiable continuity references, and latest-known-good checkpoint fingerprints, the application of these controls as candidate-set filtering during alias resolution prior to cryptographic verification, the deterministic permit-or-deny outcome of the governance gate, the structured denial result and its failure-basis indicator, and the append-only recording of freshness-relevant events and latest-known-good checkpoint records, are disclosed in U.S. Application No. 19/561,229 in the section on freshness, revocation, and anti-rollback controls and the corresponding control flow of FIGS. 13A and 13B. This article describes that disclosed mechanism. The scope extends to evaluation across heterogeneous and intermittently connected substrates, provided the freshness controls are applied as objective preconditions to instantiation of an execution context.