Register an A2A agent hosted outside UiPath in Agent Gateway and configure authentication for calls to it.

Outbound A2A is the platform calling an agent hosted outside UiPath, either directly or as a tool inside a UiPath agent. You register the agent once in Agent Gateway > A2A Agents, and UiPath acts as a governed gateway in front of it.

Because there are two hops, there are two independent authentications: the caller authenticates to UiPath, and UiPath authenticates separately to the remote agent. Neither side sees the other's credentials.

Everything specific to that second hop applies only to this direction: Integration Service connections, configured headers, Orchestrator asset references, and per-user connections.

Registering an agent makes an A2A agent hosted outside UiPath callable from the platform. Agent Gateway stores the agent's card and credentials, gives it a stable UiPath URL, and from then on any A2A-capable consumer on the platform reaches the agent through that URL.

Once registered, the agent behaves like any other deployed artifact in UiPath: it lives in a folder, folder permissions govern who can call it, guardrails can screen its messages, calls appear in Traces, and changes to it are audited.

A registered A2A agent can also be consumed by external clients. They call the UiPath-exposed A2A URL with a UiPath token, exactly as they would for a UiPath-hosted agent. For the accepted tokens and the permissions required, check Authentication.

Result: Agent Gateway fetches the agent's card and caches it. The agent appears in the A2A Agents list. If the fetch fails, the save fails with the fetch error, and nothing is stored until the card is readable.

The registered agent lives at:

You can copy this URL from the A2A Agents list. An external client uses it exactly as it would any A2A agent: Agent Gateway serves the agent's card at <that URL>/.well-known/agent-card.json, rewritten so that every advertised endpoint points at the gateway instead of the upstream host, and the client authenticates to UiPath rather than to the upstream agent. The upstream's own authentication scheme never leaks.

On every call, Agent Gateway validates the caller's UiPath token and folder access, which requires the View permission on MCP Servers, since A2A shares the MCP Servers permission set. It then screens the request against the agent's guardrails, strips the caller's Authorization header, injects the configured credentials, and streams the response back untouched, including SSE (Server-Sent Events). Messages are not parsed or rewritten, so both A2A 0.3 and 1.0 clients work, and a client selects a version with the A2A-Version header. Calls appear in Traces.

Calling an A2A agent through UiPath involves two separate authentications, and they're independent of each other. UiPath authenticates to the agent it forwards the request to, using credentials configured once when the agent is registered. The caller authenticates to UiPath separately, with an ordinary platform token. Neither side sees the other's credentials.

Registering an agent configures two things. The agent card tells UiPath where to send messages. Credentials let UiPath authenticate to the agent on every call, since the caller's token is never forwarded. Credentials can be supplied as an Integration Service connection, as headers, or as both.

An agent card is the JSON document an A2A agent publishes to describe itself: its name, its skills, and the endpoint that accepts JSON-RPC (JSON Remote Procedure Call) messages. UiPath can't route a call without one, so every registration persists the agent's card as the routing and authentication record.

Registering an agent requires the Create permission on MCP Servers in the target folder. Remote A2A agents share the MCP Servers permission set, so the MCP Servers permissions govern A2A as well.

Enter the URL of the agent's card, usually the agent's base URL followed by /.well-known/agent-card.json. UiPath fetches it at that moment, using the credentials configured on the same screen: the attached connection, if there is one, or the configured headers otherwise. Asset references in those headers are resolved for this request too, so a card behind an API key stored in Orchestrator can be read without pasting the key.

The URL is checked against SSRF (Server-Side Request Forgery) protection before the request is made, unless the agent is reached through the relay. If UiPath can't reach the address, or the response isn't a success, the agent isn't created. This is the only option that supports Refresh card later.

Paste the card document directly. UiPath makes no outbound request at all, so no credentials are needed at registration time, and the SSRF check doesn't apply. Use this option for an agent that isn't reachable from UiPath at registration time, or whose card isn't served at a public address. If both a URL and pasted JSON are supplied, the pasted JSON is used and no fetch happens.

However the card arrives, UiPath accepts it only if it's a JSON object that advertises a usable HTTP or HTTPS JSON-RPC endpoint, through the v0.3 url field or the v1.0 supportedInterfaces list. A card without one is rejected at registration rather than at call time.

