Authentication and security

Interactive MCP clients should use Cavuno’s OAuth flow when the client supports remote MCP OAuth. Headless CI and scripts can use an Operator API key as a bearer token.

Cavuno currently issues OAuth tokens with the single full_access scope. Access is still checked against the consenting user’s current account membership and permissions. API keys belong to the board and hold only the permissions chosen when the key was created; the creator’s later role changes don’t affect them. See API keys.

Keep credentials outside prompts

The parent MCP worker injects the authenticated credential into cavuno.request. Never add an Authorization header inside search or execute code, print credentials to the console, or paste a live key into a shared prompt.

Choose and rotate access deliberately

Create keys in Settings → Developer → API keys and select only the permissions the automation needs. Store the value in a secret manager or client credential store, and rotate it when a device or repository is no longer trusted.

Test with a read

After connecting, use search or a narrow GET request. Confirm the intended account before approving a write. Treat MCP configuration files as sensitive when they contain custom headers, even if the rest of the project is public.