How are roles passed from the application to the enforcement layer?

The role information travels with the request. The standard pattern is for the application to authenticate the user against the identity provider, receive the user's identity and role set as part of the authentication response, and attach the role set to the AI request as headers or as a signed token. The enforcement layer reads the token, validates the signature against the identity provider's public key, and trusts the role assertions for the policy evaluation. The application cannot fabricate roles because the signature anchors the trust to the identity provider.

What happens when a user has multiple roles?

The policy evaluation combines the policies for the user's role set, with the deployer's configuration choosing between union (the user gets the union of permissions across roles) and intersection (the user gets only the permissions all roles grant). The union pattern is more common because it matches the access-grant model the rest of the enterprise security stack operates. The audit record captures the full role set so the auditor can reconstruct the authorization context.

How does the pattern interact with break-glass access?

Break-glass access is the operational pattern where a user takes on a temporary high-privilege role to handle an incident, with the access logged and reviewed after the fact. The AI policy supports break-glass by treating the temporary role as part of the role set for the duration of the access. The audit record captures the break-glass role and the timestamp, supporting the post-incident review. The pattern does not bypass the audit; it operates with explicit visibility into the elevated access.

Can roles inherit policies from other roles?

Yes, and most production deployments use inheritance to reduce the policy maintenance burden. A base role expresses the default AI authorization for all employees. Department-specific roles inherit from the base and override the dimensions that differ for the department. Senior roles inherit from the department role and add the additional authorization that comes with seniority. The inheritance pattern matches the access management practices most enterprises already operate.

How often should the per-role policies be reviewed?

The frameworks that the policies satisfy expect periodic review. The EU AI Act Article 26 deployer obligations include ongoing monitoring, and the NIST AI RMF Manage function expects the policies to update based on observed patterns. The operational cadence is usually quarterly for the policy structure (which roles exist, which dimensions they cover), with continuous review of the role-to-user assignments through the identity provider's access management. Significant changes to the deployer's AI footprint, the regulatory landscape, or the role hierarchy should trigger an off-cycle review.

Per-Role AI Policies: How to Operationalize Identity-Bound AI Authorization

Per-role AI policies authorize what a user can do with AI based on the role the user holds inside the deployer organization. The policy expresses which models a role can call, which data classifications the role can include in prompts, which destinations and actions the role can target, and what oversight applies to each. The pattern is the AI extension of the role-based access control model the rest of the enterprise security stack already operates. The architectural difference is the inputs the policy evaluates: prompts and data classifications rather than file paths and HTTP methods.

The pattern matters because the regulatory frameworks taking effect in 2026 do not treat all AI usage the same. The data the user processes, the decisions the AI informs, and the role the user holds all affect the obligation set that applies.

I want to walk through what a per-role AI policy actually contains, how it propagates through the request path, where the pattern satisfies the regulatory authorization requirements, and how the policy operates against the common enterprise role hierarchy.

What a per-role AI policy contains

A per-role AI policy expresses the authorization at five dimensions.

The model dimension specifies which models the role can call: OpenAI's GPT family, Anthropic's Claude family, Google's Gemini, AWS Bedrock-hosted models, Azure OpenAI, internally hosted open-source models, or a subset based on the role's data sensitivity. A customer-support role might be permitted to call commercial general-purpose models; a clinical role might be restricted to BAA-covered models only.

The data dimension specifies which data classifications the role can include in prompts. The deployer's existing data classification (public, internal, confidential, restricted) maps to the AI policy through this dimension. A finance role might be permitted to include confidential financial data in prompts to a restricted model set; a marketing role might be restricted to internal-and-below classifications regardless of the model.

The destination dimension specifies which AI surfaces and actions the role can target. The chat surface and the API surface have different policy. The action surface for agent workflows has its own policy: which downstream systems the agent can act against, what scope of action, and what authorization the role grants for the action.

The oversight dimension specifies what happens when a request is high-stakes or borderline. The policy can route the request to a human reviewer, require an explicit second-user approval, or require additional metadata before forwarding. The oversight dimension is the operational expression of the EU AI Act Article 14 human oversight requirement and the equivalent provisions in NIST AI RMF.

The audit dimension specifies the record fields the audit layer has to capture for the request. Some roles produce records with full prompt content; some roles produce records with redacted content; some roles produce records with additional metadata required for the regulatory framework that applies.

How the policy propagates through the request path

The policy operates at the AI request boundary, where the enforcement layer evaluates each request before it reaches the model. The propagation path has four steps.

The application authenticates the user against the deployer's identity provider. The identity provider returns the user's identity, including the roles the user holds. The application attaches the verified identity and the role set to the AI request as it forwards to the enforcement layer.

The enforcement layer reads the role set from the request, looks up the policy for each role, and evaluates the request against the policy. The evaluation produces a decision: pass, redact, modify, block, route to human review. The decision is recorded as part of the per-decision audit record.

