Skip to content
Agent Identity
Skip navigation

Nested Identities

What happens when one agent egresses behind another: how the edge is seen, published and governed.

Published

On this page (4)

Nested Identities Documentation

An agent can send its traffic out through another agent's identity. A supervisor spawns workers behind it, or a managed service runs a customer's agents inside its own footprint. Whisper models that as a nested identity: the child keeps its own address, its own name and its own records, and the edge to the parent becomes part of the published picture.

Declared and measured

The edge arrives two ways.

A declared edge is asserted. The child, or whoever provisions it, passes the parent when it asks for connectivity, and the control plane records the claim.

A measured edge is observed. Egress sees the child's address as the source and the parent's address as the address the flow arrived from, and derives the parent from the traffic itself.

Measured governs, declared informs. A declaration is useful context and a convenient way to set up a fleet, but every decision that matters is taken on the edge that was measured, because that is the one the child cannot misstate.

Reading the tree

op:agent returns the shape around one identity: the parent it sits behind, the children sitting behind it, and the depth of the chain. Each parent and child entry carries where the edge came from, whether it is currently active, and whether it has been orphaned because one end went away. A child count of zero means counted and empty; a null count means not counted on this call, which is a different statement.

whisper-call
CALL whisper.agents({op: 'agent', args: {address: '2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478'}})

Pass roam: true and the answer includes the identity's roaming history, which is how an operator running someone else's agents reconstructs where a workload has been sitting over time. Read Your Fleet documents the full column set.

What the public sees

A nested edge is published, so a relying party checking an address can see that it egresses behind another identity rather than directly. The registry object carries a related link to the parent allocation and a remark naming the relationship, and the WHOIS record carries a nested-behind line. RDAP and WHOIS shows both.

Publication is scoped to one owner. An edge between two identities in the same account is published. An edge that crosses accounts is held back, so running someone else's workload behind your own identity does not disclose the arrangement to the internet.

An account that would rather publish nothing about its internal topology sets the nesting_opt_out key in resolver policy.

Policy composes downward

A nested child is bound by every ancestor above it, not only by its own settings. Where the child's policy and an ancestor's policy disagree, the more restrictive one wins, evaluated across the measured chain rather than the declared one. A child cannot widen what a parent narrowed, and it cannot escape a parent's block list by setting its own default to allow.

A chain that runs deeper than the composition can evaluate fails closed. That is the safe direction: an identity whose governing policy cannot be resolved is treated as denied rather than waved through.

Nesting is one shape for putting one identity's traffic inside another's. Connectivity Tiers covers how a single identity gets on the wire in the first place.