Credentials and external providers

Store credentials in the supported backend, connector, or secret manager. Never commit tokens, put them in mission text, or include them in screenshots and artifacts.

User-token secrets are shown only when created. If one is exposed, revoke it immediately with ovld user-token revoke <id> and create a replacement.

Handling tokens

• A USER_TOKEN authenticates the CLI, agents, runners, and API clients. Create one with ovld user-token create, keep it in an environment variable or secret manager, and never paste it into a prompt or source file.
• Prefer the narrowest scope that works. The mission_lifecycle scope covers what a runner or agent needs without workspace administration. See Authentication and permissions for the full scope model.
• Rotate on exposure: revoke and re-create rather than reusing a leaked secret.

External providers

Overlord runs on infrastructure and AI services operated by third parties. When you write information into a mission, some of it may be processed by these providers:

• Google Gemini — when Overlord generates dashboard feed posts from mission activity, structured context derived from the mission (fields, objectives, delivery summaries, change rationales, and other written-in text) is sent to the Gemini API for summarization.
• Supabase — application data is stored in Supabase (PostgreSQL), and server-side logic (including the summarization function) runs in Supabase Edge Functions.
• Vercel — the Overlord web frontend is hosted on Vercel.

Because mission content can flow to these services, treat everything written into a mission as intentional shared-record data. See Data boundaries for what stays on your machine versus what Overlord stores.