Policy decision point

A policy decision point (PDP) is the architectural component that receives an access request, evaluates it against the active policy set, and returns a permit or deny decision. The term comes from the XACML reference architecture and NIST Special Publication 800-162, where it pairs with a policy enforcement point (PEP) that carries out the decision. In AI traffic, the PDP runs inside the enforcement layer and decides per request, using identity context, data classification, and per-route rules.

How the policy decision point fits in AI architectures

The PEP receives the inbound AI request, hands the decision inputs (identity claim, prompt payload metadata, route, classification verdict) to the PDP, and applies whatever the PDP returns. The PDP is policy-only: it reads the rules, evaluates the inputs, and returns pass or block, with reason codes recorded for audit. Separating the decision from the enforcement keeps policy logic independent of the request handler and makes the audit record reproducible against the same policy version.

In an identity-aware AI gateway, the PDP sees the verified subject (CISO, agent, service account), the route the request targets (chatbot, RAG retrieval, code-assist), and the data class the classifier returned for the prompt. Per-route and per-role policies live in the PDP. Per-decision audit records carry the PDP's reason code so a regulator can replay the decision later.

Related reading

  • AI Inline Enforcement Architecture: Where the Policy Decision Sits and What It Has To Commit

    AI inline enforcement runs the policy decision in the request path, before the model API call returns to the calling application. The architecture places a deterministic policy decision point between the application identity and the model endpoint and commits a per-decision audit record before the response forwards. This piece walks through the architectural components, the decision-time data shape, the failure modes the implementation has to handle, and the regulatory profile that the inline placement satisfies (EU AI Act Article 12, NIST AI agent identity and authorization Pillar 2 and Pillar 3, Fannie Mae LL-2026-04, DORA Article 6).

  • Identity-Aware AI Gateway Architecture: How Inline Enforcement Binds Decisions to Users and Agents

    An identity-aware AI gateway sits at the AI request boundary, attaches verified identity context to every model API call, evaluates per-route and per-role policies, and commits a per-decision audit record before the model response returns to the calling application. The architecture closes the post-authentication gap that most enterprise AI deployments have inherited from the credential-pooling pattern used by SDKs and proxy frameworks. This piece walks through the architectural building blocks, the call path, the audit primitives, and where the identity-aware gateway sits relative to existing IAM, API gateway, and DLP infrastructure.

← Back to glossary