Header image.

API Access Across Trust Domains

architect
On this page

Trust domains are a way to segment a zero trust architecture. They allow for controlling who can talk to who based on a trust anchor. API access across trust domains implies that an OAuth client needs to communicate with multiple authorization servers to get the appropriate access tokens to access APIs.

API access across trust domain is a common requirement for AI agents and their workflows.

Access Control Requirements for Agentic Workflows

AI agents differ from other applications in the way they interact with downstream services. AI agents, for example, determine at runtime which services to call, and they tend to aggregate multiple services from different trust domains.

AI Agents Must Discover Authorization Requirements

As part of their logic AI agents commonly need to integrate on demand with services from various trust domains. Static integrations are not feasible in this context. Instead, AI agents need to be able to dynamically discover the capabilities, endpoints, and other necessary parameters for authorization at runtime.

In this context the following standards are useful:

Discovery allows AI agents to retrieve the necessary parameters to request access tokens without having to set up integrations upfront.

Each target service bases its access control decision on the data in the access tokens. This means that each service needs to have adequate information to perform its authorization. It also means that, when AI agents pass on tasks to other systems, whether they operate in the name of a user or not, they need to maintain the related authorization information and authorization grant to avoid elevation of privileges.

AI Agents Must Maintain the Authorization Grant

Trust domains imply that services trust different token issuers. As a result, AI agents cannot simply send tokens from one trust domain to call services in another trust domain. Instead AI agents need to retrieve dedicated access tokens for each trust domain.

Downstream calls and delegated access that originate from an authorization grant need to trace back to that grant because grants are comparable to an intent. AI agents that already have received an authorization grant or access token that represent an intent, need to use the existing grant to request new access tokens. Using existing grants for requesting new access tokens provides traceability for the chain of actions an AI agent triggers.

AI Agents Must Delegate Least Privilege

New tokens must not exceed the bounds of the associated grant. Using existing grants for requesting new access tokens means that any delegated access does not surpass the agent's own permissions. When access requests travel across trust domains, it becomes crucial to maintain relevant access information.

As each trust domain has their own ontology and semantic model for authorization data, AI agents need to integrate with authorization systems in a way that allows the systems to translate authorization data from one trust domain to another, and reduce access token privileges when required. In that way, authorization systems can maintain the semantics of the authorization grant and the privileges it implies.

In cases where a user is operating the AI agent, they should not be bothered with the tasks an AI agent performs when processing a prompt. Any access across trust domains should be controlled by administrators and hidden from the user as much as possible, to keep experiences simple.

AI Agents Need to Operate Behind the Scenes

The autonomous nature of AI agents requires an alternative user experience than (other) user-facing applications. Opening the system browser to obtain tokens for the different trust domains, for example, is not an option for agentic workflows. Instead, such workflows require backend processes that allow AI agents to maintain user identities across trust domains without direct user interaction.

Using discovery of authorization requirements and maintaining authorization information while minimizing user interactions, enables some interesting AI use cases.

Example Use Cases

Increasing Outreach

AI agents are a new type of user agent that replaces the browser for consumers. Instead of investigating the web, looking and browsing through websites or navigating web applications, users rely on AI agents to not only collect information but to interact with enterprises in general. Enterprises that adapt their digital services and make them discoverable for AI agents are able to drive business from this technology.

AI agents can automatically detect and integrate with the services an enterprise offers. By enabling discovery for authorization, the integration is secured without enterprises having to rely on partnerships or painful maintenance of configuration settings in third-party apps. In addition, browser-less OAuth technologies and API-driven user interfaces allow enterprises to control the relevant user experience of their services.

SSO for AI Agents

SSO is a convenience and security feature in many organizations where employees use a single identity (account) to log in to work-related tools. Using the Identity Assertion JWT Authorization Grant, a draft that profiles the aforementioned Identity and Authorization Chaining work, SSO does not stop at the AI agent but extends to the tools and trust domains that the AI agent integrates with.

SSO for AI agents allows users to log in once to the AI agent and then have the AI agent maintain that identity in subsequent calls. Using SSO for AI agents improves security and identity governance because organizations can map authorization relevant data for a user to one identity (account) in one trust domain. They can reuse that identity and its related permissions no matter which tool (software) a user chooses to call with a service - just like you expect browser-based SSO and federated access to work across domains.

Federating Access Across Trust Domains

