Skip to main content

The five-layer continuous-authorization reference architecture

Objective​

Name the five layers of the continuous-authorization reference architecture, from SPIFFE identity assertion through unified audit, and explain what each contributes to one decision.

Concept​

Continuous authorization means every request is authorized at the moment it happens, against current policy and current context, not once at login. To do that reliably at scale, EnforceAuth describes a five-layer reference architecture. Each layer answers one question about a single request, and the decision flows through them in order.

1. Identity Assertion   -> who is calling?        (SPIFFE / SVID, mTLS)
2. Context (PIP)        -> what do we know now?    (Policy Information Point)
3. Policy Evaluation    -> allow or deny?          (OPA / Enterprise OPA = PDP)
4. Enforcement (PEPs)   -> apply it, per domain    (across the four domains)
5. Unified Audit        -> record + replay         (decision logs)

Text version: identity assertion proves who is calling; the context layer enriches the request with current facts; policy evaluation decides; enforcement applies the decision at the point of use; unified audit records every decision for review and replay.

Layer 1: Identity Assertion (SPIFFE)​

Before anything can be authorized, the caller has to be identified, and for workloads that is not a username. SPIFFE gives every workload a verifiable identity (an SVID) issued to the workload itself, typically presented over mutual TLS. A service, a job, or an AI agent proves it is who it claims to be with a short-lived cryptographic identity rather than a shared secret. This matters most for non-human callers, where there is no human to log in and the traditional identity story breaks down. Authentication proves the identity; it does not decide what the identity may do. That is the Authorization Gap the later layers close.

Layer 2: Context (PIP)​

Policy rarely decides on the request alone. A Policy Information Point (PIP) supplies the extra facts the policy needs at decision time: group membership, resource ownership, risk signals, time of day, a change-approval reference. The context layer is what makes authorization continuous rather than static, because these facts change between requests and the decision reflects the facts as they are now. In the lab, context.mtls_verified and context.approval_ref are context fields the policy reads.

Layer 3: Policy Evaluation (OPA / Enterprise OPA)​

This is the PDP, the Policy Decision Point. OPA or Enterprise OPA evaluates the policy against the request plus its context and returns a decision: allow or deny, and ideally a structured result with a reason and any obligations. This is the only layer that decides. Note the boundary you learned in Govern with Writ: Writ governs which policy this PDP runs and how it got there, but Writ is not the PDP and is not on the request path. The PDP decides at the edge; Writ governs from the center.

Layer 4: Enforcement across the four domains (PEPs)​

A decision is worthless unless something applies it. A Policy Enforcement Point (PEP) intercepts the request, asks the PDP, and enforces the answer: it lets the request proceed, blocks it, or carries out the decision's obligations. The AI Security Fabric places PEPs across all four domains: applications, infrastructure, data, and AI workloads. The same decision model drives an API gateway, a Kubernetes admission controller, a database proxy, and an AI-MCP gateway. The next lesson is about where these PEPs sit relative to the PDP.

Layer 5: Unified Audit (decision logs + replay)​

Every decision the PDP makes is logged, not just the denials. That decision log is what makes authorization auditable and, with Writ, replayable: you can re-run recorded inputs against a candidate policy before you promote it. This is the layer you studied in Decision Logs & Compliance Evidence, and it is where decision_logs.mask keeps sensitive input out of the log while preserving the evidence. A decision that is not recorded cannot be audited, so audit is a layer of the architecture, not an afterthought bolted on.

Mapping back to Define, Enforce, Audit​

The five layers map onto the operating model from the Associate track. Identity assertion, context, and policy evaluation are how a request is turned into a decision (the runtime side of Define, running the policy you authored). Enforcement is Enforce. Unified audit is Audit. The value of naming five layers rather than three is that it forces you to design identity and context deliberately, because a decision is only as trustworthy as the identity and context it was made from.

flowchart LR
  ID[1. Identity Assertion\nSPIFFE / mTLS] --> CTX[2. Context\nPIP]
  CTX --> PDP[3. Policy Evaluation\nOPA / Enterprise OPA]
  PDP --> PEP[4. Enforcement\nPEPs across 4 domains]
  PEP --> AUD[5. Unified Audit\ndecision logs + replay]
  W[Writ control plane] -. governs which policy .-> PDP

Text version of the diagram: a request flows left to right through identity assertion, context, policy evaluation, enforcement, and unified audit. Writ sits off to the side, governing which policy the PDP runs, not participating in the request.

Hands-on lab​

The course lab in ../lab/ is a single decision seen through these layers. Open ../lab/policy.rego and read the input shape and the header comment. Trace the layers in the input:

  • Identity Assertion: subject.spiffe_id and subject.trust_domain are the workload's SPIFFE identity; context.mtls_verified records that the mutual-TLS handshake succeeded.
  • Context: context.approval_ref and resource.classification are the facts the PIP supplies.
  • Policy Evaluation: the reason and allow rules are the PDP logic you will implement in Lesson 3's terms.
  • Enforcement / Audit: the obligations set is what a PEP must carry out, and the redaction obligation is a message to the audit layer.

You do not need to run anything yet; just map each input field to the layer it belongs to. You implement the decision rules after Lesson 3.

Check for understanding​

  1. Name the five layers in order, and say which one is the only layer that returns allow or deny.
  2. Why is Layer 1 described in terms of SPIFFE and mTLS rather than usernames and passwords? What kind of caller makes this necessary?
  3. A colleague says "authorization happens at login, then we cache it." Why does the continuous-authorization model reject that, and which layer is what makes a decision reflect facts as they are now?