Okta, Azure AD, and Lutril: Who Manages Access When AI Agents Enter the Picture?

The question IT is starting to ask

Most mid-market and enterprise companies have spent real time getting their IAM right. They have Okta or Azure AD configured with SSO across every major SaaS tool, SCIM provisioning tied to their HR system, MFA enforced universally, and lifecycle policies that revoke access within minutes of a termination event. That work is real, it matters, and it works well.

Then the engineering or operations team deploys an AI agent. The agent needs to read and write to Salesforce. It needs to create Jira tickets, post to Slack, pull from a knowledge base. The access requests start landing on the IT desk, and the existing playbook does not fit. The agent is not a human. It does not have a manager. It does not have a lifecycle that maps to hire and terminate. It makes dozens or hundreds of tool calls per hour, driven by LLM output rather than deliberate user intent.

The question IT is starting to ask is: does my existing IAM cover this, or do I need something else?

The honest answer is: your existing IAM is the right foundation, but it does not cover agents natively. Here is exactly what each product handles and where the boundary sits.

What Okta does (and doesn't do)

Okta is genuinely excellent at what it was built to do. Its core capabilities are deep and well-proven across thousands of enterprise deployments.

• Single sign-on. Okta's SSO catalog covers thousands of SaaS integrations. Employees authenticate once and access every connected application without re-entering credentials. The coverage and reliability here are best-in-class.
• Lifecycle management with SCIM. When someone joins or leaves, Okta propagates that change to every connected application automatically. Deprovisioning on termination is reliable and fast when SCIM is properly configured.
• Adaptive MFA. Okta's risk-based authentication evaluates signals including device posture, network, and location before deciding whether to challenge a login. This catches credential-based attacks that would get through static password policies.
• Group-based access policies. Role assignments flow from groups, which flow from your HRIS. A new hire in engineering gets the right tools automatically. A promotion from analyst to manager triggers role changes without a manual ticket.

Where Okta stops is at the concept of agent identity. Okta's directory is a directory of humans and, to a lesser extent, service accounts. When you add an AI agent, the common workaround is to create a service account in Okta, give it a machine credential, and assign it to relevant application groups. That works at a basic level. The agent can authenticate. It can access the SaaS tools you grant it.

What Okta does not have: a first-class concept of agent identity, no mechanism for defining which specific tool calls an agent is permitted to make within a connected application, no audit log that records LLM-driven tool call sequences, and no kill switch that halts a specific running agent session when something goes wrong. The service account workaround was designed for infrastructure automation, not for an LLM-driven agent that decides autonomously what actions to take based on a task it was given.

What Azure AD (Entra ID) does (and doesn't do)

Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The underlying capabilities are strong, particularly for organizations running Microsoft 365 workloads, Azure infrastructure, or both.

• Conditional access policies. Entra ID's conditional access is one of the most granular policy engines in enterprise IAM. You can require compliant devices, specific network conditions, or authentication strength based on application sensitivity and user risk signals.
• Managed identities for Azure workloads. For applications and services running inside Azure, managed identities eliminate the need for stored credentials entirely. An Azure function or VM gets an identity that Azure manages, and you assign it roles in RBAC. This is well-designed for Azure-native infrastructure.
• Microsoft 365 integration. For organizations already in the Microsoft ecosystem, Entra ID provides deep integration with SharePoint, Teams, Exchange, and Dynamics that Okta cannot match natively.
• Privileged Identity Management (PIM). PIM enables just-in-time role activation with approval workflows and time-bound access. This reduces standing privilege for sensitive roles.

For AI agents, the picture is similar to Okta. Managed identities work well if your agents are Azure-hosted and only calling Azure APIs. Once an agent needs to call SaaS APIs outside the Azure ecosystem, including tools like Salesforce, Notion, Slack, or any MCP-connected service, managed identities do not extend there. The agent needs a separate credential or OAuth token managed outside of Entra ID.

Entra ID has no policy layer for MCP tool calls. It cannot enforce that an agent is permitted to send a Slack message but not delete a channel. It does not capture tool call sequences at the agent level. Its audit logs record authentication events and resource access at the Azure RBAC level, not the semantics of what an LLM-driven agent decided to do with the access it was granted.

The gap both leave open

Okta and Azure AD were built before LLM agents existed as a deployed concept. The gaps are not failures of execution. They reflect a scope boundary that made complete sense until recently.

Neither product today handles:

• Agent identity in the directory. There is no first-class object type for "AI agent" with properties like owning team, purpose, permitted tools, and session lifetime. Service accounts are a workaround, not a fit.
• Per-tool-call policy enforcement. Neither Okta nor Azure AD can express or enforce a policy like "this agent may read CRM records but not update opportunity stage." Application-level permissions are coarse. The granularity required for agent governance does not exist in the current IAM model.
• Immutable audit logs for LLM tool calls. When an agent runs a multi-step task and calls ten different APIs in sequence, the existing IAM audit logs record the authentication event. They do not record the tool call sequence, the LLM decision that preceded each call, or the data returned. That record is gone when the session ends.
• Kill switches for running agents. If an agent is behaving unexpectedly mid-task, there is no mechanism in Okta or Azure AD to halt that specific agent session without revoking access for the entire service account, which may affect unrelated systems.
• Role parity between humans and agents. In a well-governed environment, a human with read-only access to a system should translate to an agent with the same read-only access. That parity mapping does not exist. The agent's access is configured independently of the human role definitions it is supposed to mirror.

These are not edge cases. They are the basic governance requirements for any organization that wants to extend its existing security posture to cover AI agents.

How they compare

Across the dimensions that matter for a complete access governance picture:

Reading this table the right way: the "Not applicable" cells for Lutril in the human identity rows are not absences. Lutril does not attempt to replace Okta or Azure AD for human SSO and lifecycle. That work is already done, and replacing it creates no value. The table reflects scope, not competition.

Why you need all three

The right architecture is layered. Okta or Azure AD handles what it was built to handle: human authentication, lifecycle management, MFA, group-based access. That layer is solid and should stay in place.

Lutril sits on top of that as the agent governance layer. Rather than replacing your IdP, Lutril reads role and group definitions from your existing Okta or Azure AD setup and uses them as the source of truth for what agents should be permitted to do. If a Salesforce analyst in your IdP has read-only access, an agent acting on behalf of that analyst inherits read-only access. The parity is enforced automatically, not configured manually per agent.

On top of that source of truth, Lutril enforces per-tool-call policy through MCP. When an agent attempts a tool call, the policy is checked before execution: is this agent permitted to run this specific tool, at this time, under this task context? If not, the call is blocked and logged. If yes, the call proceeds and the full context is written to an immutable audit record.

The integration works in the other direction too. When a human is offboarded in your IdP, Lutril sees that change and revokes or suspends any agent that was operating on their behalf. You do not need to build a separate offboarding workflow for agents. The existing human lifecycle triggers agent lifecycle automatically.

When to add an agent access layer

A few specific triggers indicate the moment the service account workaround stops being adequate:

• First AI agent with SaaS access. The moment an agent can write to a production system, the risk profile changes. Read-only access to internal documentation is low stakes. Write access to Salesforce, Jira, or any system with customer data needs governance that a service account cannot provide.
• First SOC 2 or ISO 27001 audit question about agents. Auditors are starting to ask about AI agent access controls. "We have a service account" does not satisfy the access control criteria in CC6.1 or A.9 when the access is being exercised by autonomous LLM-driven behavior. You need a policy record, an audit log, and evidence of scope limitation.
• First departure of someone who provisioned agents. When the engineer who set up the agent leaves, who knows what that agent can do? If the answer is nobody, the agent outlives the person who understood it. That is the same problem as shadow IT, applied to autonomous systems.
• More than one team deploying agents. When multiple teams have agents running in production, the governance surface grows faster than the ability to track it manually. A central policy layer becomes necessary at this point, not optional.

If none of these apply yet, the service account approach may be adequate for now. When any of them arrive, that is the right time to layer in dedicated agent governance rather than trying to stretch a human identity model further than it was designed to go.