Identity Patterns for Enterprise GenAI

Identity is the control plane of enterprise GenAI. Prompts, models, and indexes get most of the attention, but identity decides who can ask, what data can be retrieved, which tools can run, and which actions can be audited.

When I design Azure AI systems, I do not start with one universal identity pattern. Different workloads need different combinations of application identity, user context, agent identity, CI/CD identity, and cross tenant trust.

The goal is to make access explicit. If I cannot explain which identity performed an action and why it was authorized, the architecture is not ready for production.

Pattern 1: App only workload identity

The simplest enterprise pattern is app only identity. The application or agent runtime authenticates as its own workload identity, usually a managed identity on Azure or a workload identity federation from a trusted platform.

Use this when:

• The application provides the same data experience to all authorized users.
• Retrieval uses a shared knowledge base without user specific permissions.
• Tool calls are application scoped rather than user delegated.
• The workload runs fully in a controlled backend.

In Azure, this often means a user assigned managed identity attached to Azure Container Apps, App Service, Functions, AKS, or another compute host. The identity receives roles such as Cognitive Services OpenAI User, Search Index Data Reader, Storage Blob Data Reader, or Key Vault Secrets User at narrow scopes.

The advantage is simplicity. The application can use DefaultAzureCredential, call downstream services without user tokens, and avoid secret rotation in application code.

The trade off is reduced user level authorization. If the app identity can read an index, the app logic must decide whether the current user should see each result. For general policy libraries, that may be acceptable. For customer records, legal documents, or HR files, app only identity is usually not enough by itself.

Pattern 2: On behalf of user context

On behalf of flow is the pattern I use when user permissions must travel through the application. The user signs in with Microsoft Entra ID. The application obtains a token for the downstream API on behalf of that user, or it uses the user identity to derive security filters for retrieval.

Use this when:

• Users have different permissions to source data.
• RAG results must respect document level access.
• The source system already has mature user authorization.
• Audit must show the human user, not only the application.

For RAG, I usually see direct delegated access, where the application calls a downstream API with a user token, or security trimming, where user groups, roles, tenant, or document grants become filters in Azure AI Search.

I prefer direct delegated access when the source system supports it cleanly and performance is acceptable. I prefer filter based trimming when the search index is the primary retrieval layer and the permission model can be represented reliably as metadata.

The trade off is complexity. Token acquisition, caching, consent, conditional access, group overage, and permission freshness all need attention. Still, for sensitive user scoped data, this is often the right complexity to accept.

Pattern 3: Agent identity separation

AI agents need identity separation because they combine reasoning with action. A single agent experience may search documents, summarize cases, open tickets, send notifications, and update records. Those actions should not all share one broad identity.

Use this when:

• The agent has multiple tools with different risk levels.
• Ingestion and runtime have different permission needs.
• Some actions require human approval.
• Different business domains need different blast radiuses.

I normally separate:

• Runtime identity for chat and low risk retrieval.
• Tool specific identity for privileged integrations where the hosting model supports it.
• Ingestion identity for indexing documents and embeddings.
• Administration identity for deploying prompts, model connections, and infrastructure.
• Human approver identity for high impact decisions.

The implementation depends on the agent framework and hosting platform. One runtime identity may call policy enforcing tools, or tools may run as separate services with their own managed identities. The second option is cleaner for high risk tools because each service has its own RBAC and logs.

The trade off is operational overhead. More identities mean more role assignments, more monitoring, and more documentation. For enterprise agents, that overhead is usually worth it.

Pattern 4: Federated credentials for CI/CD

Deployment pipelines need access too, and they are often overprivileged. I avoid long lived service principal secrets for CI/CD. Instead, I use federated credentials so the pipeline can exchange its platform identity for a Microsoft Entra token.

Use this when:

• GitHub Actions or Azure DevOps deploys Azure AI infrastructure.
• Secrets in pipeline variables should be eliminated.
• Role assignments need to be scoped and auditable.
• Production deployments require separation from runtime access.

The pipeline identity should be different from the agent runtime identity. It may need permissions to create Azure AI Foundry related resources, assign identities, deploy infrastructure, or update configuration. The running application should not have those permissions.

A typical GitHub Actions pattern uses OpenID Connect federation with an Entra application or managed identity, then logs in without a client secret.

permissions:
  id-token: write
  contents: read

steps:
  - uses: azure/login@v2
    with:
      client-id: $AZURE_CLIENT_ID
      tenant-id: $AZURE_TENANT_ID
      subscription-id: $AZURE_SUBSCRIPTION_ID

The important part is the role scope. A deployment identity for one AI workload should not be Owner for the entire subscription unless there is a very specific reason and a compensating control.

Pattern 5: Cross tenant access

Cross tenant GenAI appears in partner portals, managed services, acquisitions, multi tenant SaaS, and enterprise groups with separate Entra tenants. It is easy to underestimate.

Use this when:

• Users from one tenant access an AI application hosted in another.
• A central platform serves multiple subsidiaries.
• A SaaS product retrieves tenant specific data.
• A managed service operates AI workloads for customers.

The design choice is whether identities are invited, federated, or represented as tenant specific service principals. The data plane must keep tenant boundaries clear. Search indexes, storage containers, databases, and telemetry should be partitioned by risk. Sometimes separate resources per tenant are better than shared resources with filters.

For cross tenant RAG, I am cautious with shared indexes. Tenant ID filtering is not enough if operational teams, logs, embeddings, or backups blur boundaries. The right answer depends on contractual obligations, regulatory requirements, support model, and incident response expectations.

The trade off is cost and complexity. Stronger isolation usually means more resources and more automation. For sensitive tenants, that is often the correct choice.

Choosing the right pattern

Pattern	Best fit	Main strength	Main trade off
App only workload identity	Shared knowledge and backend automation	Simple operations and no user token handling	App must enforce user authorization
On behalf of user context	User specific data and security trimmed RAG	Preserves human access boundaries	Token and permission complexity
Agent identity separation	Tool using agents with mixed risk	Reduces blast radius by function	More identities to govern
Federated CI/CD identity	Automated deployment	Removes long lived pipeline secrets	Requires careful role scoping
Cross tenant access	Partner, SaaS, and group scenarios	Supports external identity boundaries	Isolation and operations complexity

I often combine patterns. A production RAG assistant might use on behalf of user context for retrieval, app only identity for model calls, separate ingestion identity for indexing, and federated CI/CD for deployment. That is not overengineering. That is matching identity to responsibility.

Design questions I always ask

Before approving an identity design, I ask:

• Which human user initiated the request.
• Which workload identity called each Azure service.
• Which identity can read source data.
• Which identity can write or delete data.
• Which identity can change prompts, indexes, and deployments.
• How are CI/CD permissions separated from runtime permissions.
• How are cross tenant users represented.
• Where are authorization decisions logged.
• How quickly can access be revoked.

If the team can answer those questions clearly, the system is much easier to operate and defend.

Key takeaways

• Enterprise GenAI needs a catalog of identity patterns, not one default approach.
• App only identity is simple, but user scoped data often needs on behalf of flow or security trimming.
• Agents benefit from separate identities for runtime, ingestion, administration, and high risk tools.
• Federated CI/CD removes long lived deployment secrets and improves auditability.
• Cross tenant scenarios require deliberate isolation across identity, data, indexes, logs, and operations.