Integrating AI Access Control with Okta and Entra ID

When Anthropic released the Model Context Protocol in late 2024, most observers read the announcement as a developer convenience. It was an architectural shift. Within roughly eighteen months, MCP had attracted backing from every major AI lab, accumulated massive monthly SDK adoption figures, and secured governance under the Linux Foundation's Agentic AI Foundation. The field had needed a standard way for AI agents to call tools for years, and MCP arrived at the moment enterprises were finally serious enough about agentic workflows to adopt one.

MCP gives AI agents a common interface for invoking capabilities across enterprise infrastructure: internal APIs, SaaS systems, databases, code execution environments. What it deliberately omits is any security layer. No built-in permissions, no governance, no access control. That's the right architectural choice for a specification meant to be broadly adopted, and it creates a serious operational problem for the enterprises now running it in production.

The credential hygiene crisis that followed was predictable to anyone who had watched OAuth sprawl unfold a decade earlier. Without a governed layer, connecting many agents to many tools requires a separate authentication flow for every combination, each carrying its own credentials, error handling, and audit trail. Agents end up holding API keys and OAuth tokens scattered across environment variables and configuration files. GitGuardian research from 2025 found a substantial number of unique secrets exposed in MCP configuration files, with Google API keys and database connection strings among the most common leaked types. This isn't a MCP flaw. It's what happens when a powerful integration surface is deployed without an access control layer sitting in front of it.

OAuth 2.1 was incorporated into the MCP specification in mid-2025, giving the protocol a formal authentication hook. Implementation varies widely. That gap, between what MCP enables and what it governs, is where IdP integration stops being a best practice and becomes a structural necessity.

What an MCP Gateway Actually Does and Where IdP Identity Plugs In

An MCP gateway sits between agents and MCP servers as a reverse proxy. It authenticates and authorizes every request, routes it to the correct backend server, enforces policy, and logs the interaction. The distinction from a traditional API gateway matters. An API gateway enforces policy at the HTTP and transport layer. An MCP gateway enforces policy at the tool and agent semantic layer: it understands which tool is being called, by which agent, under which policy. That semantic awareness is what makes it capable of enforcing meaningful constraints rather than blunt network controls.

Tool-level access control lists handle blast-radius containment. A backend MCP server exposes dozens of tools, but a given agent sees only the subset it has been explicitly granted. The default posture is deny. If an agent is compromised, the damage stays within its authorized tool set; it can't traverse the full server surface. This isn't a novel security principle. It is least-privilege, applied one layer deeper than most teams have historically enforced it, and the failure to enforce it at this layer is precisely where breaches have room to propagate.

The identity connection is protocol-native. The gateway's authentication layer speaks OAuth 2.1, OIDC, and SAML, the same protocols enterprises already use for human single sign-on. Agent identity tokens can therefore be issued, validated, and revoked through existing Okta or Entra ID infrastructure without introducing a parallel credential system. The gateway is the enforcement point; the IdP is the policy authority. Requiring all agent connections to route through governed infrastructure is structurally identical to the shift enterprises made when they deployed SaaS access management for human users. Shadow agent control becomes tractable through the same mechanism, not a new one.

Extending Okta to Cover AI Agents, MCP Servers, and Delegation Chains

Okta's answer to the non-human identity problem is to treat agents as first-class identities inside Universal Directory, applying the same lifecycle management already in place for humans: onboard, protect, govern, revoke. The operational translation covers three distinct capabilities.

Discovery surfaces known and shadow agents automatically through OAuth consent grant monitoring, assigning them to a centralized registry and requiring a named human owner for each. Protection replaces long-lived tokens with short-lived credentials; agents can't accumulate standing permissions outside their registered scope. Governance closes the loop through automated access reviews, full audit trails, and a defined revocation path for agents that are decommissioned or behave anomalously. None of these are novel concepts. What's notable is that Okta applies them to agents without asking security teams to learn a new discipline from scratch.

