Trust
Privacy, authority and availability
This page states plainly what Floating Keys can do today, what it is designed to do, and the limits of each. If something here disagrees with a marketing illustration, this page is the reference.
What stays private#
- Project threads are private to their owner. Project membership is not conversation sharing.
- Including conversation context in a run is opt-in and explained before you choose it.
- Finding existing agent projects on your computer reads folder and timestamp information, not prompt or reply content.
- The planned hosted audit trail records what happened without storing prompt, file or credential contents.
The waitlist#
The public waitlist stores your email address, consent and confirmation timestamps, and verification and delivery records, so we can send a confirmation, limit repeated sends and later send a beta invitation. Signup records are stored in Google Cloud Firestore in us-east1; confirmation email is delivered through Resend. Confirming your waitlist email does not create an account, a Project or an invitation, and nothing on the public site can run an agent.
Account sign-in#
Sign in uses Firebase Authentication to create or return to an account. Google shares your name, email and basic profile information. We request no access to your Google files, mail or calendar. Email sign-in uses an emailed link; opening it on another device requires you to confirm the same email address.
Phone sign-in is implemented with Twilio Verify and awaits service configuration. When enabled, Twilio receives your mobile number to send and verify a one-time code; the server issues a Firebase session only after verification succeeds. Verification records expire after ten minutes, with short-lived send counters used to limit abuse. Your chosen identity remains in Firebase until account deletion. Phone and email identities are not silently merged.
The local safety boundary#
Availability at a glance#
| Capability | Status | Notes |
|---|---|---|
| Public site and waitlist | Live | Email confirmation only |
| Desktop app with local Core | Local | Single user, trusted local machine |
| Projects, threads, explicit dispatch | Local | Hosted versions planned |
| Run approval and review | Local | Bound to exact task, source and policy |
| Codex governed runs | Local | Verified locally |
| Claude Code governed runs | Partial | Signed-in execution under verification |
| Cursor | Partial | History import only, best effort |
| Imported agent history | Partial | Read-only context, not resume |
| Account sign-in | Partial | Google and emailed links configured; phone awaits Twilio. Does not grant beta access. |
| Signed-in workspace UI | Live | Navigation, appearance and simulated examples; no hosted agent execution |
| Hosted chat | Planned | Durable, reconnectable |
| Connectors, MCP registry and Keys | Planned | No provider accounts connected |
| Hosted agents and schedules | Planned | After worker isolation and recovery gates |
| Team collaboration and open sign-up | Planned | A later, separate decision |
Order of the beta#
The hosted beta is planned in stages. Each stage has to pass its own checks before it is offered. This is the intended sequence; dates are not promised.
- Waitlist — live now.
- Invited, durable chat — sign in, chat, reload and see the same confirmed state; accounts cannot see each other’s records.
- Governed connectors — a small set of reviewed services with Keys, revocation and receipts.
- Durable agents — multi-step agents on isolated workers that recover without duplicate outside actions.
- Broader product — more views, connectors and team features as each one is qualified.
Status reflects September 2026. Planned items are design targets, not commitments to a date.