A per-decision audit record is a single signed log entry produced for every AI request, capturing the identity that called, the data classification on the payload, the policy state at the moment of decision, and the pass-or-block outcome. EU AI Act Article 12 references this granularity as traceability and event logging. Fannie Mae Lender Letter LL-2026-04 (effective August 8, 2026) requires disclosure on demand. NIST AI RMF Pillar 3 calls the same primitive action lineage.
A per-role policy is a policy rule scoped to a user role or agent role inside the identity provider's directory. The role attaches to the verified subject the gateway receives in the identity context (OIDC claims, SAML assertion attributes, service-account scopes). A clinical user may submit PHI to a HIPAA-covered model endpoint; a marketing user may not. A scoped autonomous agent may write to the support-ticket system; a research agent may only read. Per-role policies translate the access-control vocabulary the security team already maintains in the directory into rules the enforcement layer applies per request.
A per-route policy is a policy rule scoped to a specific API route inside the AI request boundary. Each route (chatbot completion, RAG retrieval, code-assist generation, structured extraction) carries different data classes, different identity requirements, and different acceptable outcomes. A per-route policy attaches the rule set to the route key the gateway resolves at request time. The chatbot route may pass low-classification prompts through Claude; the RAG retrieval route may require PHI redaction before reaching the model; the code-assist route may block any prompt containing a secret pattern. The same enforcement layer applies all three from a single configuration surface.
PHI redaction is the runtime operation that identifies Protected Health Information inside an AI prompt or completion and removes, masks, or tokenizes the identified fields before the content reaches the LLM endpoint. PHI is the 18 HIPAA identifiers (names, dates, geographic subdivisions smaller than a state, phone, email, MRN, account numbers, full-face photos, and the other defined elements). Redaction sits at the AI gateway above the TLS termination point so the content can be read in cleartext, classified, and rewritten before it crosses the trust boundary into a vendor model.
PII detection is the classification step that identifies personally identifiable information inside a text payload before the payload crosses a trust boundary. Detection runs as a combination of regex patterns (SSN, credit card, phone, email), named-entity recognition models (person names, addresses), and content classifiers tuned for context (a nine-digit number near "SSN" is a stronger signal than a nine-digit invoice number). In an AI gateway, PII detection runs against the decrypted prompt body and feeds the classification verdict into the policy decision.
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.
The post-authentication gap is the architectural gap between "the user is authenticated" and "this specific AI request is permitted." A user who logs into the corporate SSO and reaches an internal chatbot has cleared the authentication gate. The system then has to decide whether this user, at this moment, in this role, with this prompt payload, is allowed to send this request to this model endpoint. Identity providers answer the first question (who are you). The post-authentication gap is the space where the second question (what may you do with this specific AI traffic) gets answered. Parminder Singh coined the term to name the architectural layer that sits between the IdP and the LLM.
Prompt injection is an attack where untrusted input gets concatenated into the LLM context window and the model treats that input as instructions rather than as data. The attacker controls part of the input, so the attacker controls part of the output. OWASP catalogs this as LLM01 in the LLM Top 10 (2025 update). Direct injection puts the payload in the user prompt; indirect injection hides it in a document, web page, email, or tool response that the LLM later reads.