A-B

Policy - Retrieval

Summary

A to B: Entitlement definitions and runtime policy decisions consumed by retrieval enforcement points.

B to A: Retrieval coverage gaps, prompt-injection-induced bypasses, and ungoverned access paths identified during Pillar B operations surfaced back to Pillar A for policy correction and control-plane hardening.

Commons DraftEditorial research

Standards and Specifications

OAuth 2.0 RAR
OpenID Connect
OPA/Rego

This interface binds identity-aware authorization policy to every retrieval hop that an AI system executes, ensuring that corpus selection and document filters are constrained by governed entitlements rather than by prompt content alone. Retrieval services depend on Pillar A to expose a consistently evaluable authorization surface—via tokens, APIs, or sidecars—so that each query can be filtered to the caller’s effective access rights at the time of use. In the opposite direction, retrieval logs and detected bypass patterns must flow back into Pillar A so that policy authors can close gaps such as over-broad scopes, misaligned group mappings, or missing constraints on cross-tenant sources, reinforcing Pillar A’s role as the shared policy authority. When this loop is implemented well, AI retrieval becomes an extension of enterprise authorization rather than a parallel, less-governed channel to data.

Variants

IGA API call at request time

The retrieval enforcement point calls the IGA or identity governance platform synchronously on each retrieval to resolve the current entitlements and access scopes for the requesting identity, then constructs the query filter from that response.

Maximizes alignment between retrieval behavior and authoritative entitlements but introduces latency and dependency on IGA availability; requires stable, documented IGA APIs and shared identifiers between IGA accounts and retrieval principals.

JWT / token claims

The upstream IdP issues a token that includes roles, groups, and sensitivity clearances as claims; the retrieval layer parses the token and maps claims to filter clauses and allowed corpus sets for each request.

Reduces runtime coupling to IGA by relying on the IdP as policy distributor, but creates staleness risk if token lifetimes or claim-refresh logic are not tuned to entitlement lifecycle speed; requires agreement on claim schemas and audience across IdP, IGA, and retrieval systems.

Policy engine sidecar (OPA, Cerbos, Cedar)

The retrieval service calls a local or network-near policy engine with identity, resource, and environment attributes; the engine evaluates authorization rules and returns allow/deny plus filter parameters used to constrain the retrieval query.

Enables low-latency, portable authorization decisions across heterogeneous retrieval backends, provided that policy bundles are synchronized from Pillar A and resource attributes are modeled consistently; cache invalidation and bundle distribution pipelines become critical interoperability concerns.

Pre-computed metadata filter

At session establishment, Pillar A computes an entitlement-derived filter expression or set of corpus IDs for the identity and hands it to the retrieval client or gateway, which reuses this filter on subsequent retrieval calls.

Simplifies enforcement and reduces per-call overhead but risks over-permissioned access when entitlements change mid-session; requires explicit rules for session duration, mid-session refresh, and revocation handling to stay aligned with Pillar A governance.

SPIFFE SVID + mTLS

Retrieval clients authenticate using SPIFFE-issued identities over mutual TLS; the retrieval layer and attached policy engine treat the SPIFFE ID as the principal and evaluate authorization and scope rules for each retrieval based on that identity and associated attributes.

Supports secure, workload-centric identity and retrieval across multi-cloud and mesh environments, removing static secrets but requiring SPIFFE/SPIRE infrastructure and consistent SPIFFE ID mapping to enterprise identities and policies in Pillar A.

MCP Enterprise Authorization

AI clients call retrieval-capable MCP servers whose methods are fronted by enterprise authorization; OAuth-scoped tokens, claims, or sidecar policy checks ensure that each MCP tool invocation only exposes data consistent with Pillar A policy for the requesting identity.

Turns MCP into a governed retrieval surface rather than an open tool channel, but demands that MCP servers adopt a standard enterprise authorization pattern and propagate identity context and policy decisions to underlying retrieval systems.

Participating Vendors

Okta

Okta serves as an enterprise IdP in Pillar A, issuing verifiable identity tokens consumed by Pillar B and C enforcement contexts. Okta's Cross-App Access (XAA) extension brings MCP server authorization under enterprise identity governance, enabling centralized policy enforcement for AI tool access in Pillar B.

Azure AI Search

Open Policy Agent

OPA (Open Policy Agent) is a CNCF policy-as-code engine serving as a core component of Pillar A's shared policy authority, called at runtime by Pillar B retrieval filters, Pillar C output orchestration, and Pillar D monitoring workflows. OPA evaluates identity context and policy rules to produce authorization decisions across AI pipelines, microservices, and API gateways.