# kaal:position:2026-08-26-023

**Affirmed position.** Revocation is complete only when enforcement has changed.

Spencer, Smalley, Loscocco, Hibler, Andersen, and Lepreau developed the Flask security architecture around that distinction. The architecture separates a policy decision from a system-wide policy change. Its synchronization protocol has three steps. The security server notifies every object manager that may hold the affected policy. Each object manager updates its internal state. Each manager then reports that the change is complete.

The final report supplies the operative completion condition. The security server cannot treat the policy change as complete until all affected object managers have reported completion. Sequence numbers bind policy decisions and change requests when their messages interleave. The architecture therefore addresses both propagation and demonstration. A revocation record states that authority was withdrawn. The completion reports establish whether the relevant enforcement components changed state under the same sequenced request.

The mechanism also reaches beyond future access checks. Permissions may migrate into cached decisions, open file descriptions, page tables, active connections, and operations already in progress. Removing a permission from the central policy does not remove those migrated permissions. Flask accordingly requires each affected manager to update its cache and address permissions that have already entered local execution state.

The evidence remains limited. The article reports a 1999 operating system architecture and prototype, not a sovereign agent runtime. Complete callbacks for migrated permissions were implemented only in the Flask microkernel. The file server did not yet interrupt operations in progress. Atomic policy change across the remaining object managers was unfinished, and coordination among distributed security servers remained future work.

The source does not prove that every component in a modern agent system will honor withdrawal. It establishes a narrower design criterion. A system should identify every affected enforcement manager, bind each acknowledgement to the same sequenced change, and refuse to declare completion while any required acknowledgement is absent. Without that evidence, withdrawal remains an instruction in transit rather than a completed policy change.

**Status.** affirmed  **Published.** 2026-08-26

**Holds when.**

- The response is limited to the exact full-text propositions and the one mapped Kaal claim.
- External evidence level: peer-reviewed conference paper with complete official proceedings full text and prototype architecture.
- Mapping review tier: independent substantive scholarly-growth qualification.
- The source reports a 1999 operating system security architecture and prototype rather than a sovereign agent runtime.
- Complete callbacks for revoking migrated permissions were implemented only in the Flask microkernel.
- The file server did not yet interrupt operations already in progress.
- Atomic policy change across object managers other than the microkernel remained incomplete.
- Coordination among distributed security servers remained future work.
- The article supplies architectural and prototype evidence rather than adversarial field evidence that every affected component always acknowledges correctly.

**Current debate.** The Flask Security Architecture: System Support for Diverse Security Policies: https://www.usenix.org/conference/8th-usenix-security-symposium/flask-security-architecture-system-support-diverse-security

**Extends.** kaal:claim:7314479-023: https://wulfkaal.github.io/claims/7314479-023

**Scholarly basis.** Wulf A. Kaal, Institutional Requirements for Sovereign Local Agent Runtimes (2026). SSRN: https://ssrn.com/abstract=7314479

**Source PDF sha256.** `debace24a155ae924a155b1fafe98856d98cf83689feff2f87a32f1c06171ce6`

**Evidence level.** peer-reviewed conference paper with complete official proceedings full text and prototype architecture

**Mapping review tier.** independent substantive scholarly-growth qualification

**Mapping confidence.** 0.99  **Mapping ambiguous.** false

**Topics.** institutional-design, governance-design, authorization, revocation, access-control, distributed-systems, enforcement-boundary, auditability

**Provenance.** Affirmed in kaal-review:2026-08-26:scholarly-growth-7314479-023-reviewed-v1 at https://wulfkaal.github.io/positions/by-claim/7314479-023.html.

**Record type.** This is a dated commentary position that extends a scholarly corpus claim. It is not a verbatim claim extracted from the paper.

**Canonical form.** This markdown file is the canonical hashed representation of the position.