The stance, on record
Client-side encryption, ciphertext-only storage, zero plaintext persistence, Strict mode, and self-hosting are available at every tier, including Free. Enterprise does not get “more encrypted.” It gets proof and control: BYOK, SOC 2 attestation, audit exports, and policy enforcement. Baseline security is never gated behind pricing.
What runs where
- Free and Pro are local software. The MCP server runs on your machine, reads only the project root you point it at, and makes zero network calls by default. There is no account, no telemetry unless enabled, and no server of ours in the path.
- Redaction happens before storage. Secret-looking content (cloud keys, tokens, private keys, JWTs, credential assignments) is redacted before it enters any snapshot or store;
.env*, key files, and credential files are never read at all. - Sync is additive and opt-in. When you create a vault, records are encrypted on your device (keys derived from your passphrase via Argon2id; per-blob XChaCha20-Poly1305, each ciphertext bound to its slot) before anything is uploaded. Storage holds ciphertext under opaque ids; blob names leak nothing.
Sync modes, stated honestly
The distinction is where the MCP client runs. If it runs on hardware you control, it can decrypt locally. If it runs on someone else's servers (chatgpt.com, claude.ai), tool results must reach their edge as plaintext to feed the model. Pure zero-knowledge serving of hosted chat apps is impossible, and we do not pretend otherwise.
- Standard: ciphertext-only storage; for an authorized request a worker decrypts in memory, answers over TLS, and discards. No plaintext at rest anywhere, including logs. Encrypted at rest and in transit, zero plaintext persistence. Not zero-knowledge.
- Strict: true end-to-end. The relay can never decrypt; only devices holding the passphrase-derived key can read. Trades away hosted chat apps.
- Self-hosted relay: the same open-source build, on your infrastructure. Roaming works and the momentary plaintext happens on hardware you control.
Key recovery is passphrase plus a printed recovery code. We cannot reset a Strict vault. Vault deletion destroys its keys: crypto-shredding.
Enterprise controls (BYOK and federation)
- BYOK: serve-time data keys live in your KMS (AWS KMS, GCP KMS, Azure Key Vault) under envelope encryption. ctxfile infrastructure never holds decryptable material for BYOK orgs; revoking your CMK makes the data instantly unreadable.
- Federated grants: org-to-org sharing is scoped (thread-level), least-privilege by default (read-only, single thread, 7-day expiry), signed by the issuing org's key, verified on every redemption, revocable instantly, and filtered through redaction profiles at issuance and at serve time.
- Hub-to-hub, not through us: federated hubs exchange grant-scoped context over mutual-TLS MCP. No central ctxfile server sits in the data path unless both orgs opt in.
- Audit: append-only log of every read, write, grant, and redemption with org, agent, and human attribution; exportable to your SIEM.
Prompt-injection posture
Everything served carries provenance labels (parser-read vs agent-reported, which harness, which door, which org). Ingested and federated content is quarantined as untrusted data, and the tool descriptions say so to the model. A partner org's compromise must not become yours.
Compliance roadmap
- SOC 2 Type I: targeted four months from Enterprise build start; Type II within twelve.
- DPA, security questionnaire pack (CAIQ-lite), and SLA terms available for pilots.
- Data residency: self-hosting answers it by default; managed hubs pin a region.
Verify, then trust
The core and the relay are open source. The privacy claims on this site are the literal behavior of the code, and the code is the audit surface. Responsible disclosure: security@ctxfile.dev. Questions from a security review: hello@ctxfile.dev.
Deeper reading: Sync & roaming, Privacy & redaction, Threads & handoff.