Privacy

This is the same security disclosure the bicameral-mcp CLI prints before opening Google sign-in. We mirror it here so you can read it without running the wizard.

About to open Google sign-in. Read this first:

What flows where

  • Decision data (transcripts, payloads) flows your-CLI ↔ Google directly. Bicameral the company does NOT receive copies. No Bicameral server in the loop.
  • Your OAuth token stays on your machine (~/.bicameral/google-drive-token.json, mode 0600).

What the drive.file scope means for the rest of your Drive

  • The Bicameral CLI on your machine can only touch files it creates in the team folder. Your other Drive content (other folders, Google Docs, shared files) is invisible to the CLI — Google enforces this server-side.

What Bicameral the company CAN see (as the OAuth app publisher)

  • Aggregate API request counts. Not contents.
  • OAuth consent records: which Google accounts authenticated, when.

The trust dependency you're accepting

Same as any OAuth tool (gh, gcloud, Notion, Slack desktop): you trust that the open-source CLI behaves as advertised. Source: github.com/BicameralAI/bicameral-mcp.

Full security model: docs/team-mode-setup.md

Privacy policy

Where your data physically lives

Decision data — meeting transcripts, decision payloads, signoffs, the JSONL event log — is uploaded by the bicameral-mcp CLI on your machine into a Google Drive folder that your team owns. The Drive API call goes from your machine directly to Google. Bicameral the company operates no server that sits between your CLI and Google; we do not receive, cache, or store copies of your transcripts or any other decision data.

What the OAuth scope limits

The Drive OAuth flow grants Bicameral the drive.file scope. This permits the CLI on your machine to read and write only files the CLI itself creates inside the team folder. The rest of your Drive — other folders, Google Docs, shared files — is invisible to the CLI. Google enforces this scope limitation server-side.

This scope limitation is about the CLI on your machine, not about Bicameral the company. We don’t have a master key that would let us read your files server-side; the OAuth tokens that authenticate Drive API calls live on your machine and are never transmitted to us.

What Bicameral the company DOES see (as the OAuth app publisher)

Because we publish the OAuth client that the CLI authenticates against, Google gives us OAuth-application-level telemetry in the GCP console. Specifically:

  • Aggregate Drive API request counts attributable to our OAuth client (e.g. “5,000 calls last week from this client”). Not file contents, not file names, not folder identifiers.
  • Per-user OAuth consent records: which Google accounts have authenticated against the Bicameral app, and on which dates. We do not link this telemetry to any identifying information beyond the Google account itself, and we do not share it with third parties.

The trust dependency

The OAuth flow itself can’t leak your file contents to us — your token stays on your machine, and Drive API calls bypass our infrastructure entirely. The realistic threat is “what if Bicameral pushed a malicious CLI update that read transcripts and POSTed them to bicameral-ai.com?” — the same trust dependency you accept with any OAuth tool you install (gh, gcloud, Notion, Slack desktop, Cursor, etc.). The mitigation is that bicameral-mcp is open source: any exfiltration code would be visible in the diff. Source: github.com/BicameralAI/bicameral-mcp.

Local data

The OAuth refresh token is cached at ~/.bicameral/google-drive-token.json with file mode 0600. Treat it like an SSH key. Decision data, folder IDs, and the local SurrealDB ledger live under ~/.bicameral/ on your machine.

Telemetry

Bicameral product telemetry (separate from Google’s OAuth-app telemetry above) is opt-in and configured at setup time. When enabled, it reports anonymous usage stats only — no decision content, no file paths, no personal data. Source-attribution rendering defaults to redacted, and the signer-email fallback defaults to local-part-only — both privacy-positive defaults you can override in config.yaml.

Contact

Questions about this policy? support@bicameral-ai.com.