PDF whitepaper
Authorization Before Inference
How the EmpowerID LLM Gateway governs model access in an Identity Fabric
Identity Fabric architecture whitepaper — LLM Gateway
This whitepaper describes the EmpowerID LLM Gateway as an Identity Fabric Policy Enforcement Point at the model boundary—verified identity and delegation, prompt intent as policy context, budgets enforced before the provider call, credentials kept out of clients, and signed evidence for completed allowed use only. Feature availability, provider routes, classification depth, budget modes, model switching, and receipt coverage vary by edition and deployment.
Summary
Copilots, workflows, and agents now choose models, consume data, and act on behalf of human and machine subjects. Conventional AI gateways route, retry, cache, meter, and filter that traffic. They do not decide whether a governed subject, acting under a specific authority, may use a specific model for the apparent purpose of the request, within its current spending boundary—or preserve evidence that links the decision to the model use that followed. The EmpowerID LLM Gateway makes that decision at the model boundary as a specialized policy enforcement point—not a reverse proxy with extra logging, and not a feature of the identity provider. When an agent moves from reasoning to action, the separate MCP Gateway governs tool execution against the same policy plane: one policy plane, two specialized enforcement points.
OpenID AuthZEN connects the LLM PEP to the EmpowerID PDP. Provider-compatible routes preserve familiar OpenAI and Anthropic request patterns while authorization, credentials, budget policy, model switching, and evidence move into the Identity Fabric control layer.
What's inside
-
A provider key is not an identity
Possession of a provider key proves only that a client can reach a provider—not whose business authority is being exercised or whether that authority permits the current intent.
-
Enforce before inference
A denied request never reaches the provider. Policy reroute, budget downgrade, and provider failover each re-authorize every candidate model through the shared PDP—not config substitution.
-
Spend as authorization
Estimated cost and authoritative consumed spend are evaluated in the PDP decision before the provider call—estimate, authorize, consume, measure, aggregate, authorize again.
-
One policy plane, two PEPs
The LLM Gateway governs model invocations. The MCP Gateway governs tool execution. Both consult the same Identity Fabric identity graph and Governed Authorization PDP.
-
Honest evidence semantics
Signed, hash-linked receipts bind completed allowed calls to policy context, constraints, effective model, and measured usage. Denied calls use decision telemetry—not receipt-backed execution claims.
