Oversight Layer (PDP + PEP for Agentic AI)

The oversight layer is this wiki’s architectural primary term for the system that monitors, evaluates, and intervenes on the behavior of AI agents in production. It is a layer (not a single component), built from Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs), fed by Policy Information Points (PIPs) and managed by Policy Administration Points (PAPs) — the four-role decomposition originating in the XACML policy-language lineage (now dormant) and currently codified in NIST SP 800-162 §2.2 (NIST’s Guide to Attribute Based Access Control), the wiki’s preferred living-standard citation for the role vocabulary.

Other terms describe the same role from different vantage points — see §Cross-walk below. The wiki uses oversight layer in architectural and practitioner-facing pages, and guardian agent in procurement-language and comparison pages.

Why this terminology

The oversight-layer framing has three properties the wiki cares about:

  1. Architecturally precise. PDP / PEP / PIP / PAP are well-defined roles with stable semantics from XACML and zero-trust literature. They describe what each component does, not what it’s branded.
  2. Implementation-agnostic. An oversight layer can be deterministic (Cedar policy, OPA rules), AI-based (LLM-as-a-judge), or hybrid. The terminology doesn’t prescribe.
  3. Layer-shaped. The oversight role doesn’t live in a single product; it’s distributed across identity, control, runtime, egress, data, and observability planes. “Layer” captures that distribution; “agent” implies a single actor.

The trade-off: less procurement-language gravity than Guardian Agent. The wiki keeps both terms, lead by audience.

The four roles (XACML / zero-trust lineage)

flowchart LR
  Agent([AI agent action])
  PEP[PEP<br/>Policy Enforcement Point]
  PDP[PDP<br/>Policy Decision Point]
  PIP[PIP<br/>Policy Information Point]
  PAP[PAP<br/>Policy Administration Point]
  
  Agent -->|"intent + context"| PEP
  PEP -->|"is this allowed?"| PDP
  PDP <--> PIP
  PAP -->|policy lifecycle| PDP
  PDP -->|"allow / deny / modify"| PEP
  PEP -->|"final action"| Tool[Tool / API / Output]
RoleResponsibilityExamples in this wiki
PEP — Policy Enforcement PointSits in the action path; intercepts every consequential agent action; applies the PDP’s decisionLlamaFirewall (PromptGuard 2 + AlignmentCheck + CodeShield); AgentGateway; NVIDIA NeMo Guardrails; Microsoft Prompt Shields; before_tool / before_model lifecycle hooks
PDP — Policy Decision PointEvaluates policy against context; produces an allow/deny/modify decisionCedar (AWS); OPA/Rego; CSA ATF promotion-gate logic; capability-token / Warrant issuance
PIP — Policy Information PointProvides context the PDP needs (identity, posture, risk score, threat intel, behavioral baselines)AI Agent Catalog; AI-SPM; agent behavioral monitoring; OpenTelemetry gen_ai.* spans; Agent Observability telemetry
PAP — Policy Administration PointManages the policy lifecycle (authoring, versioning, deployment, retirement)Cedar policy repos in git; Kubernetes ConfigMaps; Microsoft Purview policies; CI/CD pipelines that test and deploy policy

How this maps to the wiki’s six planes

The Agentic AI Security Reference Architecture (2026) decomposes the oversight layer into six planes. Mapping:

PlaneXACML roleWhat lives here
IdentityPIP (subject identity)SPIFFE/SPIRE; Okta for AI Agents; Microsoft Entra Agent ID; credential proxy
ControlPDP + PAPCedar/OPA evaluation; capability-token issuance; least-agency tier engine
RuntimePEP (in-process)Lifecycle hooks; LlamaFirewall; NeMo Guardrails; sandbox
EgressPEP (broker)AgentGateway; MCP/A2A proxy; tool annotation enforcement
DataPIP (data context) + PEP (data egress)RAG provenance; AI-BOM; cognitive file integrity; memory-poisoning detection
ObservabilityPIP (signals to PDP)OTel gen_ai.*; agent behavioral monitoring; AI-SPM; SIEM

PDP is concentrated in the Control plane. PEPs are distributed across Runtime / Egress / Data. PIPs span Identity / Data / Observability. PAP is cross-cutting (policy lifecycle).

Mapping to Sentinels and Operatives

Sentinels and Operatives is Gartner’s runtime decomposition; it maps cleanly onto PIP / PDP+PEP:

Gartner termXACML role
SentinelsPIPs (provide context, posture, situational awareness)
OperativesPDP + PEP (decide and enforce)

Sentinels feed Operatives. PIPs feed PDPs. Same shape, different vocabulary.

Cross-walk

The same role goes by many names. Use the term that fits your audience.

