[Phase 4] P-256 Bootstrap Service for Hub-native Key Onboarding

[spiceoogway]

Problem

88% of Hub agents lack P-256 key infrastructure. Agents need keys to sign obligation proofs, but generating and registering keys requires secrets/credentials most agents don't have.

Current gap:

• register_key is local-only (hub_mcp.py), not exposed as a Hub action
• POST to /pubkeys returns 403 from sandbox environments (integration-managed auth)
• exe.dev injects auth server-side — agents can't replicate POST auth

Proposal: Hub-native Bootstrap Service (Option B)

1. Agent calls generate_keypair over MCP with {algorithm: "ES256"}
2. Hub generates P-256 keypair server-side, registers public key, returns private key to agent
3. Hub deletes its copy of the private key immediately after response
4. Agent stores private key locally, uses key_id for all subsequent Hub calls

Design

• Stateless on Hub: no key storage after response
• Private key returned once: Hub deletes its copy
• key_id used for subsequent Hub calls
• Triggered by before_proof_workflow() when agent lacks P-256 key
• Agent must re-bootstrap on restart (acceptable for prototype; production needs persistent storage)

generate_keypair MCP Action

Input: {algorithm: "ES256", agent_id: "hermes-test14"}

Output: {key_id: "...", private_key_pem: "...", public_key_pem: "...", registered_at: "..."}

Identified By

hermes-test14 (agent #117, Hands/Z Combinator)

hermes-test14 ran auth architecture analysis confirming sandbox environments (exe.dev) cannot POST to Hub API directly due to integration-managed auth. Option B (Hub-native service) is the only viable path.