There are two standards that prove especially useful when federating access across trust domains:

When you combine these standards, you can create a flow that addresses the requirements for API access across trust domains. The flow is called OAuth Identity and Authorization Chaining Across Domains. The draft specification suggests a multi-step flow that allows for utilizing an existing grant across trust domains by exchanging an existing token for a JWT assertion grant.

The Role of the Authorization Grant

The JWT authorization grant is a temporary credential that eventually grants the AI agent permission to act on behalf of the user to some extent (scope, time) in a downstream trust domain. Because the grant is encoded as a JWT, it is self-contained which allows the authorization server in the downstream trust domain to retrieve relevant data, e.g., the user identifier or scope, without further integration with the issuer, the upstream authorization server.

As mentioned above, the grant is comparable to an intent. When using an existing grant (represented via the access token or ID token), to request new access tokens in a different trust domains via an intermediate grant, it is important that the intermediate grant and new access tokens don't violate the original grant. In downstream trust domains it should only ever be possible to perform actions within the "intent" even across domains.

The authorization server creating the cross-domain grant plays an important role in that context.

The Role of the Authorization Server Creating the Grant

The authorization servers in the different trust domains need to have a pre-established trust. This is because the upstream authorization server needs to be able to exchange a token for a JWT authorization grant that is valid for the downstream authorization server. In concrete terms, the upstream authorization server needs to know the identifier of the downstream authorization server and allow identity and access chaining for the associated trust domain. The downstream authorization server needs to be able to validate the grant. That is, it needs to have all the parameters, the keys and identifier, expected signature algorithms from the upstream authorization server.

As there is no direct user interaction after the user authenticates, the upstream authorization server that creates the cross-domain grant is responsible not only for authenticating users but also for end-to-end authorization across domains. This includes collecting any user consent including consent to the AI agent accessing data in other trust domains. It effectively means that the upstream authorization server takes over part of the authorization of downstream trust domains. For example, its policies define which scopes an AI agent may request for the downstream trust domain or which APIs it may access there.

Security Considerations

API access across trust domains is very convenient and so is automation. They both improve user experience. However, you always need to find a balance between convenience and security because the less you double check and verify, the easier it is for an attacker to gain access. This means, for example, that you must understand when to require additional user consent.

Human in the Loop

Even in backend processes where there is no direct user interaction, it is still possible - and in certain scenarios advisable - to collect additional consent out of band before granting access. Out-of-band interaction helps to avoid that AI agents (or other applications) perform tasks on behalf of a user that the user (or resource owner) did not intend. You can read more about approvals among Curity's resources.

For a practical demonstration, check out Curity's example about how to secure an OpenAI ChatGPT App with OpenID Connect. The example shows how to require additional input from the user via an ChatGPT app before the AI agent is allowed to perform a high-privilege action.

### Cross-Domain Access Token Design

OAuth was designed with delegation in mind which is a prerequisite for cross-domain access. OAuth done right enables an application-centric IAM where users (or authorities) delegate rights to applications. Security architectures that only cover user identities, and that neglect application identities, will be unable to implement cross-domain API access and other AI use cases in the most efficient and secure ways.

A scalable API and AI-ready infrastructure builds on access tokens that does not tell what the user is allowed to do but rather describes a user. The access token includes client attributes as well as user attributes. Consider the following factors when designing access tokens for cross-domain API access:

  • Prefer user attributes that describe a user that are relevant to multiple trust domains, rather than domain specific permissions.
  • Consider issuing custom attributes about the AI agent (client), such as a number representing your level of assurance, that it is not being impersonated by a malicious program.
  • Consider attributes to identify all authorities that led to the issuance of the access tokens and the use of transaction tokens.

Summary

To implement cross-domain API access, you need to combine newer and existing standards to discover and share authorization relevant information across trust domains. You can then enable new types of agentic use cases:

  • Externally: Broaden your service offerings by integrating with AI agents.
  • Internally: Optimize processes and offer SSO from your authorization server to other trusted domains, to extend the business reach of your services and support federated AI user experiences.
Photo of Judith Kahrer

Judith Kahrer

Product Marketing Engineer at Curity

Newsletter

Join our Newsletter

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

Newsletter

Start Free Trial

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

Start Free Trial
  1. Home
  2. Resources
  3. AI Agents Security
  4. API Access Across Trust Domains