Agent-native secret provisioning: secrets.request (user pastes key, agent never sees it)

[federicodeponte]

Problem

Agents (Claude/Cursor/Devin/etc.) hesitate to call secrets.set with a raw key value because it trips their "never enter API keys into a field" safety reflex. We're mitigating with wording (PR #2049 relabels the tool + adds MCP server instructions), but the universally-safe pattern is to let the agent provision a secret it never touches.

Proposal — secrets.request

New MCP tool + flow, mirroring how password managers / OAuth let an agent trigger a credential entry it never sees:

1. Agent calls secrets.request(key, reason) → backend returns a short-lived portal_url (+ request id).
2. Agent shows the user the URL: "Paste your POSTHOG_API_KEY here."
3. User pastes the value directly into the Floom UI (over TLS, into the workspace's encrypted vault). The agent never receives the value.
4. Agent polls secrets.status(key) until set, then continues.

Why it matters

• No agent can refuse what it never handles → zero friction across every agent/framework.
• More secure than agent-set: the raw value never transits the agent's context/logs.
• Makes Floom better than Vercel for agent-driven setup (Vercel still needs the agent or human to type the value into the CLI/dashboard).

Scope

• API: POST /secrets/requests (create, returns signed short-lived portal token), portal page to accept+store, GET /secrets/requests/{id} status.
• MCP: secrets.request, secrets.status tools (read-only-ish; never return the value).
• UI: minimal paste page, workspace-scoped, expires.
• Keep secrets.set for the explicit agent-set path (now well-framed via feat(mcp): reframe secrets.set as a Vercel-style env var (agents stop refusing) #2049).

Related

• PR feat(mcp): reframe secrets.set as a Vercel-style env var (agents stop refusing) #2049 (wording mitigation — relabel + server instructions). This issue is the durable fix.

Filed from a product discussion; not urgent — roadmap.