What is Per-Request Authorization?
Per-request authorization evaluates each action against current identity, resource, policy, and request context immediately before enforcement. It does not treat an earlier sign-in or connection as permission for every later action.
Why it matters
Group membership, device state, risk, resource sensitivity, and requested operations can change during a session. A new decision can stop stale or broad session trust from reaching a protected service.
How it works
- Collect the verified caller identity and current request context.
- Evaluate policy for the exact resource and action.
- Allow or deny at the enforcement point, record the result, and repeat for the next request.
Example
A user remains signed in, but an administrator removes the user from the production group. The next protected HTTP or tool request is denied after policy reads the new context.
Pomerium boundary
Pomerium documents dynamic, context-aware authorization on every HTTP request. Its Model Context Protocol support can also combine identity policy with tool-level rules.
Limits and non-claims
- Pomerium documents TCP authorization as per session, not per packet.
- Frequent evaluation cannot correct a bad policy or false identity data.
- A later denial cannot undo an action that was already allowed.
- Pomerium protects Model Context Protocol servers that use Streamable HTTP through a Pomerium route. It does not secure local stdio connections, the model runtime, tool code, or traffic that bypasses the route.
Evaluation checklist
- Does every request name the current subject, resource, action, and decision context?
- Can a session, cache, connection, retry, or alternate route reuse an old allow decision?
- Does the application still authorize its own object and record the final action result?
