Per-role policy
A per-role policy is a policy rule scoped to a user role or agent role inside the identity provider's directory. The role attaches to the verified subject the gateway receives in the identity context (OIDC claims, SAML assertion attributes, service-account scopes). A clinical user may submit PHI to a HIPAA-covered model endpoint; a marketing user may not. A scoped autonomous agent may write to the support-ticket system; a research agent may only read. Per-role policies translate the access-control vocabulary the security team already maintains in the directory into rules the enforcement layer applies per request.
How per-role policies bind to verified identity
The enforcement layer receives the inbound request with a verified identity claim (an OIDC ID token, a mutual-TLS client certificate, a workload-identity assertion). The gateway resolves the subject to the role set the directory holds for that subject at the moment of the request. The policy decision point evaluates the rule set bound to each active role. A subject can carry multiple roles; the policy uses the highest-privilege role that applies or the union of role permissions, depending on the policy authoring convention.
How per-role policy avoids the static-allowlist trap
A static allowlist (this user identifier is approved for this endpoint) breaks the moment HR moves the user to a different team. A per-role policy attaches to the directory role, not to the user identifier. When HR moves the user, the role membership changes, and the policy decision changes at the next request. The per-decision audit record captures the role that authorized the decision, which gives a regulator a defensible answer to "who could have made this request?" without reconstructing the directory state from access logs a
Related reading
- 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.
- 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.