Delegation chains are the harder problem, and most organizations don't appreciate the complexity until they're already deep into multi-agent deployment. In architectures where one agent calls another, which calls a third, the audit trail becomes genuinely difficult to reconstruct without a standard that understands agent-to-agent interactions. Okta addresses this with Cross App Access, an open standard extending OAuth to cover agent-driven application-to-application interactions. XAA shifts access control from individual applications to the identity layer, pre-approves integrations to reduce repeated consent prompts without sacrificing visibility, and makes the delegation chain legible to security teams. Early adopters include Automation Anywhere, Boomi, Box, and Glean Technologies.

The authorization model Okta recommends for AI-driven decisions moves beyond coarse role-based access control toward relationship-based or attribute-based models. A practical example: an agent holding a "viewer" relationship can summarize documents but can't export data to external APIs. The relationship defines not just what the agent can access but what it can do with that access, a distinction that matters considerably when agents are capable of irreversible actions. Token exchange, formalized in RFC 8693, supplies the credential mechanics. Agents trade their own identity token for a scoped, short-lived access token carrying delegated permissions; the user's primary credentials are never exposed.

The Okta Integration Network's catalog covers agent platforms including Boomi, DataRobot, and Google Vertex AI, giving security teams a single console for both sanctioned and shadow agents. For organizations running AWS Bedrock, agents can be imported into Okta's registry, assigned human ownership, and have their resource connections defined and enforced at the identity layer. Okta federates with non-Okta providers via OIDC and SAML, so enterprises running Entra ID or Ping for human identities can layer Okta agent governance on top without replacing their existing human IAM stack.

How Microsoft Entra Agent ID Extends Zero Trust to Non-Human Identities

Microsoft introduced Entra Agent ID in mid-2025 with basic visibility capabilities, expanded the feature set at Ignite 2025, and reached general availability in early 2026. The architectural choice at its core is deliberate: an agent identity is a specialized service principal that carries no credentials of its own. It acquires short-lived tokens through a parent blueprint, contingent on user or tenant administrator consent to the relevant scopes.

Agent identity blueprints are templates that define security policies for classes of agents through parent-child relationships. They enable consistent policy enforcement across large numbers of agents without individual configuration. Microsoft reports that agents inside the M365 ecosystem grew many-fold year over year, a figure that makes per-agent configuration untenable. Blueprints aren't a convenience feature; at that scale, they're the only viable governance mechanism.

The platform extends existing Zero Trust controls rather than standing up a parallel system. Conditional Access policies apply to agent principals. Identity Protection risk signals apply to agent token requests. Privileged Identity Management scoping is available for high-privilege agent roles. An enterprise that has already built out its Zero Trust posture doesn't rebuild it for agents; it extends the same enforcement logic to a new class of principal.

Two delegation patterns are formally supported. On-behalf-of authentication allows an agent to authenticate using a user's context and inherit that user's permissions for the duration of a task, the standard pattern for copilots and assistants operating inside a single employee's workflow. Autonomous authentication gives an agent its own standing identity and permission set, independent of any human session, appropriate for background workflows and scheduled automations where no user context is available.

Third-party agents from platforms such as AWS Bedrock and n8n can be integrated via the Microsoft Entra Auth SDK or workload identity federation, giving every agent a governed Entra identity regardless of where it was built. For organizations already standardized on the Microsoft 365 and Azure stack, Entra Agent ID is the natural integration path, embedded in the ecosystem rather than layered on top of it. Okta's advantage shows up in heterogeneous environments where Microsoft isn't the dominant platform, where breadth of integration matters more than depth inside a single ecosystem. Security architects choosing between them aren't choosing between a good option and a bad one.

The Practical Steps for Wiring an IdP to an AI Governance Layer End-to-End

Start with inventory, not policy. Organizations that attempt to define access rules before completing discovery end up governing a fraction of the agents that actually exist. The ungoverned remainder doesn't disappear; it operates outside the framework and accumulates risk quietly.

Inventory means using Okta's OAuth consent monitoring or Entra Agent ID's visibility tooling to surface what agents already exist before attempting to register them. Shadow agents are the first problem to solve, not the last. Once agents are surfaced, every entry in the directory needs a named human owner accountable for its scope and lifecycle. A registry without accountability is bookkeeping, not governance.

