Authorization Before Inference

Scope

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.

Executive 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.

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.

Five questions to ask any LLM gateway

1. 1Can it distinguish people, applications, workloads, and agents — and require active, scoped delegation behind an agent, rather than treating a key as the identity?
2. 2Is model authorization evaluated by a shared PDP with subject, intent, data, and spend context — or duplicated as local rules in each gateway?
3. 3Can a budget stop or constrain a request before provider consumption — and what happens when the authoritative spend state is unavailable?
4. 4Are prompt classifications separated into analytics and policy tiers — with the classifier advisory to policy, observable for drift, and never the business-decision engine?
5. 5Can a completed allowed call be linked to its policy decision, constraints, effective model, and measured usage in signed, tamper-evident form?