How Okta is securing agent identity with Client ID Metadata Documents (CIMD)

Agentic AI is changing what “a client” means in your identity architecture. A few years ago, the clients talking to your APIs were mostly a handful of first-party apps and a few trusted third-party integrations—each set up once by a human through an admin console. Today, that population looks very different: AI agents, Model Context Protocol (MCP) servers, and autonomous workloads are being spun up, cloned, and retired by other software, often by vendors you don’t directly control, at a pace no admin console was built to handle.

To solve this, Okta introduced two capabilities now available to all customers running on Okta Identity Engine: 

1. Client ID Metadata Document (CIMD) support for OAuth 2.0: A general-purpose capability, it lets any OAuth 2.0 client—agent or not—authenticate by publishing information about itself at a URL, instead of going through a manual registration step for every org it needs to talk to. 
2. CIMD-based registration for AI agents: Applies that same model specifically to how AI agents get their identity in Okta.

Here’s what that means, why it matters, and why it doesn’t come at the cost of security.

Why traditional OAuth registration fails for agentic AI 

Traditional OAuth client registration assumes a relatively small, relatively static population of clients. Either an administrator manually creates an OAuth client in a console (name, redirect URIs, grant types, generate a secret), or the client uses dynamic client registration (RFC 7591) to request that the authorization server create one programmatically. Either way, the client ends up with an authorization-server-issued identity—a client_id and usually a secret—that lives in that server’s database.

That model works fine when you’re registering a handful of internal apps. It gets expensive fast when:

• An agent platform or MCP server needs to be usable across many customer orgs, each requiring its own registration step
• Agent instances are created and destroyed programmatically, faster than a human admin can keep up with
• The entity that “owns” the agent’s identity isn’t the org admin at all—it’s the agent vendor, who already maintains metadata about their software somewhere

In short: The registration step itself—not the authentication that follows it—has become the bottleneck for workload and agent identity at scale.

How CIMD works: Dynamic metadata resolution

CIMD takes a different approach, drawn from an emerging pattern in the OAuth ecosystem, and applies to any OAuth 2.0 client in Okta—not just AI agents. Instead of pushing metadata to the authorization server ahead of time, CIMD flips the architecture to a publish once, pull on demand registration model: 

• URL as client identity: Instead of registering a client and receiving an opaque client_id back, the client_id is an HTTPS URL that the client (or its vendor) already controls.
• Dynamic metadata fetching: When an authentication request arrives, Okta dereferences that URL to receive a JSON document describing the client—the same kind of metadata you’d normally submit during dynamic client registration: redirect URIs, supported grant types, a JSON Web Key set for signature verification, the token endpoint authentication method, and so on. 
• Caching and token issuance: When a request comes in using that URL as its client_id, Okta fetches, validates, and caches the document on demand, and uses it to resolve the client’s identity—no prior registration call required.

For an agent vendor serving thousands of customer orgs, that’s the difference between thousands of registration calls and one hosted JSON file.

Is CIMD secure? How Okta enforces Zero Trust controls

It’s worth being precise here because “the client describes itself” can sound as if it removes a security control rather than relocating one. It doesn’t. Okta doesn’t treat an arbitrary URL as a valid client_id just because it looks right. Okta enforces administrative control at each layer: 

• Admin allowlist pre-check: Before Okta even fetches a CIMD URL, it checks that URL against an allowlist rule explicitly configured by the org admin. 
• Exact URL matching: Documents must self-claim the exact URL—the admin lists the precise CIMD URL this org trusts. If there’s no matching rule, Okta never makes a request. The admin, not the internet, decides which CIMD-based identities this org trusts.
• Proof-of-possession (DPoP and mTLS): Admins can go further than a simple allowlist, too. Okta supports attaching additional requirements to a CIMD entry, so a fetched document can be required to satisfy specific policy conditions—for example, declaring support for a particular proof-of-possession mechanism—before it’s accepted as valid. And the document itself can declare that any tokens issued to this client must be bound to demonstrating proof-of-possession (DPoP) or mutual TLS, meaning the proof-of-possession requirement travels with the self-asserted identity rather than being configured separately out-of-band.

The result is a model where the convenience is in not having to pre-register every client, while the control stays exactly where it’s always been: with the organization that decides what it trusts.

