Abstract

Abstract

Large-scale platforms separate the moment an action is approved from the moment it takes effect. A policy engine returns “allow”, and a downstream service commits the change later. An identity provider issues a token, and a resource service acts on it minutes afterwards. An AI agent is authorised for a task, and its tool calls run after planning. A payment is approved, queued and submitted to a rail in a later batch. A deployment passes review, and a controller applies it later. During that interval, policies, revocations, consents, ownership, risk state and attestation reference values keep changing.

The result is a stale permit: an authorisation that is still correctly signed, unexpired and held by the right party, but was granted under rules that no longer apply. Token expiry, replay protection, proof-of-possession and event-driven session re-evaluation narrow this window, but none of them guarantees that the exact policy and state behind a decision is still current at the instant of commit.

This disclosure binds each concrete action to the Decision Basis it was evaluated under. The basis consists of content digests of the policy, role or route mapping and attestation reference set, together with revocation, resource-version, authority-set and policy generations. Each is identified by content, never by a mutable name, path or URL. The action stays non-effective until the enforcement point that first makes it real performs a continuity check inside the same atomic step as the commit. The check passes in one of two ways:

  • the basis is unchanged, or
  • a signed, scoped compatibility statement from the policy authority covers the new revision.

In addition, revocation, resource version, authorised use and the execution path must all still be current. The enforcement point never infers that two policy versions are “equivalent”. It re-evaluates or rejects instead. Unknown state is non-authorising unless an explicitly authorised staleness bound applies. Generations are anchored in rollback-resistant state, so restored snapshots or old policy files cannot be replayed as current.

The disclosure maps this invariant onto the building blocks used across major cloud, identity, infrastructure, payment and AI platforms:

  • identity platforms that re-evaluate sessions on critical events;
  • policy-as-code authorisation services with versioned policy stores;
  • cloud resource hierarchies with allow and deny policies;
  • container admission controllers and GitOps pipelines;
  • API gateways and service-mesh sidecars with decision caches;
  • managed databases and ledgers using conditional writes or compare-and-swap;
  • payment orchestration with sanctions and limit re-screening;
  • AI agent tool dispatch and tool-protocol servers;
  • confidential-computing enclaves and HSM or TPM monotonic counters;
  • DPUs and SmartNICs enforcing inline;
  • GPU and accelerator admission based on attestation;
  • offline edge devices with bounded staleness;
  • multi-region systems using consensus-backed policy heads and fencing tokens.

For each pattern, the disclosure states where the basis comes from, where the enforcement point sits, how atomicity is achieved and how failures are handled. It also includes a formal model and safety invariant, a bounded prevention argument, a 20-step method, reference pseudocode for concurrent updates and crash recovery, and illustrative wire objects. Five worked examples cover a payment limit cut, withdrawn agent consent, a tightened deployment policy, a withdrawn attestation reference value and a benign policy edit. An attack analysis covers policy rollback, mapping substitution, reference-state rollback, stale-permit replay, split-brain authority, snapshot rollback, commit races and alternate paths. Twenty-two conformance test classes and an examiner search index complete the document.

The platform patterns described are generic industry architectures, not descriptions of any company’s product or internal design, and no deficiency, non-conformance or infringement is alleged. This industry-relevance material is AI-generated and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion.

This technical disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382). That application claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The continuity model is as published in Internet-Draft draft-das-state-policy-continuity-finality-00 on 16 September 2026. Related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration.

Keywords

stale permit; stale authorization; commit-time authorization; policy continuity; TOCTOU; policy generation; revocation generation; fencing token; compare-and-swap; conditional write; optimistic concurrency; content-addressed policy; policy digest; continuous access evaluation; policy as code; fine-grained authorization; cloud IAM deny policy; admission controller; GitOps; service mesh; external authorization; decision cache invalidation; AI agent tool call authorization; payment sanctions re-screening; confidential computing; TEE; HSM monotonic counter; GPU attestation; DPU; anti-rollback; execution finality.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS