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 are account-bound and inherit their creator’s current permissions, so changing or removing that user’s access also changes what the key can do.

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 while signed in as the account member whose current permissions the automation should inherit. Cavuno does not currently issue narrower per-key scopes. 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.