Post-authentication gap
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.
How the post-authentication gap shows up in production
A typical AI deployment integrates SSO at the application layer, lets the authenticated user into the chat interface, and then sends every prompt the user types to the model endpoint with no per-request authorization step. The application acts on behalf of the user without distinguishing between a low-risk question and a request that would route PHI, customer PII, or board-confidential financial detail to a vendor LLM. The post-authentication gap is the surface where shadow AI, accidental data exfiltration, and Article-12 evidence failures all originate.
How the gap gets closed at the request layer
Closing the post-authentication gap places an enforcement layer between the authenticated subject and the model endpoint. The layer reads the verified identity context the IdP provided, classifies the prompt payload, evaluates the per-route and per-role policies, and returns a per-decision verdict before the request reaches the model. The per-decision audit record bound to the identity context is the evidence form that answers Article 12, NIST AI RMF MANAGE 1.3, and Fannie Mae LL-2026-04 in a single architec
Related reading
- 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.
- AI Agent Authorization: NIST Pillar 2 at the Request Boundary
AI agent authorization is the per-request decision about whether a specific caller, against a specific resource, under a specific policy, is allowed to act. NIST calls it delegated authority. Most enterprise AI deployments solve authentication and skip authorization.
- Shadow AI Risks: Quantified Loss Exposure, Regulatory Liability, and the Per-Incident Math
Shadow AI risk lives in three separate ledgers: the per-incident breach cost, the regulatory liability that attaches to the deploying organization regardless of which employee pasted what, and the contractual liability already shifting from AI vendors to enterprises. This piece walks through each ledger with the numbers from IBM, the EU AI Act, Fannie Mae, and Gartner, and shows where the architecture closes the exposure.