bee-ai-auth-mcpHonest + safest
What's held, what isn't, and how to revoke.
Custody is the whole question with a credential relay. The honest answer for Phase 1: this holds your own token in your own deployment, and nobody else's anywhere.
Two legs, kept separate
The login leg (you ↔ relay) and the data leg (relay ↔ Bee) never mix. GitHub authenticates who you are and grants nothing else — no repository access, no profile data beyond your login, which is read once and discarded. Your Bee token rides the other leg only, as your Worker's own secret.
What gets stored
The only persistent state is the OAuth provider's grants, in your OAUTH_KV namespace. Grant props are encrypted per-grant with key material derived from the token, not a shared KMS key. A storage-only leak therefore exposes metadata, not usable credentials.
The Bee bearer
It's a Worker secret. It is never written to logs, never placed in a URL, never serialized into an error, and never returned in tool output. Errors carry a status and a generic message — never the request, the headers, or the upstream body. Tools are read-only by default and request the narrowest data they need.
Revocation — said plainly
Disconnecting the connector ends the relay's access to you: the grant is gone. It does not revoke the Bee token itself. To fully revoke, rotate the token in the Bee app and re-set the secret. We won't imply a cleaner story than that — honest beats convenient.
Who can use your instance
Every login is checked against ALLOWED_GITHUB_LOGIN. Until you set it, the instance refuses everyone — closed by default, not open by default.
Why self-host is the safe default
A hosted store of everyone's tokens
- Holds many people's long-lived Bee bearers at once
- One breach exposes every connected account
- A structural honeypot someone must guard forever
- Reachable only once Bee issues short-lived, minted tokens
Self-host (Phase 1, Model A)
- Your token is your own Worker secret, nowhere central
- The blast radius is one person: you
- No trust required in an operator you've never met
- Revoke whenever, by rotating in the Bee app
Why hosted multi-tenant is deferred
The sibling git-repo-auth can host many users safely because GitHub mints ephemeral, scoped tokens that die within the hour — it never stores a long-lived credential. Bee has no equivalent minting primitive today, so a hosted bee relay would have to store long-lived Bee tokens: the exact liability self-host avoids. Hardening (envelope encryption, per-user isolation, narrowest scope, rotation) shrinks that risk but doesn't erase it. So hosted custody stays deferred and scaling is gated on an upstream "mint short-lived tokens" capability landing. The roadmap tracks that gate.