MCP authentication

Cloud Guardian account tools sign you in through a browser using your Cloud Guardian account. The Vercel cost explorer uses the existing local Vercel CLI login independently. Installing the plugin does not sign you in or give it access to a cloud provider.

Sign in

Ask Codex to call cg_login. The server opens a local callback listener, then opens https://cloudguard.dev/cli/auth in your browser. Complete Google sign-in there and return to Codex.

The browser sends the Firebase authentication result to the callback on 127.0.0.1. The server checks the login state and saves your credentials locally; the native overview does not receive the tokens.

Call cg_whoami next to verify your email, user ID, and organization memberships. Then call cg_list_organizations and choose the organization for the chat. Pass its org_id explicitly to tools that accept it, including cg_open_overview.

The native overview shows the signed-in account email. It opens a sole organization automatically and presents a chooser when several are available. Its organization selector only shows organizations accessible to that account. Selecting one affects the viewer; other tools still need an explicit org_id.

Use cg_login, then cg_whoami. Show my organizations and let me
choose one before loading its saved infrastructure and costs.

If the wrong account is shown, call cg_login again and choose the intended Google account in the browser.

Local token storage

Credentials are stored at:

~/.config/cloud-guardian/auth.json

The file contains a Firebase ID token, refresh token, expiry, and account identity. The server creates the configuration directory with mode 0700 and writes the token file with mode 0600. Local MCP processes running as the same operating-system user use this saved login.

The server refreshes expiring ID tokens through Firebase's securetoken.googleapis.com endpoint. If the refresh credential becomes invalid, call cg_login again. Treat the token file as a secret: do not paste it into a chat, commit it, or include it in support logs.

API keys and headless use

Cloud Guardian's API-key management tools create organization-scoped credentials for API clients. The local MCP server currently uses browser login and does not read CLOUD_GUARDIAN_API_KEY. Setting that environment variable does not authenticate cg-mcp.

Run the MCP server on the local machine where you can complete browser sign-in. For service or CI integrations, use the API documentation and an API key supported by that API rather than relying on an undocumented MCP authentication mode.

Vercel CLI authentication

For cg_explore_vercel_costs, install a current Vercel CLI and run vercel login. Check the account with vercel whoami, then provide an explicit team slug or ID to the tool. Access to billing depends on your role in that team. This workflow does not need cg_login, a Cloud Guardian organization, or a saved connector.

The tool invokes the local CLI; the CLI keeps control of its OAuth login and token refresh. Do not copy its credentials into Cloud Guardian or paste them into chat. If the desktop host cannot find the CLI, set VERCEL_CLI_BINARY to the absolute CLI executable path in the MCP host's environment and restart the connection.

Persistent Vercel connectors are a separately requested workflow. cg_onboard_vercel requires Cloud Guardian login, an explicit org_id, a team_... team ID, and a dedicated Vercel API token for a new connector. Prefer CLOUD_GUARDIAN_VERCEL_TOKEN in the MCP host's environment; the tool also accepts an optional api_token. This connector token does not authenticate the Cloud Guardian session or replace local CLI login. Keep the CLI's OAuth credentials under the CLI's control. See Vercel onboarding for connector reuse, saved billing, and separately requested team-only scans.

Connection troubleshooting

See installation for the plugin and standalone connection commands, and workflows for provider setup.