Credential modernization follows. Replace API keys and static OAuth tokens in environment variables with token exchange patterns, specifically RFC 8693 or workload identity federation. This is the single highest-leverage credential hygiene change available, and it directly addresses the secret-exposure pattern GitGuardian documented in MCP configuration files. After credentials, map roles. Start with the RBAC group structure already defined for human users and apply it to agents, then tighten progressively toward relationship-based or attribute-based access control where agents require finer-grained constraints than human roles provide.

Gateway deployment is where policy becomes enforceable. An MCP gateway must sit in front of MCP servers, configured to validate tokens issued by the IdP, enforce default-deny ACLs at the tool level, and route all agent traffic through a governed layer before it reaches backend systems. Without this layer, the identity work that preceded it governs credentials but not actions. Those are different problems. Conflating them is common, and the gap it creates doesn't show up in security reviews; it shows up in incidents.

Log unification closes the observability gap. Agent audit trails from the gateway and IdP should flow into the same SIEM and observability pipelines as human access logs. Unified visibility is the prerequisite for meaningful anomaly detection; without it, you've got two separate pictures of a single threat surface. Finally, define a revocation runbook before an incident forces one: specific triggers for agent deactivation, from anomalous behavior to ownership changes to decommissioning, and a clear timeline for how fast revocation propagates through the credential chain.

Where Speakeasy Fits as the Control Plane Connecting IdP Policy to Agent Execution

IdP governance defines who agents are and what they're permitted to do. It doesn't automatically enforce that definition at the moment an agent invokes a tool against a backend system. The gap between the identity layer and the execution layer is real, and it requires something purpose-built to occupy it.

SpeakeasyAPI's AI control plane is built for that enforcement layer. It functions as an MCP gateway between agents and enterprise systems, validating identity tokens issued by Okta or Entra ID at the semantic layer before any tool call reaches a backend. It adds real-time threat detection, including prompt injection detection, PII blocking, and secret detection in transit, alongside cost and usage telemetry and full audit logs of agent actions, surfaced in a unified console. For enterprises that have already invested in Okta or Entra ID, Speakeasy extends that investment into the execution layer rather than replacing it, giving IdP policy an enforcement surface at the tool and API level where the actual risk lives.

What Remains Ungoverned If Teams Treat IdP Registration as the Finish Line

IdP registration solves the identity problem. It doesn't touch the execution problem. A governed token proves who an agent is; it doesn't constrain what the agent does with the access it has been granted. Tool-level ACLs enforced at a gateway are the missing layer, and without them the governance posture is incomplete regardless of how thorough the identity work has been.

Delegation chain opacity compounds this. In multi-agent architectures where one agent calls another, OBO tokens propagate permissions in ways that are genuinely difficult to reconstruct without purpose-built tracing. XAA and similar standards address this, but coverage isn't universal. Organizations running heterogeneous agent environments will encounter delegation chains that fall outside the standards' current scope. Standards bodies are actively working to close this, and that work isn't finished. Treating it as finished is a governance assumption worth auditing explicitly.

Scope drift is the third gap. Agents accumulate OAuth scopes over time through new consent grants. Without periodic access review tied to the agent registry, scope creep produces the same over-permissioned profile that has long characterized workload identities. That was a manageable risk for static service accounts. It is a more serious one for autonomous agents capable of executing irreversible actions, where over-permissioning isn't an audit finding but a potential incident.

The governance gap Gartner identified, with a large majority of IT application leaders reporting that they lack the right structures to manage AI agents, isn't closed by standing up Entra Agent ID or Okta for AI Agents in isolation. Discovery, registration, gateway enforcement, audit logging, and revocation have to operate as an integrated discipline. Deployed as a checklist, they leave gaps. Operated as a discipline, they compound each other's effectiveness.

The enterprises making the most progress here are the ones that stopped treating AI governance as a new program and started treating it as an extension of IAM work they've already done. That reframe matters more than the tooling choices. The institutional rigor transfers; what varies is how quickly teams recognize it and act before ungoverned agent proliferation forces the issue.