AI app enterprise infrastructure is now an identity problem

At a glance

What this is: This is a technical map of the enterprise infrastructure layer AI products need to scale, with identity, access, tenancy, and audit controls as the core finding.

Why it matters: It matters because IAM, NHI, and autonomous governance teams are now being asked to secure AI products that operate like enterprise software, not just model endpoints.

By the numbers:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read WorkOS's analysis of the enterprise infrastructure layer AI apps need

Context

AI applications stop being model projects the moment enterprises ask who can access them, what they can do, how access is revoked, and how decisions are audited. That turns the problem from model quality into identity governance, because the product must now integrate authentication, authorization, tenancy, and lifecycle controls to survive enterprise scrutiny.

For IAM teams, the key issue is that the subject is no longer only a human user or a service account. The application may authenticate people, agents, MCP servers, and internal services, which means the control plane has to distinguish identities, scope access correctly, and keep those boundaries intact as the product scales.

Key questions

Q: How should security teams govern AI products that use both human and non-human identities?

A: Treat the application as an identity-governed enterprise system. Human sign-in, service authentication, agent tokens, tenant isolation, provisioning, and audit logging all need distinct controls, because each identity type has different revocation and trust requirements. The safest pattern is to make access scope explicit, centrally governed, and continuously reviewable.

Q: Why do enterprise AI applications create new authorization risks?

A: Because the application must now decide not only who the user is, but what they can do across tenants, roles, data types, and workflows. If authorization stays embedded in code, the logic becomes brittle and hard to audit. Central policy evaluation reduces hidden privilege creep and keeps decisions explainable.

Q: What breaks when AI app provisioning and deprovisioning are manual?

A: Manual lifecycle handling produces stale accounts, delayed revocation, and mismatched group membership as directories and roles change. That creates both security exposure and operational friction, especially when enterprise customers expect immediate onboarding and offboarding. Automated reconciliation is the only durable way to keep access correct over time.

Q: How can teams tell whether an AI product is ready for enterprise security review?

A: Look for evidence that the product can prove identity scope, tenant isolation, access revocation, and auditability without custom engineering for each customer. If those controls are missing, the product is still a prototype from a governance perspective, even if the model itself is production-ready.

Technical breakdown

Enterprise authentication for users, agents, and services

Enterprise authentication in AI products is no longer a single login path. The app may need to support SAML, OAuth, and multiple identity providers while also authenticating AI agents, MCP servers, and service-to-service calls. Each identity type has a different trust boundary, revocation model, and session behaviour. That means authentication becomes distributed identity plumbing, not a front-end feature. The operational burden comes from per-tenant configuration, claim mapping, and logout edge cases that appear only under enterprise conditions.

Practical implication: design authentication as an identity platform layer, with separate handling for human sessions, workload credentials, and agent tokens.

Authorization and multi-tenancy as control boundaries

Authorization answers what an identity can do, while multi-tenancy defines where that access is valid. In enterprise AI products, those two controls are inseparable because every permission decision must be evaluated in tenant context and often in the context of role, project, sensitivity, or environment. Hard-coded rules fail because enterprise access changes faster than application code. The hidden technical work is centralized policy evaluation, scoped tenancy resolution, and auditability for every denied or approved action.

Practical implication: keep authorization policy external to application logic and enforce tenant isolation as a first-class security boundary.

SCIM, lifecycle management, and audit trails

Once a product supports enterprise onboarding, user creation and removal are driven by directory syncs, SCIM, and external identity events. That turns lifecycle management into a distributed systems problem because identities must stay correct across updates, deprovisioning, group changes, and reconciliation failures. Audit logs matter because enterprises need to explain not just who acted, but how the system changed over time. Without reliable lifecycle and logging, access becomes stale, orphaned, or unprovable.

Practical implication: build automated provisioning, deprovisioning, and structured audit logging into the core control plane, not as add-ons.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI products are becoming identity-governed enterprise systems, not just model experiences. The article shows that the hard problem is no longer the model, but the surrounding control plane: who can access it, what they can do, and how those decisions are logged. That is the same transition IAM teams have seen before in SaaS, but AI compresses it because humans, services, and agents now share the same product surface. Practitioners should treat AI application onboarding as an identity architecture problem, not a feature checklist.

Authentication for AI apps exposes the same governance drift that appears when NHIs are added without lifecycle design. Once an application must handle users, agents, and internal services, identity scoping stops being a login problem and becomes a trust-boundary problem. The article’s core signal is that browser sessions, service credentials, and agent tokens cannot be managed interchangeably. Practitioners should recognise this as a non-human identity governance issue, not a UI feature.

