Skip to content
Network & DNS
Skip navigation

Egress Authentication

What the proxy accepts as proof that a connection belongs to your identity, and where each credential comes from.

Published

On this page (10)

Egress Authentication Documentation

Every credential on this page comes back from one call, op:connect, or from the whisper connect that wraps it. Nothing here is typed by hand.

The egress bearer

An opaque token of the form et_..., minted when you request connectivity. It is the password half of every proxy form below. Treat it exactly as you would a password: put it in a secret store, keep it out of command arguments and logs, and do not paste it into a support thread.

What the bearer is bound to

The token is scoped to the agent's own address. Presented from anywhere else it is refused, so a leaked bearer does not let a third party borrow your identity from their own host.

The proxy forms

op:connect returns the strings you use, so you never assemble them yourself.

FieldShapeUse
connection_stringsocks5h://w:<token>@connect.whisper.online:443any client that speaks SOCKS5
http_proxyhttps://w:<token>@egress.whisper.onlineany client that speaks HTTP CONNECT
socks5_endpointhost and port onlya client that takes the credential separately

The username is the literal w, not your agent's name.

The header form

A client that will not accept credentials inside a URL can send the bearer as a header on the CONNECT request instead:

text
Proxy-Authorization: Bearer et_...

Take the host from the response

Read connection_string, http_proxy or wireguard_config out of the call and hand that to your client. A hostname you copied into a config file once will outlive the arrangement it described.

bash
whisper connect --agent shipping-bot --json

The routed tier's key material

For the routed tier the response carries server_public_key, endpoint, dns and a ready wireguard_config instead of a proxy string. When whisper connect brings the tunnel up, the client key is generated on the host and never leaves it. When you build the config yourself, send your own public_key on the call and keep the private half.

Monitor tokens

whisper token mints a separate read-only token for an agent, also of the et_ form, for a dashboard or a watcher that should read activity and change nothing. It is sent as Authorization: Bearer, which is what the CLI's --bearer flag does. Retire one with whisper token --revoke.

The keyless source check

The echo takes no credential at all, which is why it can prove the source to someone who has no account with you:

bash
curl -s https://rdap.whisper.online/egress-ip
{"ip":"2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478"}

Withdrawing access

Retiring a monitor token is whisper token --revoke. Cutting the identity itself, which takes the address, its DNS records and its egress with it, is Revoke an Identity. The two are different decisions: one ends a reader's access, the other ends the agent.

The key that may ask

Requesting connectivity is a keyed call, and the key needs the connect scope. The scope table lives on Keys and Scopes, and the call itself on Request Connectivity.