A-C

Policy - Abstraction

Summary

A to C: Policy definitions for read, transform, and reveal rules plus clearance tiers consumed by abstraction output governance.

C to A: Abstraction tier compliance gaps, seal-break events, and overexposure patterns surfaced back to Pillar A for policy refinement and tier model evolution.

Commons DraftEditorial research

Standards and Specifications

OAuth 2.0 Token Exchange
SPIFFE/SPIRE
OPA/Rego

This interface ensures that what an AI system is allowed to reveal is governed as explicitly as what it is allowed to read, by connecting clearance tiers and output redaction rules in Pillar C to authoritative policy definitions in Pillar A. Abstraction components depend on Pillar A to express which identities may see which classes of content, at what granularity, and under which contextual conditions such as purpose or channel. In return, Pillar C must report when sealing or redaction logic is bypassed, when outputs routinely downgrade classification, or when users request content beyond their clearance so that those behaviors can be addressed as policy or tier-model issues rather than ad hoc exceptions. With a mature A-C interface, disclosure risk is governed through explicit tiers and schemas instead of being left to prompt engineering alone.

Variants

IGA-managed role and clearance attributes

Clearance tiers and output entitlements are modeled as attributes and roles in the IGA system; abstraction services or attached policy engines query these attributes at output generation time to decide which fields, sections, or explanation depth to include.

Aligns output governance with enterprise access governance but requires IGA to support clearance as a first-class, lifecycle-managed attribute and for abstraction components to consume that data via standardized identity and attribute schemas.

Purview or catalog-driven sensitivity labels

Abstraction components inspect data lineage and Microsoft Purview or similar catalog labels to infer the sensitivity of input sources and then apply Pillar-A-defined rules for what each recipient clearance tier may see.

Tightly integrates with ecosystems that already label content, reducing duplication of classification logic, but depends on consistent labeling practices and cross-system understanding of label semantics between the catalog, policy engine, and abstraction layer.

Policy engine with identity and context-aware rules

An external policy engine evaluates rules that combine recipient identity, purpose, channel, and data classification to determine whether to redact, summarize, or fully reveal each portion of the AI output.

Offers high flexibility and portability across abstraction frameworks but requires a shared vocabulary for classifications, tiers, and purposes, as well as reliable propagation of identity and context signals into the policy decision point.

Structured output schema with field-level access control

The abstraction layer emits structured responses where each field is mapped to a required clearance tier; before serialization or rendering, Pillar C drops or redacts fields the caller is not entitled to see under Pillar A rules.

Simplifies enforcement and auditing for structured responses but is harder to apply to free-form text; requires schema governance so that new fields are consistently classified and enforcement behavior remains predictable across services.

Tiered explanation and rationale control

Abstraction logic applies Pillar-A policies to control how much reasoning, provenance detail, or model rationale is exposed at each clearance tier, limiting sensitive operational or security details to higher tiers.

Extends abstraction beyond data redaction into explanation control, reducing leakage of sensitive methods or internal topology; depends on standardized tier definitions shared between Pillar A policies and Pillar C implementation teams.

Participating Vendors

Cerbos

Cerbos is a lightweight, Git-native policy engine operating in Pillar A as a callable authorization service, with particularly strong fit for low-latency Pillar B RAG pipeline pre-retrieval checks and Pillar C output filtering. Cerbos emits authorization decision logs consumed by Pillar D SIEM for audit trails.

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.