Security and compliance

EasyCC is a Tauri desktop app with a clear set of trust boundaries and a small set of network destinations. This page is the single answer to "what does this thing send, where, and how is it signed?"

For the in-depth security architecture, see docs/reference/SECURITY.md in the repo.

Trust model

┌──────────────────────────────────────────────────────────┐
│                    EasyCC Desktop App                     │
│                                                           │
│   WebView (untrusted)  ── Tauri IPC ──  Rust (trusted)    │
│   React + TypeScript     typed schema    file ops, PTY,   │
│   renders content        path-validated  keychain, chat   │
└──────────────────────────────────────────────────────────┘

The WebView renders arbitrary content — including model output, fetched web pages, and MCP responses. Anything sensitive lives in the Rust backend behind a typed IPC boundary. Every cross-boundary call:

• Has a fixed parameter schema
• Validates inputs server-side (paths, sizes, formats)
• Is scoped to the current agent folder (path traversal is rejected)
• Is logged

The WebView can call IPC commands; it can't run arbitrary Rust.

A second boundary lives between external content and the model's next prompt: the safety scanner sits between every tool result and Claude. It strips invisible characters, optionally runs an on-device prompt-injection classifier, and optionally double-checks via Claude Haiku.

Data flow

The minimum set of destinations EasyCC reaches by default:

What each destination sees:

• Anthropic / your gateway — chat messages, attached file contents, tool results, model name. TLS 1.2+ in transit. Retention follows Anthropic's policy (typically 30 days for safety review) or your gateway's policy.
• Supabase — email (for OTP), OAuth callback parameters, session refresh requests. Never chat or file content.
• HuggingFace — a single GET for the safety scanner model file (~268 MB) on opt-in. Pin safety_custom_model_url_base to your mirror to skip HuggingFace entirely.
• Update host — a small latest.json plus the platform binary when an update is available. No version-of-installed reporting.
• MCP servers — only the MCP protocol traffic. EasyCC adds nothing; stdio MCP servers don't leave the device at all.

Local-only data (never leaves the device unless you've configured something to send it):

• Files under the agent folder
• Chat history (.easycc/chats/)
• Version history (.easycc/history/)
• Learned preferences (.easycc/learning/)
• Sign-in tokens (OS keychain)
• App settings

Signing

Two independent signing layers.

OS-level signing (install-time trust):

Update signing (runtime trust):

The auto-updater verifies every update against a minisign public key baked into the app binary at build time. A tampered update binary fails verification and is rejected — even if your mirror is compromised.

Loss or compromise of a signing key triggers revocation and a new key/binary ships; users see a one-time re-install prompt.

Telemetry

Off by default. When on (Settings → Advanced → Telemetry, or telemetry_enabled policy), EasyCC sends:

• Anonymized feature counts (settings_opened: +1, skill_run.summarize: +1)
• Crash reports (stack trace, OS version, anonymous user ID)
• Performance metrics (cold-launch time, memory, latency)

Never sent in telemetry, regardless of the toggle: chat content, file content, file names or paths, credentials, MCP server output, anything the user typed.

To lock telemetry off across a fleet:

{
  "policy": {
    "telemetry_enabled": { "kind": "enforced", "value": false }
  }
}

Service-provider partners can route telemetry to their own endpoint with telemetry_endpoint. Every telemetry batch writes a telemetry_sent entry to the device log so you can audit per-machine.

Compliance posture

EasyCC is pursuing SOC 2 Type II (target: late 2026). The internal control set is already aligned with the SOC 2 Trust Service Criteria; a formal Type I scope is in flight. For specifics on timing and the in-flight report, contact your EasyCC representative.

Today, what your review team can verify themselves:

Air-gapped deploys

For zero outbound traffic except to your own infrastructure:

• Point chats at your own gateway (Bedrock, Vertex, Foundry, or a custom proxy) — no direct Anthropic calls.
• Run a self-hosted update mirror; set the update_endpoint policy.
• Mirror the safety scanner model; set safety_custom_model_url_base.
• Use stdio-only MCP servers; no HTTP MCP servers.
• Lock cloud connectors off.

That set of controls lets EasyCC run with no traffic outside your perimeter.

Known limitations

• No FIPS-validated cryptography. EasyCC uses OS-native TLS, which on Windows means SChannel and on macOS means Network.framework — these are not themselves FIPS-validated. If your fleet requires FIPS 140-3, please get in touch.
• No EU sovereignty guarantee in the default Anthropic deployment. Route chats through a region-pinned gateway if required.
• No SCIM / directory sync in v1. SCIM is on the v2 roadmap.

Where to look next

• Configuration — the managed-policy fields you can lock for compliance.
• Bundles — pre-seed a fleet with a known-good policy + skill set.
• Support — log paths, network endpoints, troubleshooting.