Maintain network isolation with VPC peering

Compliance, security, and data residency rules often require internal traffic to stay on private networks. Yet agents need to reach MCP servers, databases, internal APIs, and AI services that sit in different networks, clouds, or data centres. Opening those systems to the public internet, or building a VPN for every integration, widens the attack surface and slows down every new connection.

What you can do

• Reach MCP servers, internal APIs, and other services by their private network addresses so that those services never need a public endpoint.
• Reach services in a peered AWS VPC the same way as services in the gateway’s own network so that peering extends what agents can reach without exposing those services publicly.
• Connect gateways in different networks, clouds, or companies over an encrypted DIDComm tunnel so that no VPN or shared network segment is needed between them.
• Run the gateway as an Affinidi-managed appliance or as a container in your own infrastructure so that it sits in the network your rules require.
• Run the gateway yourself from the open-source repository so that it stays inside your own cloud account or data centre.

How it works

A surface reaches its target by private address. A Direct URL target, or an MCP proxy’s Base URL, can point at an address inside your private network, such as http://orders.internal:8080, so the service never needs a public endpoint. This works for any address the gateway’s own network can route to. A gateway that runs outside your network, such as an Affinidi-managed appliance, reaches your private services through a peering connection or a gateway-to-gateway tunnel. Cloud metadata endpoints are always blocked as targets, so a misconfigured target cannot be used to read the cloud instance’s credentials.

Agent Gateway supports VPC peering on AWS. Peering is a connection between two cloud networks, so it is set up at the network level rather than in the gateway’s dashboard. Once the gateway’s network and a service’s network are peered, the gateway reaches that service by its private address, exactly as it reaches a service in its own network.

Between networks that are not peered, including other clouds and other companies, two gateways connect over an encrypted DIDComm v2.1 tunnel. Each gateway keeps an outbound connection to its DIDComm mediator, which relays the messages, so neither gateway needs an inbound port for the tunnel and the services behind them stay private. Each gateway’s DID document must still be reachable over HTTPS, because the other side resolves it to verify which gateway it is connecting to. On the receiving side, a Trust Check can verify the remote gateway’s DID against a trust registry, and the surface’s own policy decides what may enter.

The gateway runs as an appliance managed by Affinidi and administered through the dashboard, or as a container image you run in your own cloud account or data centre, built from the open-source Agent Gateway repository. Wherever it runs, it sits in the request path in the same way, so the deployment choice never changes how traffic is governed.

Related

• Connect two gateways: Step-by-step guide to establishing a connection over an encrypted DIDComm tunnel.
• DIDComm messaging: The encrypted transport, the mediator model, and what must be publicly reachable.
• Gateways: How connection points and gateway-to-gateway routing work across network zones.
• Architecture: How the gateway’s layers and components fit together across deployment models.
• Deploy Agent Gateway appliance: Provision a managed instance through the Affinidi Portal.
• Agent Gateway on GitHub: The open-source repository for running a self-hosted gateway.