TermSourceWhat it capturesWhen to use it
Oversight LayerThis wiki (architectural)The layer-shaped role across PDPs / PEPs / PIPs / PAPsArchitectural and practitioner-facing pages
PDP + PEPXACML, zero-trustThe decision/enforcement role splitImplementation discussions; precise component-level work
Guardian AgentGartner (Feb 2026 Market Guide)Holistic oversight: visibility + assurance + enforcement, evolving toward AI-driven supervisionProcurement, RFP structure, board-level reporting
Reference MonitorLampson (1971); classical security”Always invoked, tamper-proof, verifiable” — formal-methods anchorThreat-model writeups; formal proofs of containment
Supervisory AgentMulti-agent systems literatureThe supervising role in a multi-agent hierarchyAcademic / research contexts
AI Firewall / AI GuardrailLlamaFirewall (Meta), Lakera, Lasso, NeMoInput/output filtering at runtime — narrower than the full oversight layerComponent-level discussions of input filtering
Agent Gateway / MCP GatewayAgentGateway (Linux Foundation); Solo Enterprise; OperantNetwork/protocol-layer broker for tool calls + MCP — egress-plane onlyNetwork/protocol-layer specifics
Promotion GateCSA Agentic Trust Framework (Feb 2026)Staged authorization checkpoints for autonomy promotionAutonomy-tier governance
Compartmentalized LLM / CaMeLGoogle DeepMind researchPrivileged-LLM-coordinates-Quarantined-LLM split — a containment patternResearch-stage architectural discussions
AI Watchdog / AI Auditor / AI Steward / AI CustodianInformal industry usageVarious — usually narrowerInformal contexts; not standardized
AI Oversight / Human OversightNIST AI RMF; EU AI Act Art. 14The umbrella concept; doesn’t specify implementationRegulatory / compliance writeups

Why so many names

The category is forming in real time across multiple traditions: classical security (Reference Monitor), zero-trust (PDP/PEP), multi-agent research (Supervisory Agent), regulatory bodies (Oversight), and commercial analysis (Guardian Agent). Each carries the assumptions of its tradition. The wiki picks Oversight Layer + PDP/PEP for architectural rigor and Guardian Agent for procurement gravity, with the rest cross-referenced from this page.

Why not just “Reference Monitor”?

Reference Monitor is the most architecturally pristine option — Lampson 1971, formal-methods literature, well-understood security semantics. Three reasons the wiki doesn’t lead with it:

  1. Pace of innovation. AI security is evolving faster than 50-year-old security vocabulary can keep up. The agentic-AI threat surface (prompt injection, lethal trifecta, MCP supply chain, tool-abuse chains) doesn’t map cleanly onto the system-call mediation Reference Monitor was designed for.
  2. Reference Monitor is a property, not a layer. “Always invoked, tamper-proof, verifiable” is a property the oversight layer should satisfy — not the layer itself. Conflating the two loses the layered-implementation reality.
  3. Practitioners don’t use it. AI security teams in 2026 talk about gateways, guardrails, posture management, agent identity — not about reference monitors. Aligning vocabulary with practice is more useful than aligning with formal lineage.

The wiki keeps Reference Monitor as a property that the oversight layer should satisfy (see Agent Observability §1) and as one of the synonyms in the cross-walk above.

Why not just “Guardian Agent”?

The full critique is in Guardian Agent §Why “Guardian Agent”. Headlines:

  • “Agent” is doing double duty (the supervisor and the supervised are both agents)
  • Anthropomorphic — implies a single autonomous actor; reality is a layer of cooperating components
  • Conflates AI implementation with role — a deterministic policy engine doing the same job isn’t a “guardian agent” in Gartner’s framing, even if functionally equivalent
  • Gartner-coined; vocabulary lock-in risk if Gartner pivots

These concerns don’t make Guardian Agent wrong — they make it the wrong term to lead architectural discussion with. It remains the right term for procurement, RFPs, and board reports.

Implications for the CMM

The Agentic AI Security CMM 2026 domains map cleanly onto oversight-layer roles:

CMM DomainXACML role
D1 Governance & AccountabilityPAP (policy lifecycle, ownership)
D2 Identity & AuthorizationPIP (subject) + part of PDP (authz decisions)
D3 Control & Least-AgencyPDP + PAP (autonomy-tier policy)
D4 Runtime & GuardrailsPEP (in-process)
D5 Egress & NetworkPEP (broker)
D6 Data, Memory & RAGPIP (data context) + PEP (data egress)
D7 Observability & DetectionPIP (signals to PDP)
D8 Supply Chain & AI-BOMPAP (policy provenance) + PIP (BOM as context)
D9 Operations & Human FactorsCross-cutting

This mapping is useful for CMM evidence: an L3+ claim on D4 should specify which PEPs are deployed and how they consume PDP decisions. An L3+ claim on D7 should specify which PIPs are emitting signals and what PDPs consume them.

See Also