Egress
Put an agent's outbound connections behind its own address, and let the far end confirm which one it saw.
In this section
- Connectivity TiersWhat each way of putting an agent behind its own address gives you, and what it asks of the host.
- Send Traffic From Your AddressBring up a bound egress on this host, run a job through it, and prove the far end saw the identity you expect.
- Serverless and Edge RuntimesHow a function that can only call fetch still reaches a target from its own identity, with one HTTPS hop.
- Reaching IPv4 DestinationsWhat the far end sees as the source of a connection when it speaks only the older protocol, and where the record of that connection lives.
- Egress AuthenticationWhat the proxy accepts as proof that a connection belongs to your identity, and where each credential comes from.
Egress Documentation
Outbound traffic from an agent can leave the internet from the agent's own address instead of from whatever address its host happens to have. The far end then sees a source it can look up, with no agreement and no key on its side.
whisper connect --agent shipping-bot
whisper run curl -s https://rdap.whisper.online/egress-ip
{"ip":"2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478"}
There is more than one way to get there, and they differ in what they ask of the host: Connectivity Tiers lays them side by side and says which one a rootless container, a bare-metal host or a browser automation runner should take. The job itself, from install to a proven source address, is Send Traffic From Your Address.
The credential the proxy accepts, and what it is bound to, is on Egress Authentication. Read it before you put a bearer in a deployment secret.
Two cases need their own page. A function runtime that offers fetch and no raw sockets
goes through an HTTPS relay instead of a tunnel, covered in
Serverless and Edge Runtimes. And a destination that
answers only on the older protocol sees something different from one that speaks IPv6,
which Reaching IPv4 Destinations sets out.