Import A2A agents from Agent Registry

As an administrator of Gemini Enterprise, you can add an A2A agent from Agent Registry to a Gemini Enterprise app.

You can apply access control policies to traffic through Agent Gateway. These policies let you enforce egress governance to control traffic to agents.

About A2A agents and Agent Registry

Agent2Agent (A2A) Protocol is an open communication protocol and a universal language for agents. The protocol enables agents from different builders and platforms to discover each other, collaborate, and securely delegate tasks.

Agent Registry is a centralized, queryable catalog that acts as the single source of truth for discovering, tracking, and managing A2A agents, endpoints, and MCP servers.

The A2A agents in the registry can be custom agents built by you and your colleagues and deployed on various runtimes such as Agent Runtime on Gemini Enterprise Agent Platform, Cloud Run or Google Kubernetes Engine (GKE). These agents can also be agents built in our Google products, such as Google Workspace.

You can associate the agents in Agent Registry with your Gemini Enterprise apps. This makes the agents available to the app's end users.

About Agent Gateway

Agent Gateway is the managed regional networking component of Agent Platform that acts as the traffic controller and runtime policy enforcement point for A2A agents, MCP servers, and endpoints. It secures and governs connectivity: between clients and A2A agents; A2A agents and backend tools; or A2A agents and other agents.

Before you can associate A2A agents with your Gemini Enterprise apps, you need to have set up an Agent Gateway through which agent traffic can be routed. See Before you begin below.

Regional constraints for the registry, gateway, and app

To ensure compliance with data residency requirements, both Agent Registry and Agent Gateway resources are project-and-region-specific.

A Agent Gateway must be configured to associate with a Agent Registry that is in a region compatible with the Gemini Enterprise app's operational region. This prevents violations of data residency conventions. For example, a Gemini Enterprise app created in the US region must use an Agent Gateway configured with a US-regional Agent Registry, not a global one.

For Gemini Enterprise apps, the regional alignment is strictly enforced through a specific binding process:

• The Gemini Enterprise app must bind only to an Agent Gateway located within one of the allowed regions for that app.

• The selected Agent Gateway must be associated with an Agent Registry. This Agent Registry must also be located in the same specific region as the Agent Gateway and the app.

• This means the three components (app, gateway, and registry) must be regionally aligned. The table below provides the specific region mappings:

Gemini Enterprise app location	Agent Gateway location	Agent Registry location
global	us-central1	us-central1, us, or global
us	us-central1	us-central1 or us
eu	europe-west1	europe-west1 or eu

Limitations

The following limitations apply when you import agents from Agent Registry:

• You can only discover and import agents from Agent Registry if the registry is associated with the Agent Gateway set up for your Gemini Enterprise app.

• You can apply governance policies only to agents residing within the single registry associated with the Agent Gateway.

• Direct communication between Gemini Enterprise agents, or between a Gemini Enterprise agent and a Gemini Enterprise data connector (including MCP-based connectors such as the custom MCP server) doesn't trigger Agent Gateway policy enforcement.

Before you begin

Before you begin, make sure you've completed the following prerequisites:

• You have the Gemini Enterprise Admin role.

• You've set up a gateway to route agent traffic through Agent Gateway. For more information, see Route Gemini Enterprise traffic through Agent Gateway.

Import agents from Agent Registry to a Gemini Enterprise app

Importing an A2A agent from Agent Registry into your Gemini Enterprise app makes the agent available to the app's end users.

Important: When you configure, and allow your End Users to access, an agent imported from Agent Registry, their query string — which may be rewritten based on prior conversation context — and tool parameters may be sent to the agent (and to any tools or MCP servers the agent invokes), and those systems may be able to link this data with their identity. Data in such systems is subject to the agent provider's Terms of Service and Privacy Policy.

Console

To import an agent from Agent Registry to a Gemini Enterprise app, do the following:

1. In the Google Cloud console, go to the Gemini Enterprise page.

   Gemini Enterprise

2. Click the name of the app that you want to associate an A2A agent with.

3. Click Agents.

4. Click + Add agents, and select Add from Agent Registry.

5. Find the agent that you want to add, and click Add agent.

6. Review the agent details, and click Next.

7. Do one of the following:

   • Review or enter the Provider credentials and Additional details, and click Finish.

     Field	Description
     Client ID	The unique identifier of the OAuth application that you registered with your identity provider to represent Gemini Enterprise.
     Client secret	The confidential key associated with the OAuth application that you registered with your identity provider to represent Gemini Enterprise.
     Authorization URL	The URL that users use to authorize Gemini Enterprise to access the agent. For example, https://accounts.google.com/o/oauth2/v2/auth?client_id=123...abc.apps.googleusercontent&redirect_uri=https%3A%2F%2Fvertexaisearch.cloud.google.com%2Foauth-redirect&oauth-redirect&include_granted_scopes=true&response_type=code&access_type=offline&prompt=consent. Note: Make sure that your OAuth app has this redirect URI: https://vertexaisearch.cloud.google.com/oauth-redirect
     Token URL	The endpoint used to exchange the authorization code for an access token. For example, if the agent is hosted by Google, the token URL is https://oauth2.googleapis.com/token.
     Scopes	The permissions that define what actions Gemini Enterprise can perform on behalf of a user, or what data it can access. Gemini Enterprise requests these scopes during user authorization. For example, https://www.googleapis.com/auth/cloud-platform. When you specify scopes, consider the following: Provide a space-separated list of scopes. For example: read write. Ensure the scopes are sufficient to let the user sign in and use the agent.
     PKCE verification enabled	Select this if Proof Key for Code Exchange is required by the agent.

• If the agent is publicly available or if permission for a runtime already exists, click Skip & Finish.

As soon as it's added, the agent becomes available to the app's end users.

Set up and apply egress governance policies

Using Agent Gateway, you can assess and apply semantic and IAM control policies to egress agent traffic. You can create granular egress policies to manage agent-to-agent access for your A2A agents.

You define allow and deny rules restricting an agent's access to specific entries within Agent Registry.

To create and apply egress governance rules to agents, do one of the following:

• Create IAM agent policies

• Configure semantic governance policies

What's next

• Test the agent