RBAC for LLMs Needs a Route and Action Matrix

A user can hold permission to call an Azure OpenAI deployment and still submit a prompt containing data that their job should never send to that route. Cloud IAM answers an important resource-access question. RBAC for LLM systems needs a second decision at request time. The decision must determine whether the authenticated role may use the selected model route and data class, and whether the requested action is allowed.

TL;DR

• Build RBAC for LLM traffic as a role-to-model matrix covering routes, data classes, and actions. Provider-resource permission is only one input.
• Bind policy to authenticated user or agent identity. Shared keys erase the attribution needed for request-level authorization.
• Test allowed and denied combinations across model aliases and fallback routes. Cover connected tools and streaming responses. Include a case with missing identity context.
• Log the policy version and matched rule. Include the reason code and outcome independently of the application that made the call.

Separate cloud resource access from request authorization

Microsoft documents four Azure OpenAI roles in its RBAC guidance. The service-specific pair is Cognitive Services OpenAI User and Cognitive Services OpenAI Contributor. Broader assignments include Cognitive Services Contributor and Cognitive Services Usages Reader. The OpenAI User role can make inference calls with Microsoft Entra ID against deployed models. It lacks permission to create deployments or access quota. It also cannot copy resource keys.

That role boundary is useful because it separates inference from resource administration. It still operates at the Azure resource scope. The role alone does not express that a support agent may use a summarization route with public ticket text but must be denied when the same route contains payment-card data.

AWS describes the underlying IAM model in its Amazon Bedrock identity and access guide. Administrators define permissions for each principal. Each permission pairs an action with a resource. Policy conditions can narrow that permission. Users and roles start with no permissions. Identity-based policies attach to an identity, while supported resource-based policies attach to a resource and name a principal.

Use those provider-level access controls. Then add the application-level request decision that provider IAM cannot infer from enterprise prompt context.

Build the role and action matrix for model routes and data classes

Start with rows for enterprise roles and columns for decision dimensions. Keep each cell explicit enough to compile into policy and test.

• Role: authenticated employee role, workload identity, service account, or delegated agent role.
• Model: approved model family or immutable model identifier. Treat mutable aliases as a deployment risk.
• Route: the controlled endpoint and provider account, including the region and deployment reached by the request.
• Data: the highest classification present in the prompt or attachments, including retrieved context and planned response handling.
• Action: completion, embedding, image generation, fine-tuning upload, tool invocation, or administrative operation.

A policy row might allow the legal-review role to use an approved text model through the EU route for confidential contract analysis, while denying training uploads and external web tools. Another row can allow a public-support role to summarize public content through a lower-cost route. This is the practical shape behind AI access control.

Add time and environment when they affect a real decision. Do the same for tenant and business purpose. A matrix with dozens of unused attributes becomes impossible to review. Every attribute should appear in at least one test and one log field.

Bind the matrix to trustworthy identity

The policy point needs identity context supplied through a trusted path. For a human, that can be a verified token carrying a stable subject and approved group or role claims. For an agent, use a workload identity plus delegated authority. The delegated authority should name the initiating principal and the permitted action.

Shared provider keys establish that an application can reach the service. They collapse every caller into the same provider identity. Keep provider credentials at the gateway or workload boundary and authenticate callers separately. Our per-request LLM authorization guide explains the difference between account access and the decision for one call.

Application role claims also need governance. Define the identity source and claim mapping. Assign an approval owner, establish a recertification process, and document the revocation path. Cache role data only for a bounded period that matches your revocation requirement. On lookup failure, a sensitive route should deny the request or use a deliberately limited fallback role.

I would never let a prompt body select its own role. The same rule applies to an unverified X-Role header. A convenient header becomes a privilege-escalation switch when the enforcement point trusts it without token or registry validation.

Add data and action context at decision time

A role says what a principal normally does. Prompt content determines what the principal is doing now. Classify the request before the model call and feed the resulting labels into the matrix. Include attached files and retrieved passages because the short user prompt can trigger a much more sensitive context window.

The requested action needs equal precision. Text generation and fine-tuning upload have different persistence and governance implications. A model call that can invoke a CRM write action carries more authority than a summarization call. Keep tool authorization distinct from model authorization, then require both decisions for an agentic request.

Attribute-based access control for AI becomes useful here. RBAC supplies the stable job function. Request attributes narrow that broad permission using the route and data class. The action, tenant, and environment provide further limits. An auditor can start with the role and then inspect the attributes that narrowed its permission for one request.

Inspect responses as a separate policy stage when output classification or tool instructions can change the allowed action. Record the request decision and response decision independently under one correlation ID.

Test the matrix as executable policy

Turn every allow rule into a positive test and every boundary into a denial test. Start the minimum suite with an approved role on its intended route. Reuse that identity against a prohibited model and then a more sensitive data class. Test a disallowed downstream action separately. Finish the suite with a missing-identity case. Add expired-token and revoked-role cases as separate checks.

Add cases for the operational edges:

• A model alias changes its backing version.
• The preferred provider fails and routing attempts a fallback.
• An agent requests a tool outside its delegated action set.
• Retrieved context raises the data classification after the initial prompt.
• A streaming response crosses an output rule after partial generation.
• The policy store or identity lookup becomes unavailable.

Run the suite in deployment pipelines and on every policy change. Preserve the policy bundle hash and identity fixture. Record the input classification, expected result, actual result, and test time. The broader AI request authorization model should be reviewable as code and evidence, rather than a diagram that drifted away from production.

Keep independent decision evidence

For each request, record the authenticated subject and effective role. Include the application or agent, provider, model, and route. Add the data labels and requested action, followed by the matched policy rule and policy version. Finish the event with the outcome, reason code, and correlation ID. Keep credentials and unnecessary prompt content out of the general audit event.

The application log remains valuable for debugging. An independent enforcement record establishes what crossed the controlled boundary and which rule governed it. This separation matters when an application crashes after receiving a response or suppresses a denied event.

Review denied events for two different signals. Repeated attempts against prohibited routes can indicate abuse. A surge in legitimate denials after a role change can reveal a broken claim mapping. The same reason code should lead an analyst to a different response based on identity and frequency, with deployment context informing the decision.

DeepInspect

DeepInspect can evaluate the role and model route for authenticated HTTP AI requests before they reach an LLM endpoint. The same decision can account for data classification and the requested action. Each decision can fail closed and produce a record containing the identity context and matched policy. The record also includes the version, outcome, and reason code.

The boundary is the deliberately routed user or agent-to-LLM HTTP call. Provider IAM remains responsible for cloud resource access, and local processes or bypass traffic require separate controls.

Book a technical deep dive at deepinspect.ai.