Dynamic Trust for AI Agents

Dynamic trust establishment means that clients like AI agents (or AI agent developers) don't have to have a prior relationship with a server to securely integrate. Instead, clients can establish trust programmatically when needed. Dynamic trust establishment allows AI agents to integrate with protected APIs on demand and across trust domains.

This article provides an overview of existing standards and ongoing efforts in the OAuth community to enable dynamic trust establishment for AI agents.

Trust in OAuth

In an OAuth context, trust implies that an AI agent needs to register with the authorization server. This client registration allows the authorization server to authenticate and trust the AI agent. In essence, trust governs the policies that the authorization server applies when an AI agent requests tokens.

In many cases the safest option is static client registration. Static client registration means an administrator configures the policies for a particular AI agent in the authorization server. For example, an administrator might grant access to ChatGPT and configure a specific redirect URI, client credential and allowed scopes. However, in an AI context, static clients can limit the business reach.

Dynamic trust establishment means the client communicates its capabilities to the authorization server so that it can create and configure appropriate policies for the client automatically. In some cases, the authorization server may not persist the registration data but allow for ephemeral clients. Ephemeral clients are clients that can come and go, and change their capabilities between appearances.

When registering a client, the authorization server, among other things, stores (part of) the client capabilities called client metadata.

The Client Metadata

Clients express their capabilities (or preferences) in a JSON object called client metadata. The client metadata defines how the client expects the authorization server to communicate with it. The data, for example, can list the client's redirect URI to which the authorization server must send its responses. It can also contain client credential parameters like a link to a public key for client authentication with JWT assertions.

Clients have two options to communicate their client metadata for dynamic trust establishment in OAuth:

• Dynamic Client Registration
• Client ID Metadata

The following sections introduces them one-by-one and discusses how to establish trust with them.

Dynamic Client Registration

Dynamic Client Registration (DCR) is a protocol defined in RFC 7591 that enables clients to share their client metadata with the authorization server and have it registered. Clients send their client metadata to a dedicated endpoint at the authorization server. The authorization server validates the data and stores an entry (and policy) for each newly registered client. It returns a client ID and optionally a client secret to the client. The authorization server uses the client ID (and optional credentials) to determine its trust in the client.

Use Cases

Typical use cases for dynamic client registration are:

1. Mobile application instances register to get an installation-specific credential.
2. Developers use a developer portal or API management system to register clients with the authorization server.
3. Applications are part of an open ecosystem and should be able to register at will (e.g., open banking).

As you can see from the list, dynamic trust establishment is not a unique requirement for AI agents. You can, for example, find comparable requirements in ecosystems like open banking. Commonly, these ecosystems set up a trust framework with an accreditation body to make sure clients meet required conditions. What is new for AI agents is, that there is not necessarily such a framework that regulates the trust. Dynamic trust establishment for AI agents may be completely open.

Challenges of Dynamic Client Registration

Dynamic client registration comes with some challenges that are even more apparent with AI agents:

• Data store growth
• Multiple identifiers for the same application

As mentioned before, the authorization server creates an entry in its data store for each newly registered client which eventually leads to an unbound growth of the data store. AI agents might create multiple entries when running on different devices, e.g., desktop and mobile. Not only does this behavior add to the data store problem, it also makes auditing harder as the same AI agent application uses multiple identifiers. What's more, an open AI agent ecosystem calls for open registration.

Open registrations means that any client can register. Without any shared trust, the authorization server has no way to verify either the client or its metadata. The authorization server trusts whatever data a client provides. This anonymous registration opens up for attacks like Denial of Service (DoS) attacks or client impersonations where a malicious client registers pretending to be another client. This setup is only suitable for low sensitivity data and most enterprises should not use open registration.

The instance-specific entries are the main benefit of DCR. They allow the authorization server to govern and eventually revoke individual AI agents while not blocking others. However, applying a global policy to AI agents becomes more challenging with DCR. Therefore, the MCP specification has started to emphasize another form of establishing trust for AI agents (MCP clients) — the Client ID Metadata.

Client ID Metadata

The Client ID Metadata (CIDM) draft adds a semantic meaning to the otherwise server-specific client ID. Instead of being a simple pointer to the authorization server's policies, it also becomes a pointer to some client metadata. That is, Client ID Metadata defines the client ID to be an HTTPS URL.

Global Identifier

Using Client ID Metadata allows an AI agent to identify via an HTTPS URL. This URL serves as a globally unique identifier for that client, and eliminates the need for server-specific client IDs. It means that the AI agent can identify using the same client ID for different authorization servers (trust domains). Having a globally unique identifier for the AI agent improves auditing across trust domains and allows organizations to retrieve a holistic view of an agent's activities.

Client Metadata Discovery

Client ID Metadata enables the authorization server to discover the AI agent's client metadata from the client ID. This eliminates the need for the authorization server to store registration data for the AI agent, and for the AI agent to register before requesting tokens. Also, there is no need for the AI agent to store a client ID and client credentials for each authorization server. In other words, Client ID Metadata minimizes the operational burden for both the AI agent and the authorization server. Since the authorization server does not store the client metadata, we call such OAuth clients ephemeral clients.

