SEED / Clearance
developer preview
Trust

Security

SEED Clearance is local-first. Your assistant does not receive your long-term keys. SEED checks permissions locally, signs receipts locally, and denies actions when required information is missing.

Key material

Identity keys live in the operating system keystore when available: Keychain on macOS, Secret Service on Linux, and DPAPI-backed storage on Windows. They are not printed by status commands.

Where secrets live

The local SEED state stores policy and log data. Long-term identity secrets stay behind the host signing boundary instead of being handed to the assistant.

How signing works

SEED prepares the thing that must be signed. The host side performs the signature through the keystore or a pinned helper. The assistant never receives the private key.

For the local Trust Loop, provider claims are verified with an Ed25519 signature and the consumer policy must pin the provider signing public key. Protocol Provider BLS verification is separate and is not claimed by the local product loop.

Revocation

  • Immediate. The assistant's bridge token rotates.
  • Recorded. The revocation is written to the signed log.
  • Irreversible. A revoked assistant id is not reused; you connect a new one.

Fail-closed

If permission, policy, budget, log chain, or signature data is missing or broken, SEED denies the action and writes a denied entry. It does not guess.

Disclosure

Vulnerability reports: security@seedid.xyz. Use the public PGP key published at seedid.xyz/keys/security.pub. We acknowledge inside 72 hours.

Uninstall & keys

See Uninstall & keys for clean removal, rotation, and what stays on disk after each path.