# Private network connectivity

> Reach internal services and partner systems without exposing an endpoint to the public internet or standing up a VPN.

Strict network isolation and agent reach usually pull in opposite directions. Internal services must stay off the public internet, yet your agents still need to call them, and sometimes reach a partner’s systems too. Opening inbound ports or building a site-to-site VPN for every integration is slow, costly, and widens the attack surface.

## What you can do

- Keep internal services unexposed so that agents reach them through the gateway instead of over a public endpoint.

- Connect two gateways over an end-to-end encrypted DIDComm tunnel so that no VPN or shared network segment is required.

- Establish the link with an out-of-band invitation and an approval step so that a connection forms only between parties that both consent.

- Route to a remote access point with a fabric:// target so that a caller reaches a service in another network or organisation.

- Verify a remote caller against a trust registry so that only participants you trust can proceed.

## How it works

Each gateway has a stable Decentralised Identifier (DID) that acts as its cryptographic identity. Two gateways form a connection point by exchanging an out-of-band invitation, a shared link plus a secret; the receiving side imports it and the initiating side approves the pending connection, after which both sides show a connected status. Only the access points you publish are visible to a remote gateway, so you control exactly what is reachable.

Once connected, a request to a fabric:// address is packaged into a DIDComm message that only the recipient gateway can decrypt and that is authenticated by the sender’s DID, then carried to the far gateway, unwrapped, and forwarded to the internal service. Because gateways reach each other through a mediator over outbound connections, neither side opens an inbound port. A surface can add a Trust Check that verifies the remote caller’s DID against a trust registry before the request is allowed to proceed.

If the caller’s DID fails the trust check, or targets an access point you have not published, the request is refused at the receiving gateway before it reaches the internal service.

## Related

- [Connect two gateways](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/connect-gateways.md): Step-by-step guide to establishing a connection over encrypted DIDComm tunnels.

- [Gateways](/products/affinidi-trust-fabric/agent-gateway/concepts/connections/gateways.md): How connection points, published access points, and fabric:// routing work.

- [DIDComm messaging](/products/affinidi-trust-fabric/agent-gateway/concepts/protocols/didcomm.md): The encrypted, sender-authenticated transport and the mediator model behind the tunnel.

- [G2G authentication and routing](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/g2g-authentication-and-routing.md): Configure credentials, policy, and fabric:// endpoints for remote requests.