Provenance is the traceable origin and history of a signal: where it came from, who asserted it, and whether it was altered or exposed in transit. Authorization decisions rely on this evidence because an encrypted channel alone does not establish the caller’s identity or the trustworthiness of supplied context. section 12.5.2
For internal service calls, mutual TLS authenticates both endpoints, often using SPIFFE IDs and SVIDs as workload identity material. A policy enforcement point can pass that authenticated identity to the policy decision point, which still evaluates whether the action is allowed. SaaS integrations, browsers, and bearer-token APIs may instead use signed tokens: signature verification establishes the issuer and detects tampering. section 12.5.2
Provenance also applies to signals aggregated from enterprise systems. A normalization layer records how each source is collected, how fresh it must be, and how its authenticity and provenance are verified before mapping attributes into a shared authorization schema. This gives policy authors consistent inputs without hiding responsibility for trustworthy source data. section 12.6.1 section 12.8
Figure 12.3 ACME’s normalization architecture. Before normalization (top), each PDP integrated directly with HR, Finance, authentication, and operational systems (e.g., PagerDuty, ticketing), each with custom schemas and caches. After normalization (bottom), a shared signal-normalization layer aggregates and standardizes those feeds, delivering consistent context to all PDPs. Device posture arrives separately as a signed token attached to each access request and is verified alongside the normalized data. This hybrid model keeps tokens minimal (identifier plus scopes) while preserving rich, consistent context for authorization decisions.
The architecture shows how normalized enterprise context and separately verified device-posture tokens combine to preserve provenance across authorization decisions. section 12.6.1
