Honest about what works.

The phases

Phase 1 — Auth core & whoami current

The Bee-independent spine: OAuth front door, the identity gate, the MCP transport, and a Tier-1 self-host deploy. Built and deployed; the one Bee-touching call is gated on reachability.

Phase 2 — Read-only retrieval next

Tools over Bee's /v1/conversations (confirmed) — async-by-default, paginated, size-capped, summary-or-full, never a raw transcript dump into your context. /v1/search/conversations and /v1/changes aren't in Bee's public docs and stay out of the tool surface until confirmed against the live API.

Phase 3 — Hosted hardening deferred

A hosted, multi-tenant Tier 2 toward git-repo-auth parity: per-user isolation, envelope-encrypted custody, rotation, quotas. Deliberately deferred — see below.

Why hosted multi-tenant waits

git-repo-auth can host many users safely because GitHub mints short-lived, scoped tokens — it stores no long-lived credential. Bee has no equivalent yet, so a hosted bee relay would have to custody long-lived Bee tokens: a honeypot self-host is built to avoid. Hardening shrinks that risk but doesn't erase it, so any hosted offering stays small and eyes-open, with scaling gated on an upstream minting capability. Full reasoning on the security page.

Open questions — not banked

• Adopt vs build the personal wire. For one person's own use, an off-the-shelf hosted pendant MCP may already close the all-surface gap. bee-ai-auth-mcp's durable value is as the reusable relay substrate, the interim wire, and the MIT community artifact — not necessarily anyone's long-term personal setup.
• Tier 2: cut, keep, or demote. Whether to build the hosted posture at all, given the above.
• Upstream petition. Asking pendant vendors for OAuth install + short-lived minted tokens — the capability that would make hosted custody safe and restore a magical first-run.

The full decision trail lives in the repo's planning corpus and ledger. Read the PRD →