Designing safe customer access for AI agents
Why Coldvio uses browser PKCE, purpose-bound agent tokens, a narrow API, and confirmation gates instead of reusing dashboard sessions.
The customer—not the agent—is the authority
An agent can help a customer operate Coldvio, but it should not become a second identity system. The customer signs in on the official Coldvio origin, reviews consent, and can revoke the resulting agent credential.
Browser login without sharing a password
A loopback PKCE flow lets a local CLI use the customer's browser session. The authorization code is short-lived, single-use, stored hashed, and bound to a verifier. Redirect validation accepts only the exact 127.0.0.1 callback shape.
Purpose-bound credentials
Agent tokens have audience=agent and explicit read, write, generate, and approve scopes. Dashboard sessions and browser-extension credentials cannot be substituted on dedicated /v1/agent routes. Shared extension-generation routes scope-check agent credentials separately. This reduces confused-deputy and cross-surface reuse risks.
An allowlist beats accidental API parity
The agent API exposes only operations that make sense through a conversational interface. It performs server-side tenant filtering, bounds result sizes, and deliberately omits direct send, publish, and generic execute tools.
Confirmation is a boundary, not a phrase
Consequential MCP calls require trusted host elicitation and the CLI requires --yes; a model-supplied boolean is not proof. The first-party client then obtains a 120-second, single-use server intent bound to the exact payload. Server authorization and state checks remain necessary because a model prompt is not a security control.