Skip to content
Floating KeysDocs
HomeSign inJoin waitlist

Design target

Keys and connectors

Connectors let agents read from and act on outside services. Keys narrow exactly what a given agent may do with a connector inside one Project. This is the core of the hosted beta design and is not connected to anyone’s accounts today.

Current status#

  • Connector registry and KeysPlanned

    Designed for the hosted beta; no provider accounts are connected.

  • Approval-gated action pathPartial

    Core has the request → approve → execute lifecycle that connectors will reuse.

  • First reference connectorPartial

    A bounded, read-only GitHub connector exists in Core as a reference.

Connectors and MCP#

A connector is a reviewed integration with a manifest: which actions exist, whether each one reads or writes, what account scope it needs, how it is rate-limited and which version was tested.

MCP (Model Context Protocol) is one way tools are transported to an agent. In Floating Keys, transport is not authority. Adding an MCP server does not make its tools approved, and a long list of servers is not a measure of what agents can safely do.

Try a read-only connector#

In the signed-in workspace, open Connectors → Test connectors. Select Floating Keys, GitHub, or both. Search a word, or leave the query empty to browse retrieved sources. Each result includes its original source, source identity and retrieval time.

  • Floating Keys: searches the same public documentation shown here. A connected Core runtime can also return your currently authorized Project names and membership roles. It does not read message bodies, files, credentials, drafts or simulated examples.
  • GitHub: reads the overview, default-branch README and up to ten recently updated open issues or pull requests in one named public repository. Start with octocat/Hello-World. No GitHub token is required, and query matching happens in your browser.
  • Coverage: this is bounded text retrieval, not a full repository crawl, model response or account-wide memory search. Public API limits and incomplete reads are shown in the coverage disclosure.

Keys#

A Key is a project-scoped grant that narrows a connector’s ceiling for one agent: which actions, on which exact resources, for how long and whether each use needs approval. Keys are how the gold key motif appears in the product — it marks access, not importance.

  • Keys can expire, be limited to a number of uses, and be revoked. Revocation stops the next call of a queued or running agent.
  • Effective scope, and any part of a Key the provider cannot enforce, is shown before use.
  • Provider credentials stay in a server-side credential broker. They never reach browser code or an agent’s prompt.

Two gates on every action#

An outside action must pass two independent checks, evaluated again at the moment of the action rather than when a button was drawn.

  1. Agent asksA specific action on a specific resource
  2. Gate 1: WorkspaceProject grant and Key; any deny wins
  3. Gate 2: ProviderYour account’s own permission
  4. ApprovalExact payload, when required
  5. ReceiptProvider confirmation, or an explicit unknown
Diagram Both gates must allow the action. When one refuses, Floating Keys says which one, because the fixes are different.

Write evidence, not judgment#

  • Additive and reversible actions — like posting a comment that describes what a run did — can be automated within a Key.
  • Decisions that settle something for others — closing an issue, merging, publishing — require a person, with preview and approval of the exact payload.
  • No optimistic updates. An outside change shows as pending until the provider confirms it. If the result is unknown, the interface says so.
  • When a provider is unreachable, cached data is labelled as stale and actions are disabled.

Status reflects September 2026. Planned items are design targets, not commitments to a date.