Federated Trust for Embodied Robot Capability Marketplaces
Robot capability marketplaces, the "app store for robot skills," are emerging as the deployment vector for LLM-driven robot fleets. The default cloud-native answer to "is this package safe to install?" is centralised PKI: one certificate authority, one transparency log, one root of trust. We argue this is the wrong model for embodied robot fleets, where operators face heterogeneous regulatory regimes, air-gapped deployments, tiny operator headcounts, and physical-world consequences for trusting the wrong publisher. We present federated trust: each deployed bridge maintains its own local trust directory of acceptable signers; signers identify themselves with a public key embedded in a detached Ed25519 signature envelope; install-time verification is a local set-membership check rather than a network round trip to a certificate authority. The cryptographic primitives are deliberately standard (Ed25519 detached signatures and SSH-style trust files); the contribution is the architectural commitment that this composition fits embodied robot fleets specifically. We implement the model in a runtime governance layer with a five-subcommand CLI, a registry server, a per-bridge install gate, and 80 tests. A multi-deployment evaluation shows the same registry stream producing divergent install verdicts on bridges with different trust directories, the load-bearing design property. Across 5000 adversarial trials, the strict-mode gate rejects 100% of rogue-publisher, tampered, forged, and revoked-signer attacks, and 96.6% of downgrade attempts under a minimum-version pin extension. A same-hardware comparison against Sigstore-Cosign and python-TUF locates federated trust's per-verify cost between the two and its per-publisher storage footprint below both.