Trust via URL

Client ID Metadata requires the authorization server to make outgoing calls. There's always a risk when opening firewalls and calling third-party endpoints. The Client ID Metadata URL, for example, could contain malicious code and exploits that in worst case could compromise the authorization server.

To establish trust using Client ID Metadata, the authorization server can, for example, maintain a list of approved domains, i.e., AI agents, that it trusts. Alternatively, it can have a list of domains that it explicitly disapproves. Obviously, to trust an AI agent, the authorization server also needs to be able to call the URL and validate the HTTPS certificate of the agent's Client ID Metadata URL. Practically, Client ID Metadata requires the authorization server to set up policies for an AI agent upfront, e.g., by adding them to the list of trusted AI agents or assigning them scopes.

Whether to trust a client does not only depend on how they register but also on their capabilities. One important capability regarding trust establishment is authentication. OAuth distinguishes between public and confidential clients in this context.

Public Clients

Some clients cannot reliably authenticate due to technical limitations of the environment they run in. Such clients are called public clients. Many popular AI agents operate as console or desktop clients. As a result, they cannot protect a client credential. Therefore, they classify as public clients. No matter how a public client registers, the authorization server cannot verify the identity of the client.

If you want to grant API access to AI agents that act as public clients, consider the following techniques to mitigate risks:

• Use dynamic client registration so that each user’s agent instance gets a distinct client ID and client secret.
• Use OAuth scopes to avoid exposing high sensitivity data or operations to the AI agent.
• Use strong user authentication.

AI agents can use additional techniques aimed for mitigating injection attacks through random secrets (PKCE) and temporary transaction keys (DPoP). Whenever possible, use distinct URIs per AI agent and ensure that the AI agent sends a client credential, so that the authorization server can authenticate the client.

The following example illustrates the client metadata for a public client:

{
    "client_id": "public-ai-agent",
    "client_name": "Coding Agent Extension",
    "grant_types": ["authorization_code"],
    "redirect_uris": ["http://127.0.0.1/oauth/callback"],
    "response_types": ["code"],
    "scope": "repositories/read",
    "token_endpoint_auth_method": "none"
}

Traditionally, DCR has been the method to provide public clients with credentials. The mobile application use case mentioned before is an example where DCR enables instance-specific client IDs and secrets for public clients. For clients running on platforms that support attestation (e.g., mobile applications or workloads), attestation-based client authentication provides strong security guarantees, on par with strong backend client credentials.

Confidential Clients

Confidential clients are clients that can securely store a credential like a secret, private key or assertion. Thanks to that capability they are able to authenticate at the authorization server.

There are various ways how an AI agent may authenticate:

• Client ID and secret, e.g., from Dynamic Client Registration
  • Using HTTP POST (client_secret_post)
  • Using HTTP Basic authentication (client_secret_basic),
• Self-signed JWT
  • Signed with a shared secret (client_secret_jwt)
  • Signed with a private key (private_key_jwt)
• Mutual TLS
  • With a client certificate from a trusted PKI (tls_client_auth)
  • With a self-signed client certificate (self_signed_tls_client_auth)
• Key-bound attestation with a proof of possession (attest_jwt_client_auth)
• Others (not standardized for OAuth context)
  • WIMSE Workload-to-Workload Authentication with HTTP Signatures
  • WIMSE Workload Proof Token

AI agents may receive a client ID and secret from the authorization server as part of Dynamic Client Registration and use that to authenticate. Secret-based authentication methods are not suitable for clients that use Client ID Metadata to establish a dynamic trust with the authorization server because these clients cannot securely share the secret with the authorization server. Instead, such clients should use JWTs (private_key_jwt and attest_jwt_client_auth), certificates (tls_client_auth) or other workload identities with a proof of possession mechanism to authenticate with the authorization server.

The following shows an example client metadata for a confidential client. That data tells the authorization server that this client supports self-signed JWTs for authentication and where the server can find the signature verification keys.

{
    "client_id": "https://aiagent.example/oauth/client_metadata.json",
    "client_name": "https://aiagent.example",
    "grant_types": ["authorization_code"],
    "redirect_uris": ["https://aiagent.example/oauth/callback/"],
    "response_types": ["code"],
    "scope": "trades/read",
    "token_endpoint_auth_method": "private_key_jwt",
    "jwks_uri": "https://aiagent.example/oauth/jwks.json"
}

Authentication methods based on public key cryptography are the preferred client authentication method for AI agents. They allow the AI agent to dynamically update their key material without having to update their trust with the authorization server. The metadata example shows how an AI agents can publish a jwks_uri with a public key and use the corresponding private key to authenticate with a self-signed JWT. When the client updates its key pair, the authorization server can retrieve the latest public key from the URI and verify the self-signed JWT. Key rollover is an important aspect for maintaining the security and trust.

