Sophon

Security & privacy

Sophon is built around one constraint: your agent runtime stays yours. The cloud coordinates identity, delivery, streaming, history, and approvals, but it does not host your runtime or take custody of your provider credentials.

What stays local

These stay on the machine or service running the connector:

  • model provider API keys,
  • local files and shell access,
  • MCP server credentials,
  • OpenClaw gateway tokens,
  • runtime prompts and private config,
  • the bridge token used to connect to Sophon.

The connector decides what to send back as message text, tool metadata, attachments, or approval requests.

What Sophon stores

Sophon Cloud stores enough to make the iOS experience work:

  • user identity from sign-in,
  • installations and their display metadata,
  • hashed bridge tokens,
  • sessions and messages,
  • streamed final text,
  • tool call metadata/results that the connector forwards,
  • approval requests and decisions,
  • delivery state needed for reconnect and resume.

Secrets are not intentionally stored in plaintext. Connector authors should still avoid sending secrets in message text, tool args, tool results, or approval copy.

Bridge tokens

A bridge token looks like:

inst_<id>:s_live_<secret>

It is scoped to one installation and only authorizes bridge actions for that installation. Treat it like a production secret:

  • store it in a keychain, local config file, or secret manager,
  • do not include it in URLs,
  • do not print it after first setup,
  • redact it in logs,
  • rotate it if exposed.

User sessions

The browser and iOS app use user sessions, not bridge tokens. User sessions can manage account-level state such as pairing, installations, sessions, and approvals.

Bridge tokens and user sessions are intentionally separate so a local connector cannot impersonate the user outside its installation scope.

Approvals

Approvals are explicit human-in-the-loop checkpoints. A connector should request approval before actions that are destructive, expensive, privacy-sensitive, or externally visible.

Good approval prompts include:

  • the exact command or action,
  • the host or service affected,
  • a plain-language explanation,
  • severity,
  • what will happen if the user denies.

Do not hide important details inside vague copy like “continue”.

Network model

The connector dials out to Sophon Cloud over WebSocket. Sophon does not need inbound access to the user's laptop, localhost, or private network. This keeps the default OpenClaw path usable behind NAT and on normal home or office networks.

Practical checklist

  • Use HTTPS/WSS endpoints only in production.
  • Keep bridge tokens out of URLs and logs.
  • Use idempotency keys for retryable POSTs.
  • Ask for approval before risky tool actions.
  • Redact secrets before forwarding tool output.
  • Provide a way to revoke or rotate local credentials.
  • Use least-privilege scopes when a connector has its own internal auth.

Read next