East-West Reachability

East-west traffic is agent to agent and service to service: a build runner reaching a registry, a worker reaching a database, one agent calling another's API. It is the traffic a fleet generates on its own, as distinct from a person reaching one machine, and it is the traffic Whalenet is built to govern.

Four questions are answered in order, and the first one that settles the matter settles it.

Is the destination one of your nodes? If it is not, this is not east-west at all. A connection to an address outside your fleet leaves through egress, where your resolver and connectivity policy apply instead: see send traffic from your address.

Does the destination belong to the same owner? Tenancy is evaluated first, and it is evaluated whether or not you have published anything. Another customer's agent cannot reach yours, and yours cannot reach theirs. This is the one boundary you cannot widen, and it is why withdrawing your own document is safe.

Is the destination on your roster, and admitted? A node that has been minted but is awaiting admission still holds its /128, resolves, publishes its name and reaches the internet. Reachability to its siblings is the one thing that waits. A node that was never minted, or whose identity has been withdrawn, is simply not on the roster. Approval and holds covers both states and how to move a node between them.

Does one of your grants match? Now the access document is consulted. The first matching grant wins, and its where clause, if it has one, is evaluated once for the connection. With no document published, tenancy alone governs, which still stops another customer's agent reaching yours but narrows nothing inside your own fleet.

Ask before you send

Both reads answer from the same compiled artifact the connection path itself reads, so neither is a second interpretation of the file you wrote.

whisper whale acl test group:sre tag:prod:22

Exit status is 1 when the flow is refused, which makes this usable as a deploy gate: a change that would cut a service off fails the pipeline instead of the service. The same question over the API is op:list with view: 'acltest', which returns a verdict row carrying a why.

When a connection is refused

Read the refusal against the order above rather than guessing. A flow your document is supposed to allow, and does not, usually has one of three causes: another grant earlier in the list matched first, the destination is not the node you think it is, or the node is on the roster and awaiting admission. The why column on an acltest row names which.

A refusal that survives all four questions means the document is doing what you published. If that is not what you intended, edit the file, re-run its tests block, and publish it with --base so you replace the document you actually read. Inspect your fleet is where you confirm the roster afterwards.