Details like which authentication methods a client supports, how key rollover works and how verification keys get distributed, make a difference in the trust establishment. Client authentication solutions that provide a common trust anchor, such as mutual TLS, attestation-based client authentication and workload identities, are useful tools for the authorization server to protect dynamic trust establishment.

Protecting Dynamic Trust

Trust is something that requires careful consideration. If you trust any client to register with an authorization server without any restrictions, you open up for attacks targeting the APIs that the authorization server is supposed to protect. To avoid that, restrict registrations.

For example, implement approaches like the following to restrict registrations:

• Protect the registration endpoint, e.g., with mutual TLS. Use this option if you control the AI agent and if it operates in a closed ecosystem, e.g., within an enterprise and its partner organizations.
• Require assertions during registration, e.g., a software statement in the client metadata. Works for both Dynamic Client Registration and Client ID Metadata and for both public and confidential clients. Requires a trust framework for the authorization server to verify the (signed) software statement.
• List approved clients or domains. Applicable for clients using Client ID Metadata to trust only certain, known AI agents. Works for public and confidential clients.

The following sections briefly discuss protecting DCR and requiring a software statement.

Protecting Dynamic Client Registration Endpoint

The authorization server can protect the dynamic client registration endpoint by requiring an initial access token (IAT). The Architectural Overview of Dynamic Client Registration and the Dynamic Client Registration Authentication Methods get into more details. In short, there are two approaches to retrieve that initial access token:

• Client authenticates
• User authenticates

Client-Authenticated Registration

Client-authenticated registration is useful in cases where you can impose requirements on the AI agent for how to authenticate. It implies that clients need to authenticate, e.g., with a X509 certificate or self-signed JWT, to get the initial access token. With the initial access token, the AI agent can then register an instance, e.g., an MCP client.

For now, client-authenticated registration requires that the AI agent is a confidential client. However, there is a recent draft specification — Attestation-based Client Authentication — that will allow even AI agents that are public clients to authenticate.

User-Authenticated Registration

User-authenticated registration implies that the user authenticates at the authorization server and confirms client registration. The client only needs to present a client ID. Consequently, this approach is suitable for AI agents that cannot authenticate. The AI agent could, for example, use the Client ID Metadata to get an initial access token and register a user-specific instance.

The software statement adds another layer of security to the client metadata that the client presents.

Software Statement

The software statement is a JSON Web Token (JWT) containing client metadata and signed by a trusted third party. By trusting the third party, the authorization server can trust the data in the software statement. Consequently, the authorization server has a higher confidence in the client metadata being correct. Software statements thus increase the trust in the client.

Registering the correct metadata for clients is only one part of establishing trust. The other is making sure to apply correct policies to correct clients when a client actually requests a token. This is when you have to deal with client authentication, and distinguish between public and confidential clients.

Attestation-based Client Authentication

Attestation-based Client Authentication is a draft specification that introduces a new way to authenticate a client and establish trust.
It defines a way for the client to present an attestation from a trusted attestation service to prove that it is the genuine client. It does so by presenting the authorization server an attestation JWT that is bound to a public key together with a proof of possession of the corresponding private key.

AI agents running, for example, in Android, iOS or Apple Silicon, can use their hosting environment to produce cryptographically signed material that asserts the app's identity and public key. The AI agent can send the signed material to an attestation service like Google Play Integrity or Apple App Attest, to get an attestation JWT. The attestation JWT serves as an identity proof for the AI agent. It is bound to the AI agent's public key. Via the proof of possession of the corresponding private key the AI agent proves to the authorization server that it is the intended holder of the attestation JWT and a genuine app.

Attestation-based client authentication combined with client metadata enable another form of an ephemeral client. If the attestation JWT contains the client metadata then the only thing the authorization server needs to trust is the attester. There is no need for the client to host any endpoint with the client metadata nor for the authorization server to make any outbound calls.

Conclusion

Trust in OAuth ensures the authorization server applies adequate policies to a given client. It is twofold:

1. It requires the authorization server to determine what policies to apply to which client.
2. It requires the authorization server to apply the correct policies to the correct client.

The challenge of the former is to communicate the client metadata to the authorization server, and register the client. The two methods discussed in this article were Dynamic Client Registration and Client ID Metadata. Dynamic Client Registration creates a new client for each instance (e.g., MCP client, mobile and desktop app) of an AI agent, and thus allows for governing individual connections. Client ID Metadata, on the other hand, creates a globally unique identifier that the AI agent can reuse over instances and trust domains. Consequently, it improves end-to-end auditing as the same identifier points to the same AI agent.

The challenge of the second point is client authentication. Public clients normally cannot authenticate. Attestation-based client authentication solves that challenge for public clients like mobile or desktop applications, making integrations more secure.

Last updated: 2026-02-12

Judith Kahrer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Email

Subscribe

I agree to Curity's Privacy Policy

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial