# Let agents work across companies

> Let your agents work with a partner company's agents, with each side able to verify who it is dealing with instead of trusting the other's network.

Your partners are deploying agents too, and sooner or later yours need to call theirs. A shared API key or a VPN tells the other side only that a request came from your network. It does not say which agent sent it, on whose behalf, or whether your own rules allowed it. Each company also runs its own identity provider and its own policies, and neither will hand control of them to the other.

## What you can do

- Connect your gateway to a partner’s gateway over an encrypted DIDComm tunnel so that agents reach each other’s services without a VPN or a shared network.

- Send a signed presentation of the calling agent’s identity, and of the caller it acts for, with each request so that the partner verifies who is asking instead of trusting your network.

- Enforce each company’s own policies on its own gateway so that you decide what leaves your side and the partner decides what enters theirs.

- Check a remote gateway or agent against a trust registry so that only participants recognised in your trust network can proceed.

- Choose which of your surfaces each partner gateway can see so that a partner discovers only the services you have chosen to share.

- Record each exchange in the audit log on both gateways so that either company can show what crossed the boundary and why.

## How it works

The two companies connect their gateways once. One operator shares a connection point’s out-of-band invitation, the partner imports it with Add Gateway, and the inviting operator approves the pending request. Each side then chooses what the other can discover. On your gateway, the partner’s gateway record has a Publishing tab, where you select which of your surfaces the partner sees when it asks what is available.

To call the partner, a Transit Point on one of your surfaces sets its Endpoint Type to via Gateway Connection and picks a surface on the partner’s gateway. Your gateway wraps each request in a DIDComm v2.1 message, encrypted for the partner’s gateway and authenticated as coming from your gateway’s DID. The partner therefore knows which gateway sent it, without relying on where the traffic came from.

Identity travels with the request. With a Workload Binding element on that Transit Point, your gateway signs a Verifiable Presentation (VP) for each request. The VP carries the calling agent’s DID, the allowlisted claims of the caller it acts for, a one-way hash of that caller’s identity, and a flag showing it acted on that caller’s behalf. The partner’s gateway verifies the signature and passes the result to its own OPA policies as trusted input. Those policies can then require, for example, that the caller came from an approved department. By default the partner relies on your gateway’s attestation of the caller. With Chain caller-supplied credentials turned on, the presentation also embeds the caller’s own verifiable credential, so the partner can verify the whole chain itself.

A Trust Check element can also query a trust registry, for example to confirm that the sending gateway’s DID is a recognised member of your trust network. To accept only the agents a partner has recorded in a shared trust registry, see [Verify agents across organisations with a trust registry](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/verify-agents-across-organisations-with-a-trust-registry.md).

Neither company gives up control. Your gateway’s policies decide what may leave, the partner’s decide what may enter, and each side keeps its own identity provider. While VP Auditing is on in Settings › Security, each gateway records the policy decisions, trust checks, and presentations it sent or received, so both companies hold their own record of every exchange.

When the presentation is missing or fails verification, the partner’s policies see the caller as unverified and can deny the request before it reaches the service.

Credentials that the partner’s surface sends to its own Target stay under the partner’s control. That surface uses its credential bindings on your request only for a caller it verified itself, and it refuses with 403 a request that would use a per-user grant, such as a user’s own OAuth token.

## 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 an encrypted DIDComm tunnel.

- [Workload binding](/products/affinidi-trust-fabric/agent-gateway/concepts/workload-binding.md): What the signed presentation carries and how the receiving gateway verifies it.

- [Trust registries](/products/affinidi-trust-fabric/agent-gateway/concepts/connections/trust-registry.md): How the gateway queries a trust registry and passes the verdict to policy.

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

- [Audit log](/products/affinidi-trust-fabric/agent-gateway/concepts/audit-log.md): The record of policy decisions, trust checks, and presentations on each gateway.