Gateways

Agent Gateway instances route agent traffic between each other over encrypted DIDComm tunnels. Each gateway has a stable Decentralised Identifier that acts as its cryptographic identity. Traffic is encrypted at each hop, and no VPN or shared network segment is required. Connect two gateways →

What a gateway is

A gateway is a configuration object representing either:

• This gateway (self): the running Agent Gateway instance. There is exactly one self gateway per deployment. Its DID is generated at initialisation and cannot be changed.
• A remote gateway: a record for a remote Agent Gateway instance that this deployment communicates with. A remote gateway record holds the remote DID and transport endpoint.

Gateways are managed in the Gateways section of the dashboard.

For a complete field reference for the gateway editor, see Gateway object.

Connection points

A connection point is a configuration object that establishes a link between your gateway and a remote gateway. It contains an out-of-band (OOB) invitation URL that the remote gateway imports to create its side of the connection.

After the remote gateway imports the invitation, the initiating gateway operator approves the pending connection request. Published Access Points on your Agent Surfaces can then be routed to by the remote gateway via the fabric:// URL scheme.

For a complete field reference for connection points, see Connection point object.

Published access points

By default, all published access points on a gateway are visible to remote gateways that query for available destinations. The Publishing tab on a gateway record lets you restrict what is exposed to a specific remote gateway.

When no items are selected on the Publishing tab, all published access points are exposed. When one or more items are selected, only those access points are visible to the remote gateway.

Gateway-to-gateway connections

A gateway-to-gateway (G2G) connection is a bidirectional, encrypted tunnel between two Agent Gateway instances. Each side of the tunnel is a connection point.

In a multi-hop flow, an agent sends a request to Gateway 1 over A2A, AP2, UCP, MCP, or another supported protocol. Gateway 1 receives it on an Agent Surface Access Point configured with an external target using fabric://... to represent a destination on Gateway 2. Instead of forwarding this as a normal HTTP request, Gateway 1 wraps the request in a DIDComm v2.1 encrypted message and sends it to Gateway 2.

Gateway 2 receives the DIDComm v2.1 message, decrypts it, validates the sender DID, unwraps the original request, and forwards it to the backend service behind the target Access Point. The backend can be another agent, an MCP proxy, or a REST API. In this flow, caller identity context can transit to Gateway 2 so it can verify identity and intent, while neither agent needs to be aware of the inter-gateway transport details.

The fabric:// scheme

A fabric:// target endpoint identifies a destination on a remote gateway:

    fabric://CONNECTION_POINT_ID/REMOTE_ACCESS_POINT_ID

You do not need to enter this URL manually. When you select the via Gateway Connection routing mode, the dashboard assembles the fabric:// target from the selected connection and remote destination.

When the gateway sees a fabric:// target, it resolves the connection point to retrieve the remote gateway DID and endpoint, encrypts the request payload using DIDComm messaging, and transmits it to the remote gateway. The remote gateway decrypts the message and routes it to the destination Access Point.

How a connection is established

1. The initiating gateway generates a connection invitation from the Gateways section. This produces an OOB invitation URL and a Connection Secret.
2. The receiving gateway imports the invitation URL and secret through its dashboard, creating a connection point entry on the receiving side.
3. The initiating gateway approves the pending connection request from the receiving gateway.
4. Both gateways now have an active connection point and can route traffic between published Access Points.

For step-by-step instructions, see Connect two gateways.

Multi-hop routing use cases

• Cross-organization agent communication: Company A agents can communicate with Company B services through linked Agent Gateways, while each organization maintains independent policy enforcement and observability.
• Network boundary traversal: Agents in a private network can route through an Agent Gateway in a DMZ and onward to another Agent Gateway in a public cloud while preserving encrypted transport and identity verification at each hop.

When to use G2G routing

Use G2G routing when two agent services are owned by different organisations and neither can expose internal addresses, or when your deployment spans network boundaries such as different VPCs or cloud providers without VPN connectivity.

Do not use G2G routing for services within the same network. A direct URL target is simpler and lower latency for same-network destinations.

Trust verification in G2G

When a request arrives at the remote gateway over a DIDComm tunnel, the receiving Agent Surface can verify the sender DID against a trust registry. Configure this on the receiving surface inbound controls under Trust Registry Extension Injection (Inbound).

Verified remote identities appear on the receiving surface Identities view with a REMOTE badge. When the trust registry check passes, a VERIFIED badge is also shown.

Related

• Connect two gateways: Step-by-step instructions for generating an invitation and establishing a connection.
• Gateway reference: Field-level reference for the gateway and connection point editors.