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: 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 — captured at consent and held in your own encrypted grant, never a shared 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 lives only in your own encrypted grant props — never a shared 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 deletes the relay's copy of your token along with the grant. It does not revoke the Bee token at Bee — to fully revoke, re-pair or rotate it in the Bee app. 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
- Your token lives only in your own encrypted grant, nowhere central
- The blast radius is one person: you
- No trust required in an operator you've never met
- Revoke whenever: disconnect deletes the copy; re-pair 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.