Authorization and tenancy are the real blast-radius controls in enterprise AI. The hidden stack matters because enterprise customers will judge whether access can be scoped, explained, and revoked without breaking workflows. That maps directly to NIST CSF and OWASP-NHI thinking: the security model must be explicit enough to survive audits and resilient enough to contain failure. Practitioners should not let authorization remain embedded in application code where it cannot be governed.

Lifecycle correctness is the difference between enterprise-ready and enterprise-risky. The article’s SCIM and provisioning discussion is really about whether access stays accurate over time as directories, roles, and teams change. That connects human IAM, NHI lifecycle, and machine access governance into one operational pattern. Practitioners should assess whether their AI products can prove deprovisioning, not just create accounts.

Named concept: enterprise identity stack. The article describes a hidden layer of authentication, authorization, tenancy, provisioning, audit, and protection controls that sits between a working model and a scalable enterprise product. The implication is that AI adoption now depends on whether that stack is designed upfront rather than patched in after security review begins. Practitioners should frame AI product readiness as identity infrastructure readiness.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• From our research: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• The governance gap is structural, not theoretical, because access models are already being stretched faster than policy coverage.
• From our research: Read more in Analysis of Claude Code Security for a related view of AI identity control in production.

What this signals

Enterprise readiness for AI is increasingly an identity programme decision. As products cross into customer environments, the question shifts from model performance to whether identities, tenants, and permissions can be governed without bespoke engineering. Teams that already run mature IAM and NHI controls will find the transition easier because the underlying problem is now control-plane discipline, not just application design.

Only 13% of organisations feel extremely prepared for agentic AI, according to the 2026 Infrastructure Identity Survey. That figure suggests the market has not absorbed how quickly AI products are turning into governed enterprise systems. Security leaders should prepare for more scrutiny around auditability, deprovisioning, and tenant isolation before those gaps become deal blockers.

Enterprise identity stack: the hidden combination of authentication, authorization, tenancy, lifecycle, and logging controls that lets an AI product survive procurement and security review. Practitioners should use that lens to separate genuine enterprise readiness from a model that simply works in a demo.

For practitioners

• Map every AI-facing identity type Separate human users, AI agents, MCP servers, service accounts, and background jobs into distinct identity classes with distinct trust boundaries and revocation paths. Do not reuse browser-session assumptions for workload or agent access.
• Externalise authorization policy Move access logic out of application code and into centrally evaluated policy so tenant boundaries, role changes, and data sensitivity rules can be audited and updated without rewrites.
• Treat SCIM as a reconciliation system Design provisioning and deprovisioning to survive partial failures, provider quirks, and delayed updates. Confirm that access removal completes cleanly when directories, groups, or roles change.
• Build auditability into the control plane Log identity changes, permission decisions, and administrative actions in structured form so security, compliance, and customer teams can explain access over time.
• Use tenant isolation as a security boundary Verify that every request, token, and policy evaluation resolves in tenant context so data and permissions cannot bleed across customers or background processes.

Key takeaways

• AI products become enterprise risk problems when they must authenticate users, agents, and services under one control plane.
• Authorization, tenancy, provisioning, and logging are the controls that determine whether an AI app can scale inside real organisations.
• Teams that design identity infrastructure early avoid retrofitting governance after security review starts.

Key terms

• Enterprise Identity Stack: The enterprise identity stack is the set of controls that lets an AI application operate safely inside a customer organisation. It includes authentication, authorization, tenancy, lifecycle management, audit logging, and protective controls that together define whether the product can be governed at scale.
• Tenant Isolation: Tenant isolation is the practice of keeping each customer’s identities, data, permissions, and configuration separate inside shared infrastructure. In AI products, it must hold across users, agents, services, and background jobs, or one customer can bleed into another through policy, data, or log paths.
• Lifecycle Reconciliation: Lifecycle reconciliation is the ongoing process of keeping accounts, roles, and access aligned as directories and organisations change. For enterprise AI, it means provisioning and deprovisioning must remain correct even when external systems update membership, roles, or attributes without direct human intervention.
• Scoped Agent Identity: Scoped agent identity is a non-human identity assigned to an AI system or agent with explicit limits on what it may access and do. The scope must be narrower than a human session because agents can execute independently, interact with tools, and persist across workflows.

Deepen your knowledge

AI product identity, access, and lifecycle design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building enterprise-facing AI systems, it is worth exploring.

This post draws on content published by WorkOS: The enterprise infrastructure layer behind successful AI applications. Read the original.