Security & Compliance

What your security
team needs to see.

Clearly is built to be reviewable. Below is the current security posture of the platform — controls in production today, the SOC 2 roadmap, and the contractual commitments we make to Enterprise customers via a DPA.

Request the DPA & SOC 2 packetTalk to sales

Your Claude key stays on your Mac

We engineered the daemon so the worker stores only masked metadata — never the credential value itself. Every call to Anthropic originates from your daemon, on your computer, using your subscription. The worker is a coordination layer, not a secret store. Here are the five hops with cited code paths.

  1. 1

    You click “Connect Claude” in the Hive Mac app

    The daemon spawns Anthropic's official `claude setup-token` CLI as a child process on your Mac. Anthropic's CLI — not ours — handles the OAuth browser flow and writes the token to ~/.claude/.credentials.json. Clearly's code never sees the token in this step.

    📄 beehaven_sdk/packages/cli/src/claude-credential-store.ts
    🌐 Anthropic's CLI ↔ Anthropic OAuth (your Mac → Anthropic, direct)
  2. 2

    Daemon detects the credential file changed

    A filesystem watcher inside the daemon notices ~/.claude/.credentials.json was updated. It extracts only the last 4 characters for display purposes ("Pro/Max plan (…1234)"). The raw access token stays in a local variable inside the daemon process — never written to our disk, never shipped over the network.

    📄 beehaven_sdk/packages/cli/src/claude-credential-store.ts:334-415
    🌐 None
  3. 3

    Daemon tells our cloud "a credential is connected"

    Over the daemon's WebSocket to the Clearly relay, the daemon sends a `canvas-credential-detected` message containing four fields: credType ("plan" or "api-key"), maskedKey ("…1234"), expiresAt, scopes. The actual access token, refresh token, and any secret material are NOT in the message.

    📄 beehaven_sdk/packages/cli/src/relay.ts → _startCredentialsWatcher()
    🌐 Daemon → Clearly cloud (metadata only)
  4. 4

    Our cloud writes a metadata-only row

    Our backend handles the broadcast and writes one row to its claude_credentials table. The columns are: type, masked_key, connected_at, daemon_confirmed_at. There is no column for token, accessToken, refreshToken, apiKey, or any other secret. The backend literally cannot make an authenticated request to Anthropic on your behalf — we never have your token to send.

    📄 apps/cloudflare/src/workspace.ts → case 'canvas-credential-detected'
    🌐 None (DB write only, inside our backend)
  5. 5

    Your prompts run on YOUR Mac

    When you send a prompt, the worker forwards only the prompt text to your daemon. Your daemon spawns the Claude Agent SDK as a local subprocess. The SDK reads the OAuth token from ~/.claude/.credentials.json (or your API key from your local keychain) and makes the HTTPS call directly to api.anthropic.com from your Mac — exactly as if you'd run `claude` in your own terminal.

    📄 beehaven_sdk/packages/cli/src/daemon-omni.ts → buildSdkOptions() + query()
    🌐 Your Mac → Anthropic (direct HTTPS, your token, your IP)
DataBackend can seeStays on your Mac
Claude OAuth access token—✓
Claude OAuth refresh token—✓
Anthropic API key (sk-ant-…)—✓
Last 4 chars of credential (display only)✓—
Credential type (plan / api-key)✓—
Connection timestamp✓—
Your prompts (FAB chat send)✓ (transit only — forwarded to daemon)—
Claude's responses (daemon stream)✓ (transit only — forwarded to tab)—
Files in a local-folder brand scan—✓ (daemon reads + sends thumbnails to Anthropic via YOUR key, never to us)
Files you explicitly upload to a canvas✓ (your private object storage)—
Composition blocks (saved canvases)✓ (your workspace DO)—
Generated assets (SVG / MP4 / PNG)✓ (your object storage)—
Brand kits (palette, type, voice)✓ (your workspace DO)—

This architecture sits cleanly inside Anthropic's published policy for third-party Agent SDK use of a user's plan — the February 2026 enforcement action targeted services that reverse-engineered the OAuth flow outside the SDK or proxied many users through one subscription. Clearly does neither.

Verify by reading the source at /Applications/Hive.app/Contents/Resources/beehaven/ — grep for any string that looks like a token transmission. Or run nettop -P while using Clearly and confirm outbound HTTPS to api.anthropic.com comes from the daemon's node process, never from a browser tab on clearly.sh. Found a regression? security@clearly.sh — P0 incident.

Current posture

Encryption
TLS 1.3 in transit on every external connection. AES-256 at rest across every primary data store. Third-party access tokens are stored with a per-environment key envelope so a compromise in one environment cannot decrypt another.
Data residency
Compute runs on a global edge network with the request handled at the closest healthy region. Persistence defaults to the closest healthy region with US/EU pinning available on Enterprise. AI inference is pinned to a single named region for predictability.
Authentication
Email + Google sign-in for end users; identity tokens verified server-side on every authenticated request. SSO via SAML 2.0 and SCIM provisioning available on Enterprise — Google Workspace, Okta, and Azure AD tested.
Authorization
Per-workspace RBAC with owner, admin, member, and guest roles. Per-block visibility (private, team, public) enforced server-side at every share-resolve — visibility is never determined by the client.
Audit logging
Workspace activity, share-link access, and billing transitions are written to an append-only audit log. Every authenticated server-side action is captured with user identity, timestamp, and resource path. Audit export available on Enterprise.
Secrets management
All third-party credentials live in encrypted secret stores, never in source control. Rotation is performed on a documented cadence and on every personnel change. No long-lived credentials are issued to engineers — access is short-lived and audited.
Subprocessors
A current subprocessor list is provided under the Data Processing Agreement. The list is reviewed at least quarterly and customers are notified before material additions take effect.
Vulnerability management
Dependencies audited monthly with critical CVEs patched within the published SLA. Workloads run in isolated tenants — no shared VMs or container hosts. Coordinated disclosure at security@clearly.sh; we respond inside 24 hours.
Backup & recovery
Primary data stores are continuously replicated. Daily snapshots retained 30 days. Point-in-time recovery and object versioning available on Enterprise. Restore drills run quarterly.

Roadmap

  • NowTLS 1.3 in transit, AES-256 at rest, everywhere
  • NowPer-workspace RBAC + per-block visibility
  • NowAppend-only audit log on share-resolve and billing
  • NowEmail DKIM + SPF aligned
  • Q3SOC 2 Type I (auditor engaged Q1)
  • Q4SOC 2 Type II — observation period
  • Q4SAML + SCIM on Enterprise
  • NextOn-prem option (annual contract, dedicated tenancy)
  • NextHIPAA BAA for healthcare customers

Enterprise security review

We'll send you the DPA, current SOC 2 status, the subprocessor list, and a security questionnaire response within one business day.

security@clearly.sh →

Found something concerning? Email security@clearly.sh — we respond inside 24 hours.