AI Systems and Enterprise Identity — Where Most Deployments Cut Corners

In the AI engagements we have reviewed for remediation, the most common architectural gap isn't model selection or prompt engineering — it is identity. Authentication and authorisation are standard enterprise architecture concerns, well-understood and well-tooled. In AI deployments, they tend to be deferred, abbreviated, or wired up in ways that create exposure the team didn't intend.

This piece is a practitioner view of how enterprise identity should integrate with AI systems, where the common gaps are, and what the patterns that hold up actually look like.

What identity has to do in an AI system

A working identity model for an AI system answers several questions:

• Who is the user making the request?
• What is their organisational context (tenant, role, group)?
• What permissions do they have on the underlying systems the AI touches?
• What permissions do they have on the AI system itself (which features, which workloads)?
• What is the audit identity associated with their actions through the AI?

In a conventional application, the same questions arise. The answers usually come from the corporate identity provider — Microsoft Entra (formerly Azure AD), Okta, Ping, a SAML federation. The application validates the user's token; the user's identity propagates through the application; downstream calls carry the user's identity.

AI systems should do the same. They often don't.

The common gaps

Service-account integration with downstream systems

The AI system holds a service account credential for the downstream system. Every call the AI makes uses the service account, regardless of which user initiated the action.

This collapses access control. The AI can return data the user shouldn't see; the AI can call functions the user shouldn't invoke; the audit trail shows the service account, not the user.

The fix: propagate the user's identity. Either by using the user's token directly (where the downstream system supports it) or by representing the user's identity in the service-account call (claims passed through, or on-behalf-of patterns).

No tenant isolation

A multi-tenant AI system that doesn't enforce tenant boundaries at the data layer. The retrieval index is shared; the vector store has no filter on tenant; cached results leak across tenants.

The fix: tenant context as a first-class filter at every retrieval and every downstream call. Audit that nothing crosses the boundary.

Token freshness ignored

The user's token has a lifetime. After it expires, calls made with it should fail. AI systems sometimes cache tokens beyond their lifetime or use refresh tokens improperly, extending access beyond what the user's session was supposed to enable.

The fix: respect token lifetimes. Re-authenticate when sessions are stale. Treat tokens as credentials, not as persistent identifiers.

Identity at the LLM call but not at the function call

The system authenticates the user at the front door. The LLM is invoked. The function call from the LLM goes out using the system's credentials, not the user's.

The fix: identity propagation at every layer. The function executor checks the user's permissions before executing, regardless of what the LLM has been told.

Insufficient audit granularity

The audit log records that the system did things; it doesn't always record which user the things were done for. After an incident, the question "who initiated this" can't be answered.

The fix: every audit log entry includes the user identity, the session, the request ID. Joinable across layers.

The integration patterns that work

OAuth / OIDC at the front door

The standard pattern for modern enterprise applications. The user authenticates against the corporate IdP. The application receives an OIDC token. The token is validated; the user's identity and claims are available to the application.

For an AI system, the same applies. The AI is just another application from the IdP's perspective. The token provides identity; claims provide context.

Claims propagation

The user's claims travel with the request through the AI system:

• Identity (sub claim, email, name)
• Tenant or organisation
• Role
• Group memberships
• Custom claims relevant to the workload

When the AI calls a function, the claims are part of the call context. The function executor uses them to enforce permissions.

Token exchange for downstream calls

When the AI calls a downstream system on the user's behalf, the call should be made with credentials representing the user.

The pattern depends on the downstream system:

• OAuth-aware systems — pass the user's token, or exchange it for a downstream token
• SAML-federated systems — request a SAML assertion for the user, present to the downstream
• API key-based systems — use a service account but include the user identity as a header or claim that the downstream enforces
• Legacy systems — use a service account but log the user identity for audit; enforce permissions at the AI layer if the downstream cannot

The choice depends on the downstream system. The principle is the same: the downstream call represents the user, not the AI.

Authorisation at the function-call layer

When the LLM proposes a function call, the function executor performs authorisation:

• Is the user authorised to invoke this function?
• Are the function arguments within the user's permission scope?
• Are there policy constraints that apply (this user can read but not write, this user can read only their tenant's data)?

The LLM is not the authorisation engine. The function executor is. The LLM proposes; the executor disposes.

Tenant-aware retrieval

For multi-tenant systems, retrieval respects tenant boundaries:

• Vector store queries filtered by tenant
• Document stores accessed with tenant-aware credentials
• Caches keyed by tenant
• No cross-tenant inference even from aggregate signals

Session-scoped state

State that persists across an interaction (conversation history, intermediate results) is scoped to the session and the user. State does not leak across sessions or users.

Token rotation and revocation

The system handles token rotation gracefully. When a user's session is terminated (logout, revocation), state associated with the session is invalidated.

What we keep seeing

Recurring patterns in enterprise AI identity engagements:

Pilots run on service accounts; production proposals don't change that. The pilot was fast to build because it used a service account; the production migration leaves the service account in place. The exposure ships with the system.

Permission propagation gaps are the most common finding. In remediation engagements, we find them in roughly two-thirds of the systems we review.

Tenant boundary issues happen in multi-tenant SaaS contexts. A team builds a single-tenant pilot, expands to multi-tenant production, doesn't adapt the data layer. Cross-tenant leakage becomes the incident waiting to happen.

Audit identity gaps surface during incidents. The team responds to a complaint, tries to identify which user took the action, finds the log doesn't say. The retrofit is significant.

Modern IdP integration is straightforward but often deferred. Most enterprises have an IdP that supports OAuth/OIDC well. The integration work is routine. It just doesn't get prioritised in the pilot phase and ships unfinished.

What we recommend

For enterprise teams building AI systems in 2024:

1. Integrate with the corporate IdP at the front door. OAuth/OIDC for modern systems; SAML where the IdP doesn't support OIDC.
2. Propagate user identity through every layer of the system.
3. Authorise at the function-call layer, not just at the front door.
4. Respect token lifetimes. Don't cache or extend.
5. Enforce tenant boundaries at the data layer, not in application logic alone.
6. Log audit identity with every recorded action.
7. Plan token exchange patterns for downstream calls. The user is the actor, not the AI.

Enterprise identity for AI systems is not a new architecture problem. It is the same architecture problem solved many times in conventional systems. The teams that approach AI identity with that recognition produce systems that integrate cleanly with the existing enterprise controls. The teams that treat AI as a new architecture without these constraints produce systems that operate as privilege bypasses, often without realising it until the audit or the incident.