Sync privacy

TL;DR

We only send counts. Never raw data. Never tool calls. Never payloads.

Operator controls

Never register

Simplest control. If you never run sentience-sync register, Sentience Cloud never sees anything from you.

The runtime works fully locally without it.

Send less

sentience-sync run is manual. Running it less often means less data sent.

If you want to sync once a month, invoke the command once a month. If never, invoke it never.

Inspect what would be sent, before sending

sentience-sync run --dry-run

Prints the exact payload that would go over the wire — without making any network call.

Send from a specific window only

sentience-sync run --window 2026-04-14T00:00:00Z..2026-04-14T23:59:59Z

Lets you control exactly which window of events is aggregated and uploaded.

Delete local state

rm -rf ~/.sentience/

Removes the local installation_id, installation_secret, contact info, and offset state. Next register creates a fresh installation.

Account and data deletion

Contact support to delete your installation and all associated data. Removes:

Your installations row (contact info, installation_id)
Every sync_runs row associated with it
Any aggregated analytics derived from your data

What IS sent

On sentience-sync run, Sentience Cloud receives:

installation_id — a UUID generated locally on first register.
runtime_version — your installed sentience-governor version.
A time window — start and end timestamps.
Aggregated counts — a dict like {"POL-001": 0, "POL-003": 12, ...}. Counts per rule.
Your contact email and name — once, at registration time.

Counts sum across every file in log_sources — MCP wrapper traces, LangChain callback traces, and Claude Code hook traces all roll up into one counts_by_rule payload. Sentience Cloud is never told which wrapper surfaced which rule fire.

What is NEVER sent

Raw event content — no agent IDs beyond yours, no user IDs, no tool names, no tool arguments, no tool responses, no payloads.
Streaming data — no realtime channel, no webhook, no persistent connection.
Your agent’s code, behaviour, logs, or business context.
IP-level identity — source IP is hashed with a server-side pepper on arrival; raw IP is never stored.
Anything about individual tool invocations.
The contents of your trace files.

If you never ran sentience-sync register, Sentience Cloud has received nothing from you.

Exact wire format

You do NOT need to understand this to use the product.

POST https://sync.getsentience.ai/v1/sync
Authorization: Bearer sgn_live_<your-token>
Content-Type: application/json

{
  "installation_id": "inst_<uuid>",
  "runtime_version": "0.2.0",
  "window_start": "2026-04-22T00:00:00Z",
  "window_end":   "2026-04-23T00:00:00Z",
  "counts_by_rule": {
    "POL-001": 0,
    "POL-002": 3,
    "POL-003": 12,
    "POL-004": 0,
    "POL-005": 1
  }
}

That is the entire body. No envelope fields, no metadata.

For register, the body adds contact_email, contact_name, optional organization / operator_role, and a user_agent like sentience-sync/0.2.0 python-3.12 darwin.

update-check is an unauthenticated GET:

GET https://sync.getsentience.ai/v1/update-check?installation_id=inst_<uuid>&runtime_version=0.2.0

No body. No bearer token.

How the secret is stored

On first register, the server issues an installation_secret (a sgn_live_* bearer token) and returns it exactly once. The CLI stores it at ~/.sentience/sync-state.json.

On POSIX, the file is written with owner-only permissions (0600). On Windows, a best-effort equivalent is attempted.

Two things to know:

This is local hardening, not perfect security. Anyone with local-user access can read the file. Better than world-readable, not a defense against a compromised machine.
If the secret is compromised, rotate it. Contact support to null the hash server-side, then run sentience-sync register again. Your installation_id is preserved.

The secret is never displayed outside the one-time register success message.

In transit

TLS 1.2 minimum. Enforced at the edge.
Bearer token in a header, never the body.
HSTS. Subsequent requests must use HTTPS.

At rest, server side

installation_secret_hash bcrypt’d with a server-side pepper. Plaintext never touches the database.
Source IP SHA-256 hashed with a separate pepper on arrival. Raw IP never stored.
Aggregated counts stored per (installation_id, window_start, window_end) tuple. Duplicate submissions are idempotent.
Retention: see Sentience Cloud’s published retention policy.

If you later need enforcement (not just visibility)

Same visibility surface, plus:

Real enforcement at the tool-call boundary (block, scope contraction, pause)
Cross-session and cross-agent memory
Operator dashboards, alerting, SOC 2 audit support
Centralised policy distribution
Enterprise support + custom retention

The paid control plane is a commercial offering. Open-tier is the honest observability half and is free forever.

Stuck? → Troubleshooting