How is per-request authorization different from an API key with scopes?

Scoped keys narrow what a key can do, but the decision is still made once and baked into the credential. Every request carrying that key inside its scope is allowed, regardless of the prompt content or the specific identity behind the call. Per-request authorization evaluates each call fresh against the live identity, route, and content, so two requests under the same key can get different answers. Scopes coarsely partition access; per-request authorization decides each action.

Does this require changing how our applications authenticate?

Applications keep authenticating people and agents the way they already do. What changes is that the identity context travels with the model call so the enforcement point can read it, and the model endpoint is reached through that enforcement point rather than directly. The application does not have to reimplement authentication; it has to propagate identity into the request and route model traffic through the point that makes the decision.

What happens to a request that fails authorization?

Depending on policy, it is either denied outright or transformed before it proceeds, for example by redacting a sensitive field so the remaining request can continue safely. In both cases the original sensitive content never reaches the model, because the decision is made in the request path before the call continues. Every outcome, including denials and redactions, is recorded, so a blocked request leaves evidence rather than vanishing silently.

Can per-request authorization handle autonomous agents?

Yes, and agents are a strong reason to adopt it. An autonomous agent acting without a human still presents an identity and a scope, and each of its model calls is authorized on the same per-request basis: identity, route, content, decision, record. Because agents can generate many calls quickly, deciding and recording each one is what keeps their model activity attributable and governed rather than trusting a standing grant to behave.

Is this the same as rate limiting?

No. Rate limiting caps how many requests are allowed in a window; it does not look at who is calling or what the prompt contains. Per-request authorization is a content-and-identity decision on each call, which can permit, redact, or deny based on policy. The two are complementary: rate limiting protects against volume, while per-request authorization governs the substance of each call. An enforcement point can apply both, but they answer different questions.

Per-Request LLM Authorization: Deciding Access at the Call, Not the Key

Most enterprise access to a model is authorized exactly once. Someone issues an API key to an application, and from then on every request that carries the key is allowed, whatever it contains and whoever is behind it. The key is a standing grant. Per-request LLM authorization replaces that standing grant with a decision made at each call: this identity, on this route, with this prompt, right now. The request is evaluated before it reaches the model, and the answer can differ from one call to the next.

I want to walk through how per-request authorization works for model traffic, why key-scoped access is the wrong granularity, and how the decision fits inside the time a user already spends waiting for a response.

What "per request" changes

Key-scoped access answers one question, once: does the caller possess a valid key. Per-request authorization answers a richer question on every call. It resolves the identity of the user or agent behind the request, checks the route being called, inspects the content of the prompt, and applies policy that can permit, redact, or deny. Nothing about holding the key pre-authorizes the specific request.

The shift is the same one zero-trust made for network access, moved to the model call. Access stops being a property of a credential and becomes a decision about a specific action. A key that can reach the model is a starting point, not a verdict.

Why key-scoped access is too coarse for AI

Two prompts sent under the same key can carry wildly different risk. One asks a model to rephrase a public sentence. The next pastes a customer's full record into the same endpoint. Key-scoped access treats them identically, because the key does not know or care what the request contains. For traffic where the sensitive payload lives inside the request body, that is the wrong place to make the decision.

The identity problem compounds it. A shared application key makes every caller behind it indistinguishable, so authorization is not only coarse but collective. Anyone who can reach the key inherits its full grant. My view is that a shared model key with no per-request decision in front of it is not an access control at all; it is a shared password with a latency budget.

The anatomy of a per-request decision

A per-request authorization decision has a few moving parts, and they resolve in sequence in the request path.

Identity resolution comes first: the enforcement point reads the identity context the caller supplies and establishes who is acting and in what role. Route evaluation follows: which model and endpoint is being called, and what policy applies to that route for this role. Content inspection runs against the prompt: is there PII, a secret, or regulated data that policy treats differently. The decision resolves to permit the call as sent, redact specific fields, or deny it. And the outcome is recorded, so the authorization is not only enforced but evidenced.

Because all of this happens before the request continues to the model, a denied or redacted call never reaches the endpoint in its original form. The decision is preventive, not a post-hoc alert.

Keeping it inside the latency budget

The obvious worry is that a decision on every call adds delay. The budget makes it a non-issue for AI traffic. Enforcement overhead measures under 50 ms in production tests, while model inference runs from 500 ms to 5 seconds. The authorization decision resolves inside a window the user already waits through for the model itself. For high-volume batch traffic, a stateless enforcement point scales horizontally, so the per-request cost stays flat as call volume climbs.

DeepInspect

DeepInspect performs per-request authorization for model traffic. It runs as a stateless proxy between your applications, agents, and staff and any LLM, resolves the identity behind each call, evaluates the route and the prompt against per-route and per-role policy, and permits, redacts, or denies before the request reaches the model.

Every decision writes a tamper-evident record holding identity, role, policy version, data classification, outcome, and timestamp, committed before the response returns. Access to a model stops being a standing grant tied to a key and becomes a decision made, and recorded, on every call. To see per-request authorization running against your own routes, book a platform demo.