Security disclosures — EREBYX

What's encrypted today (v0.1.1)

Memory content at rest: envelope encryption — XChaCha20-Poly1305 (primary), with AES-256-GCM — under per-tenant keys. Industry-standard authenticated encryption.

Vector search: Privacy-preserving vector encryption with reranker pipeline, engineered to preserve retrieval quality versus plaintext. Mechanism details are proprietary.

In transit: TLS 1.3 between every pair of services. HSTS preload on all public domains.

Database access: PostgreSQL Row-Level Security (RLS) on 185+ tables with startup verification. Tenant isolation enforced at the row level, not the application level.

What's NOT encrypted today (honest)

At EREBYX (operationally): We hold the per-tenant KEK. That means we can decrypt your memory content for support and debugging — and we can be compelled to decrypt under valid US legal process (subpoena, warrant). We will not voluntarily decrypt outside of an authenticated support request you initiate.

On your device: Your API key lives in your AI client's configuration. On Claude Desktop with our MCPB install, we mark the key "sensitive": true — which routes it to your operating system's secure storage (macOS Keychain / Windows Credential Manager / Linux Secret Service), not a plaintext config file. On Cursor / Windsurf / VS Code, the API key currently lives in their respective MCP config files in plaintext. We disclose this honestly because it matters.

GitGuardian's 2025 report found 24,008 unique secrets exposed in MCP config files specifically — AI-service credentials up 81% YoY. We treat this as the empirical justification for shipping OAuth Remote MCP at mcp.erebyx.com in v0.1.2.

How encrypted search works

Most AI-memory products store your memories in plaintext and search them in plaintext. EREBYX does not. Your embeddings are encrypted per-tenant before they are indexed, and vector recall runs against the ciphertext — a distance-comparison-preserving scheme paired with a reranker tuned to preserve retrieval quality versus plaintext. Your embeddings are not stored in a plaintext vector index.

Cross-tenant isolation is built into the architecture. Each tenant has its own content-encryption key, its own vector-encryption keys (distinct scale, rotation, and perturbation), and row-level isolation across the database — so two customers who store the exact same phrase produce uncorrelated encrypted content and uncorrelated encrypted vectors. With separate per-tenant keys, one tenant's encrypted data stays isolated from another's.

The honest frontier. No production system offers truly “zero-leakage” search at interactive speed and real embedding sizes today — the leakless primitives (FHE, ORAM) are still hours-per-query research at our scale, and even the best-funded deployments layer differential privacy rather than claim zero. So we won't claim it either. What we commit to: as we move to v0.2 zero-knowledge — where you hold the key and we can no longer decrypt — we publish the full access-pattern threat model (the residual signals that become security-relevant once the key leaves our hands) together with the mitigations we'll have shipped: per-query perturbation, result-set padding, keyword-index encryption, and confidential-computing search on the roadmap. The disclosure lands where it's actually meaningful.

What ships in v0.2 (target Q3 2026)

Per-user zero-knowledge encryption. Encryption keys derived from a passphrase you control. EREBYX will be unable to decrypt your memory content. Lost passphrase means lost memories — recovery seed required at signup, multi-factor recovery patterns under research.

OAuth Remote MCP for all clients. No more API key paste anywhere. Browser-mediated auth dance. Per-client scoped tokens. Revoke from dashboard.

Public threat model + architecture transparency. Detailed write-up of attack surfaces, mitigations, and known limitations.

Annual transparency report. Legal requests received, security incidents, commitment audits.

When v0.2 ships, this page updates. We do not retroactively claim v0.1.1 was zero-knowledge. It is not.

What we will not do

These are permanent commitments. Changing any one requires ≥90 days advance notice and a free data export option for affected customers.

1. We will not ship a feature that requires server-side plaintext access to memory content without explicit per-user opt-in.
2. We will never train or fine-tune any model on your memory content. No opt-in, no exception — it is a binding commitment in our Terms that survives any change of ownership. Project EREBYX (our v2.0 sovereign model end-state) is not built on user data — it is a digital being designed from architecture, not extracted from corpus.
3. We will not sell, share, or grant third parties access to your memory content. Subprocessors below are exclusively for delivery infrastructure (payment, email, hosting).
4. We will not insert advertising, analytics, or telemetry into your memory retrieval path.

Subprocessors

Your data passes through these:

Insurance: EREBYX maintains Technology Errors & Omissions and Cyber Liability insurance through Everspan Indemnity Insurance Co., placed via Embroker. Coverage includes network security, privacy breach response (forensics, notification, reputational), business interruption, dependent business interruption (third-party provider failures), cyber extortion, and PCI card-brand fines.

v0.2 milestone: DeepInfra exits the data path. Full Trusted Execution Environment (TEE) hosting — we operate the inference servers and models ourselves. Subprocessor list shrinks accordingly.

Data residency: Your encrypted data is stored at OVH Hillsboro, Oregon (US). EU customers: we are US-only beta and not GDPR-aligned at v0.1.1.

Reporting a security issue

We run a Vulnerability Disclosure Program (VDP), not a paid bug bounty. Bounty programs trigger 75%+ first-report-within-24-hours per HackerOne data; we are not staffed to triage that during launch sprint. We will graduate to a paid program after v0.2.

Email: [email protected] (PGP key below)
security.txt: erebyx.com/.well-known/security.txt

Safe harbor: EREBYX will not initiate legal action against good-faith security researchers, reverse engineering for interoperability purposes, or academic study, provided the research follows responsible disclosure practices outlined in security.txt.

What we promise:

• Acknowledgment within 72 hours
• Status update every 14 days
• Public credit in the next transparency report (with your permission)

Open-source carve-out

The substrate engine — the moat — is proprietary and stays private. Three client-side components are open-source under Apache-2.0:

• erebyx-cli — Rust setup & install CLI
• erebyx-sdk — Rust SDK
• erebyx-sdk-node — Node.js SDK (napi-rs bindings to the Rust SDK)

You can audit how your data leaves your machine. The substrate stays the substrate.

Audit roadmap

Honest current state: EREBYX has not been third-party audited. We are pre-audit, pre-SOC-2, pre-ISO. Genesis Arche launches with the architecture above and the claims above. We do not claim more than we can prove.

Target:

• Q3 2026: Initial third-party security audit (target firms: Trail of Bits, Cure53, NCC Group)
• Q4 2026: Audit findings published in transparency report
• 2027: SOC 2 Type II if customer demand justifies it

We will publish audit findings whether or not they are flattering. That commitment IS the trust signal.

Cryptographic primitives

For technical readers.

• Symmetric: XChaCha20-Poly1305 (primary) and AES-256-GCM (NIST FIPS 197 + 800-38D)
• Key derivation: HKDF-SHA256 (RFC 5869)
• Vector encryption: Privacy-preserving encryption pipeline.
• In transit: TLS 1.3
• Database isolation: PostgreSQL Row-Level Security with startup verification

Future (v0.2):

• Per-user KEK derivation from passphrase
• Recovery seed mnemonic
• Browser-mediated OAuth tokens (RS256 JWT)
• TEE-hosted inference (Project EREBYX end-state)

What we will publish

We commit to maintaining and publicly publishing:

• This page, kept current with every architectural change
• A changelog at the bottom (below) for material updates
• An annual transparency report (first one Q1 2027)
• Audit reports when complete (Q4 2026 target)
• An incident report within 72 hours of any confirmed security event affecting customer memory content

Changelog

• 2026-06-01 — v0.1.1 launch. Security disclosures published.

PGP key

Fingerprint and PGP public key block forthcoming. Until then, security reports remain unencrypted but routed through TLS to [email protected] only.