The audit record includes the role set in effect at the moment of the request, so the auditor reviewing the record can reconstruct the authorization context. The record is committed before the model response returns to the application.

The application receives the decision and either forwards the response, presents the redacted response, surfaces the routing-to-review state, or returns the policy violation to the user. The application's logic around the response depends on the decision, but the policy evaluation itself happened at the enforcement layer.

Where the pattern satisfies the regulatory authorization requirements

The EU AI Act Article 26 deployer obligations include operating the AI system within its intended purpose and ensuring human oversight by competent natural persons. The per-role policy is the operational expression of the deployer's allocation of AI usage to roles, and the audit record evidences that the allocation operated.

The Article 12 record-keeping obligation requires identification of natural persons involved. The per-role policy's audit record captures both the natural person and the role context, satisfying the identification requirement at a higher granularity than the natural-person field alone provides.

The NIST AI RMF Govern and Manage functions include allocating responsibility for AI usage and operating the controls that the responsibility allocation implies. The per-role pattern is the operational expression of the allocation.

The ISO 42001 management system requires the deployer to document the controls and operate them at the per-decision level for high-stakes AI usage. The per-role policy produces the documented control and the per-decision record the audit samples against.

For sector frameworks (HIPAA with AI, GLBA, DORA, Fannie Mae LL-2026-04), the per-role pattern satisfies the sector-specific authorization requirements that depend on the user's clinical privilege, financial license, or supervisory role.

How the policy operates against the enterprise role hierarchy

The enterprise role hierarchy is usually expressed in the identity provider as groups: Active Directory groups, Okta groups, or the equivalent. The AI policy maps onto these groups directly. A user's group membership at the identity provider drives the role set the AI policy evaluates against.

The mapping has three operational patterns. The functional mapping uses department-based groups: Finance, HR, Legal, Engineering, Customer Support. Each function has its own AI policy reflecting the data the function handles and the AI surfaces appropriate to its work. The level mapping adds seniority: a Director-level user in Finance has different oversight requirements than an analyst-level user in the same department. The privilege mapping adds high-trust roles: incident response staff, compliance officers, and auditors have specific AI authorization for their work.

The mapping is maintained as part of the identity provider's group management, with the AI policy operating against whatever group structure the identity provider already runs. The pattern reuses the existing access management discipline rather than introducing a parallel AI-specific access model.

Where role granularity matters most

The role granularity has to match the regulatory granularity. For EU AI Act Annex III use cases, the role that is permitted to use the high-risk AI system has to be identifiable at the per-decision level. A generic employee role that covers both high-risk and low-risk AI usage fails the audit because the record cannot distinguish the use case.

The practical answer is to introduce role granularity that reflects the high-risk Annex III boundary. The hiring AI system is accessible only to a specific HR sub-role. The credit-scoring AI system is accessible only to a specific underwriting role. The classification of access on the role distinguishes the high-risk usage from the general-purpose AI usage and supports the regulatory boundary.

For sector regulations, the role granularity has to match the sector's authorization model. HIPAA's minimum necessary principle implies role-based access to PHI, and the AI policy has to inherit that constraint. Financial services authorization frameworks (SR 11-7 for model risk management, MNPI handling for material non-public information) imply roles that have specific AI authorization tied to the licensed activity.

What the policy does not solve

The per-role pattern requires the identity provider's group hierarchy to be in good shape. If the groups are stale, mismatched against the actual role hierarchy, or insufficiently granular, the AI policy inherits those problems. The pattern is not a substitute for identity governance; it is a downstream consumer of identity governance.

The pattern does not address the case where the user's role legitimately permits the AI usage but the specific request is still problematic. The role might permit Finance staff to discuss customer transactions in prompts, but a specific prompt that includes a sanctioned-party name still violates a separate AML control. The pattern handles the per-role authorization; additional data-classification and content-pattern controls layer on top.

DeepInspect

This is the architecture per-role AI policies operate at. DeepInspect sits at the AI request boundary as a stateless proxy between the application and the LLM provider. For each request, the proxy reads the verified user identity and the role set the application attached, looks up the policy for the role set, and evaluates the request against the policy.

The decision is made before the prompt reaches the model. The per-decision audit record captures the identity, the role set in effect, the data classification, the policy version, the decision outcome, and the timestamp. The record satisfies the EU AI Act Article 12 and Article 19 record-keeping obligations and the equivalent requirements across NIST AI RMF, ISO 42001, HIPAA with AI, and the sector frameworks.

The policy expression supports the dimensions enterprise deployments need: model authorization, data classification, destination scope, oversight routing, and audit fields. The policy operates against whatever group structure the deployer's identity provider already runs, with the role-to-policy mapping maintained as configuration rather than as code.

If your AI deployment is operating against a uniform policy regardless of who the user is, the question that surfaces at the next compliance review is how the deployer demonstrates the role-based authorization the frameworks expect. Book a demo today.