Universal Entity Lifecycle Governance Framework (UELGF)

Research Question

What policy architecture, covering Policy Administration Point (PAP), Policy Decision Point (PDP), Policy Enforcement Point (PEP), and Policy Information Point (PIP), and what 8-layer organisational context model should the UELGF specify to provide architecturally enforced policy independence, a machine-checkable scope boundary mechanism replacing intent-based reasoning, and a kill switch operable at single-entity, entity-class, and entity-type levels?

Findings

Executive Summary

• UELGF should implement policy independence through one canonical PAP that publishes signed policy revisions to stateless PDPs, with every PEP failing closed when freshness cannot be proven, because standards and current policy-engine practice support separated roles and bounded revision fanout but do not support safe local override.

• The 8-layer context model should be encoded as an ordered constraint stack in which Layers 1 to 7 are organisation-wide constants and Layer 8 is a typed per-entity scope object, because deterministic ABAC and XACML-style evaluation requires structured attributes and precedence, not intent interpretation.

• The kill switch should suspend licence-to-operate first and then fan out revocation across tokens, workload credentials, pending work, and dependencies, because each revocation mechanism covers a different delay surface and none is sufficient on its own for high-consequence stop authority.

• A new Layer 1 rule should trigger automatic portfolio re-evaluation without entity-owner action, and any entity whose new licence decision cannot be recomputed inside the freshness window should move to suspended_pending_revalidation until the architecture can prove compliance under the new revision.

Key Findings

1. High confidence: The component split should follow the standards model closely enough that the PAP authors and publishes policy, the PDP evaluates policy, the PEP enforces returned decisions and obligations, and the PIP supplies entity and runtime attributes, because both XACML and Zero Trust Architecture rely on that separation to prevent policy logic from collapsing into enforcement code.
2. High confidence: Policy independence is best specified as signed revision publication plus bounded-distribution freshness guarantees rather than literal global synchrony, because distributed PDP estates can converge quickly but not instantaneously, and the safe response to missed freshness is automatic suspension rather than silent continued authorization.
3. High confidence: The 8-layer model should be encoded as an ordered constraint stack where lower layers may specialize but never weaken higher layers, because otherwise entity scope or local procedure could override regulation, risk appetite, or enterprise standards and destroy machine-checkable policy coherence.
4. High confidence: The machine-checkable scope boundary must be a typed object covering actions, resources, data domains, connectors, side effects, approval requirements, and numeric limits, because neither workload identity nor coarse string scopes can tell the PDP whether a specific requested action lies inside the registered licence envelope.
5. High confidence: Scope violations and policy denials must be recorded as different decision classes, because an out-of-scope request signals an entity-registration or misuse defect while an in-scope denial signals a valid organisational prohibition being enforced as intended.
6. Medium confidence: The kill switch should execute as a multi-channel stop protocol with single-entity suspension in 60 seconds, class suspension in 180 seconds, and type suspension in 300 seconds, because deny-first licence publication is fast while token, certificate, queue, and dependency propagation complete on a slightly slower control path.
7. High confidence: A Layer 1 regulatory update should trigger automatic re-evaluation of all active licensed entities from the PIP registry without owner action, and any entity whose new decision cannot be recomputed inside the freshness window should move to suspended pending revalidation until the architecture can prove compliance under the new revision.
8. Medium confidence: The architecture should treat CIA tier as a hardening selector over one shared policy stack rather than as a separate governance regime, because adjacent repository work shows that layered enforcement, control-plane composition, and proportional PAP logic are strongest when they share one canonical source of truth.

Assumptions

• Assumption: The target estate can revoke connector sessions or stop renewing workload credentials quickly enough that queue drain and notification become the dominant residual delay. Justification: the standards prove the revocation patterns exist, but they do not prove one universal enterprise propagation speed.
• Assumption: The target estate can centralize decision evidence by entity identifier and policy revision. Justification: the sources prove rich decision metadata can be emitted, but not that every platform already writes into one durable evidence store.

