feat(desktop): support provider-custodied agent keys

[jrobotham-square]

Why

A remote backend may need to create and keep an agent’s signing key. Buzz must not receive that private key, and it must not switch custody modes after telling the user which process will hold it.

What

Providers can advertise a narrow register and attest handshake. Buzz stores the returned public identity, records provider custody, and keeps attestation retryable.

The create request now carries the custody mode shown after the provider probe. Creation fails closed if fresh negotiation no longer matches.

How

Desktop validates the provider’s protocol response before the UI uses it. It performs all local checks available before registration, including owner-key, persona, team, relay, and behavior checks.

Providers without both capabilities keep the existing deploy flow. Provider-custodied agents skip local keyring and spawn paths.

sequenceDiagram
    actor User
    participant Buzz as Buzz Desktop
    participant Provider as Provider executable

    User->>Buzz: select a remote provider
    Buzz->>Provider: info
    Provider-->>Buzz: validated capabilities
    Buzz-->>User: show who will hold the private key
    User->>Buzz: create agent + observed custody mode
    Buzz->>Buzz: validate local inputs and selected custody
    Buzz->>Provider: register (name and config)
    Note over Provider: Create and retain private key
    Provider-->>Buzz: agent id + public key only
    Buzz->>Buzz: save public identity as attestation pending
    Buzz->>Provider: attest (public key + owner authorization)
    Provider-->>Buzz: acknowledged
    Buzz->>Buzz: clear attestation pending
    Buzz-->>User: agent created and ready

Loading

Risk

This changes only the unreleased remote-provider path. Final disk persistence can still fail after a provider returns an identity, so providers should expire registrations that never receive attestation.

Testing

Manually ran the full create path against a protocol-v1 provider on the latest commit.

Created a fresh provider-backed agent and verified that the provider recorded one successful REGISTER and one successful ATTEST for the same backend agent ID. Buzz persisted the provider-issued public key with provider custody, active state, no pending work, no error, and no local private key.

Restarted Buzz and confirmed the same agent remained active with the same public key and provider backend. The provider still showed exactly one registration and one attestation, so restart did not duplicate either call.

Bigger picture

Provider-side expiry for unattested registrations remains useful cleanup. Stable registration retries are outside this slice and are not required by this create flow.

Generated with Codex

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 3c7f288c60d67df78577b237e27c3dfc8831aaa1...74715246b7a94cea7b83cf7e3419959d6bd9a252.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 74715246b7a94cea7b83cf7e3419959d6bd9a252 to authorize a new review.
Any previous review applies only to its recorded range.