Per-route policy
A per-route policy is a policy rule scoped to a specific API route inside the AI request boundary. Each route (chatbot completion, RAG retrieval, code-assist generation, structured extraction) carries different data classes, different identity requirements, and different acceptable outcomes. A per-route policy attaches the rule set to the route key the gateway resolves at request time. The chatbot route may pass low-classification prompts through Claude; the RAG retrieval route may require PHI redaction before reaching the model; the code-assist route may block any prompt containing a secret pattern. The same enforcement layer applies all three from a single configuration surface.
How per-route policies are evaluated at request time
The gateway resolves the route from the inbound request: the destination model endpoint, the application identifier, the URL path, or a request header the application sets. The policy decision point looks up the rule set bound to that route, takes the identity context the gateway has already established, takes the classification verdict the prompt classifier returned, and evaluates the combined inputs against the rules. The decision returns pass, redact, or block with a reason code. The per-decision audit record carries the route key so a regulator can reconstruct which policy applied to which request.
Why per-route policy separation matters for the audit trail
A single enforcement layer that runs one rule across every route either over-blocks (rules that fit code-assist break the chatbot) or under-blocks (rules that fit the chatbot let secrets through code-assist). Per-route policies let one team write the chatbot rules and another team write the RAG rules without either team breaking the other's traffic. The audit record carries the route attribution alongside the policy version hash, which keeps the regulator's question "which policy applied to this request?" answerable on demand.
Related reading
- Per-Route AI Policies: How To Implement Endpoint-Specific Enforcement in Front of LLM APIs
Per-route AI policies attach a different enforcement rule to each LLM endpoint behind the inspection layer. A request to the customer-support route runs under one policy. A request to the developer-tooling route runs under another. The implementation lets a single inspection layer serve every team without the lowest common denominator policy that an organization-wide rule produces. This piece walks through the data model, the matching algorithm, the policy state that has to be present at decision time, and the operational characteristics that hold up at production scale across OpenAI, Anthropic, Azure OpenAI, and Bedrock endpoints.
- 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.