Analysis

• The strongest architecture anchors were XACML and Zero Trust Architecture because both define clean role boundaries and support the claim that policy logic should not live inside every enforcement surface.

• The propagation conclusion weighs OPA, Verified Permissions, and Azure Policy together because they expose the real design space: rapid signed fanout, managed logical propagation inside a policy store, and slower estate-wide reassessment loops.

• The scope-boundary conclusion rejects both plain-language intent and identity-only licensing because the evidence shows that schema-validated request semantics and workload identity solve different halves of the determinism problem.

• The kill-switch timing remains medium confidence because the revocation mechanisms are well supported, but the exact second-count service-level objectives are an engineering synthesis rather than a quoted external requirement.

Risks, Gaps, and Uncertainties

• OPA bundle activation is eventually consistent, so any UELGF wording that promises literal globally simultaneous activation would overstate what the source supports.
• Azure Policy demonstrates useful reassessment triggers, but its slower compliance cycles make it an analogue for broad correction rather than for sub-minute suspension.
• The proposed kill-switch timings assume short-lived workload credentials and accessible renewal controls.
• The typed scope-object design assumes the enterprise can model actions, resources, connectors, and side-effect classes in a stable schema and keep that schema current.

Open Questions

• What compatibility rules should allow a policy revision to reuse a prior scope object without forcing entity re-registration?
• Which connector classes in the target estate support immediate session revocation, which support only non-renewal, and which require compensating PEP-side hard blocks?
• How should high-confidence anomaly signals from the PIP influence the scope-violation path without producing excessive false suspensions?

sources

• [x] OASIS XACML 3.0 Core Specification — - canonical PAP/PDP/PEP/PIP architecture definition
• [x] Open Policy Agent philosophy — - policy decoupling and runtime externalization
• [x] Open Policy Agent bundle management — - bundle propagation, long polling, persistence, and immediate activation after load
• [x] Open Policy Agent decision logs — - decision traceability and bundle revision capture
• [x] Cedar policy language reference — - externalized authorization model and dynamic policy evaluation
• [x] Cedar validation against schema — - schema validation and default deny on invalid or non-matching policy
• [x] Amazon Verified Permissions — - managed PDP pattern
• [x] Amazon Verified Permissions terminology — - determining policies, policy store scope, and enforcement boundary
• [x] Amazon Verified Permissions policy templates — - template-linked propagation semantics
• [x] RFC 7009: OAuth 2.0 Token Revocation — - revocation endpoint semantics
• [x] RFC 6960: Online Certificate Status Protocol — - timely certificate-status checks
• [x] RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile — - certificate revocation list profile
• [x] NIST SP 800-162: Guide to Attribute Based Access Control — - attribute-based policy evaluation model
• [x] NIST SP 800-207: Zero Trust Architecture — - policy engine, policy administrator, policy enforcement point, and supporting-data analogue
• [x] Azure Policy overview — - central assignment, most-restrictive effects, and remediation model
• [x] Azure Policy evaluation triggers — - assignment and update timing
• [x] SPIFFE overview — - workload identity framing
• [x] SPIFFE concepts — - short-lived credentials, trust bundles, and automatic rotation
• [x] Adaptive policy authorisation and compliance — - adjacent completed item on dynamic authorization evidence
• [x] AI and low-code governance enforcement architecture — - adjacent completed item on layered enforcement placement
• [x] Policy coherence as machine-checkable prerequisite — - adjacent completed item on policy coherence prerequisite
• [x] AI agent control plane architecture in the enterprise — - adjacent completed item on composite control planes
• [x] PAP dynamic policy profiling and proportionality — - adjacent completed item on PAP-side topology derivation
• [x] PDP universal policy synchronisation integrity — - adjacent completed item on policy identity and re-synchronisation
• [x] PIP invariant anomaly detection — - adjacent completed item on PIP runtime signal design