The stored card isn't re-fetched on every call, so a card that changes upstream doesn't update on its own. Refresh card fetches it again, requires the Edit permission on MCP Servers, and requires a card URL: an agent registered by pasting JSON has none, and the refresh is refused.

Attaching a connection to the agent means UiPath retrieves a fresh bearer token from it on every call. This is the better option for any agent whose credentials expire, since nothing has to be rotated by hand. The connection is used together with the folder it belongs to; if that folder is missing, the call fails rather than falling back to another folder or to a configured header.

Alternatively, configure the headers the agent expects as name and value pairs. The common case is Authorization: Bearer <your-api-key>. Headers are stored encrypted and masked when read back, so a secret pasted once isn't visible afterward.

If a connection is attached, it provides the Authorization header, and any Authorization header configured as well is ignored rather than merely overwritten: the configured line is removed before asset references are resolved, so a header pointing at an asset isn't even looked up. Every other configured header is still sent. The same precedence applies to the card fetch at registration time.

Individual users can attach a connection of their own through User configurations on the agent's row, which requires the Edit permission on Connections. When the agent is called, the connection is selected in this order:

The connection is chosen for whatever identity the token represents. On a scheduled or unattended run, that identity isn't the person who built or scheduled the agent, so a connection attached under someone's own user isn't used there. If an agent must be reachable from unattended runs, give it a default connection instead of relying on per-user ones.

User configurations also shows the state of each connection:

Instead of pasting a secret into a header, give the header a value in the form %ASSETS/AssetName%. UiPath resolves it to the asset's value before sending the request, reading the asset from the agent's folder under the calling identity. If the asset can't be read, the call fails rather than forwarding the unresolved placeholder.

Text, Secret, Bool, Integer, Credential, and Windows Credential assets are supported; Credential and Windows Credential assets resolve to the password value. Key-value-list assets are rejected, since one header value must resolve to one string. The resolved value is forwarded to the remote agent as the configured header, so use asset-backed headers only for endpoints you trust with those secrets.

An agent that runs inside a private network with no inbound firewall ports is reached through the relay: UiPath sends the request to a relay server, and a relay client inside the network collects it and forwards it to the agent. The relay changes how UiPath reaches the agent, not how it authenticates to it: the connection, the headers, their precedence, and asset references all behave exactly as described above. The SSRF check doesn't apply on the call or the card fetch, since the request isn't sent to a public address.

Two kinds of caller reach a registered remote agent. A UiPath client, such as a UiPath agent or a Maestro flow, uses the agent as a tool, and the platform resolves the address, the token, and the protocol version at run time. A direct HTTP client calls the agent's URL itself and has to supply all three. Both authenticate to UiPath the same way; the rest of this section matters only when calling directly.

Every request carries a bearer token in the Authorization header. Nothing is carried forward between turns: each message in a conversation is authenticated on its own.

A2A uses the same tokens as the rest of the platform.

For how to create each one, check MCP Server authentication. A2A agents and MCP Servers are validated by the same pipeline, so any token that works for an MCP Server also works for an A2A agent. The one exception is the MCP OAuth flow, which only MCP endpoints support, since it depends on discovery metadata that A2A agents don't publish.

A registered remote agent lives at:

Its agent card is at the same address followed by /.well-known/agent-card.json. Get the URL from Agent Gateway > A2A Agents by selecting Copy URL on the agent's row, rather than assembling it by hand: the folder key is a GUID (Globally Unique Identifier) rather than a folder name, and the slug isn't the display name.

Remote A2A agents support A2A v0.3 and v1.0, selected with the A2A-Version request header:

The same header applies when requesting the agent card, and determines which version of the card UiPath returns. UiPath forwards a request only to an endpoint that matches the requested version; it doesn't fall back to another version, since that would send the remote agent a message in a wire format it doesn't understand. If the stored agent card publishes no JSON-RPC endpoint for that version, the request is rejected and the version is named in the response.

Three things are stopped at the boundary:

For the errors you're most likely to meet and how to resolve them, check Test and troubleshoot A2A. Its Outbound section covers the failures on this path.

For the opposite direction, where an external client calls an agent you deployed, check Inbound (external to UiPath).