It’s worth being clear about scope here: CIMD support isn’t agent-specific. Any custom OpenID Connect (OIDC) app in Okta can be configured as a CIMD client today—once an admin allows its URL, that app authenticates and receives tokens through the same OAuth 2.0 flows every other client uses, with no AI agent involved at all. AI agent registration, covered next, is simply the newest purpose-built implementation of that same underlying capability.

Securing the next generation of AI agents

CIMD support for OAuth 2.0 is the foundation. CIMD-based registration for AI agents makes it directly usable with Okta’s agent identity model.

When registering an AI agent with Okta, you can now back that agent’s identity with a CIMD URL instead of asking Okta to mint a traditional OAuth client. In practice, this supports two flows: registering a brand-new agent identity backed by a CIMD document, or pointing a new agent registration to an existing CIMD-backed app to adopt that same published identity.

This maps naturally onto how agent platforms and MCP servers already operate. These platforms typically already publish metadata describing their software—it’s part of how they’re built to be discoverable and interoperable. CIMD lets Okta consume that existing metadata directly as the basis for a trusted identity, rather than asking the vendor to additionally complete a separate registration flow for every customer org that wants to use their agent.

Eliminating static client secrets

CIMD sidesteps a quieter problem with traditional registration: client secrets. An Okta-minted OAuth client typically comes with a secret that must be provisioned, stored securely, and eventually rotated—one more long-lived credential to manage per agent. A CIMD-backed agent identity doesn’t need one; authentication relies on the keys and metadata published in the document itself, combined with proof-of-possession mechanisms like mutual TLS or signed assertions.

Identity revocation and access control

And because the binding between a CIMD identity and an agent is one-to-one, there’s no ambiguity about which agent a given identity represents—attempts to reuse an identity that’s already bound to another agent are rejected outright. Disabling the agent on Okta’s side immediately revokes its tokens, regardless of what the externally hosted metadata document still says. Identity resolution and lifecycle control are two separate layers, and both stay under the org’s control.

More broadly, this changes who owns what in the authentication relationship. Agent builders retain control of their own keys and rotation schedule on their own infrastructure—no more filing a ticket with IT every time a credential needs to be updated. Admins, in turn, step out of per-credential key management and into trust governance: deciding which agent URLs to allowlist, and retaining the ability to cut off an agent’s access in real time if needed. That shift is also what makes this a practical foundation for larger agent architectures—including Okta’s own Agent Gateway and integrations with tools like Anthropic’s Claude Code and Salesforce Agentforce—where the number of distinct agent identities an org needs to trust can grow well beyond what manual registration was ever designed to handle.

A robust framework for agent identity

It’s reasonable to be skeptical of any model in which an authorization server fetches and trusts a document hosted elsewhere. The design here addresses the obvious failure modes directly:

• Allowlist before fetch: Okta checks for an admin-configured match before making any outbound request—an unregistered URL never gets dereferenced in the first place.
• The document must agree with the URL: The metadata fetched from a given URL must claim that same URL as its own client_id. A document can’t claim to represent a different client than the one it was fetched for.
• HTTPS only, with no shortcuts: CIMD URLs are validated structurally—no embedded credentials, no fragments, no path tricks that could be used to confuse which identity is actually being resolved.
• Bounded caching: Documents are cached with limited lifetimes, so there’s a hard ceiling on how often—and how fast—any single endpoint can be reached through Okta.
• Identity isn’t authorization: Resolving a CIMD document tells Okta who a client claims to be. It says nothing about what that client is allowed to do. Admins still have to explicitly connect an agent to the specific resources and APIs it’s permitted to reach—a validly identified agent doesn’t get implicit access to anything.

Put simply: Self-asserted identity is still identity Okta chooses to trust, on terms the org sets, with the same proof-of-possession and access-control guarantees as any other OAuth client.

Start building with CIMD today

CIMD support for OAuth 2.0 and CIMD-based registration for AI agents are now available to all customer orgs on Okta Identity Engine. Learn more about CIMD and how this feature works in your org.

As agentic AI continues to reshape what “a client” looks like in your environment, this is one piece of a broader effort at Okta to make sure that shift doesn’t come at the expense of knowing—and controlling—exactly who’s connecting to your systems.

These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. Any features or services that are on the roadmap or available in beta, early access or similar non-generally available release status may not be developed, released or made generally available, or may have different features, functionalities, technologies, configurations, and/or documentation at the time of release, if any. © 2026 Okta, Inc. and/or its affiliates.