Expand description
Trust-on-first-use pin of a REMOTE agent_id’s LAN public key. See db_lan_peer_pubkey_pins in migrations.rs (OBJECT_SCHEMA_VERSION v20) and docs/specs/SPEC_JEKT_LAN_TIER_SIGNING_2026_08_15.md §2.2.
Distinct from agent_lan_keys.rs (this instance’s OWN agents’ keypairs,
private half included) — this table holds only public keys OBSERVED from
LAN peers for agent_ids this instance does not itself host.
Why this exists (reagentx P0 on the LAN signing PR): mDNS peer discovery
is unauthenticated — any device on the LAN can advertise its own
AgentMux instance and locally register an agent under an EXISTING
agent’s name (e.g. “korp”). Without pinning, find_agent_lan_pubkey
trusts “whichever peer answers the discovery query first,” which an
attacker can win just as easily as the legitimate owner — their
self-minted keypair would then verify successfully as “korp,” defeating
the entire point of per-agent signing. Pinning the FIRST key ever
observed for an agent_id, and treating a later, DIFFERENT key as a
mismatch rather than silently accepting it, is the standard SSH-host-key
mitigation for exactly this “no PKI available” situation. It does not
eliminate spoofing entirely — an attacker who wins the race on the very
first-ever lookup for a given agent_id still gets pinned as
authoritative — but it closes the “always fully spoofable, forever”
case down to a narrow first-contact race, the same residual risk any
TOFU scheme accepts.