Expand description
Per-agent Ed25519 keypair for general agent-to-agent WAN-tier jekt
signing. See db_agent_wan_keys in migrations.rs (OBJECT_SCHEMA_VERSION
v36).
Mirrors agent_lan_keys.rs: one row per locally-registered agent_id,
minted once (first call to agent_wan_key_ensure), with the PRIVATE half
leaving this srv instance only by being injected into that ONE agent’s own
MCP server process env (AGENTMUX_WAN_KEY) — never into any other agent’s
env, never returned over any RPC. The public half is not secret: it is what
gets published to muxbus’s agent-ownership registry so a WAN counterpart
can verify this agent’s outgoing signatures.
Why this is a separate table from db_agent_lan_keys rather than a reuse
of the same keypair. The two tiers need different key lifecycles, and
that difference is structural, not stylistic:
- A LAN public key is permanently trust-on-first-use pinned by every peer
that has ever seen it (
db_lan_peer_pubkey_pins, no expiry, no re-pin path), which is exactly whySPEC_JEKT_HOST_KEY_TTL_ROTATION_2026_09_14.md§4 declined to rotate LAN keys — rotation would turn every pinned peer into a permanent false “active forgery” alarm. - A WAN public key is served from an authoritative registry the receiver queries, so rotation is a republish rather than a spoofing alarm, and the spec intends WAN keys to rotate.
One keypair cannot have both lifecycles. Keeping them separate also means a compromise of one tier’s key does not hand over the other’s.
Scope note: minting and signing ship ahead of verification on purpose.
Verifying a WAN signature requires resolving (sender_account, source_agent) to exactly one key, which waits on relay-side work tracked
in the private cloud repo. An agent
only receives a key when it is spawned, so minting now is what makes
verification meaningful later instead of applying to almost nobody.
Structs§
- Agent
WanKeypair - An agent’s WAN signing keypair, both halves base64-encoded for storage/transport, plus the version the publish/rotation phases will use.