Security

condense.chat is a context-compression proxy for LLM workloads. Conversations, prompts and compressed context flow through our infrastructure, so security and privacy are not features; they are the product. This page documents the controls we operate today: how engineers reach internal systems, how data is encrypted and retained, how we detect and respond to incidents, and where we stand on SOC 2, GDPR and other compliance regimes.

Authentication & access

Customers authenticate through Clerk with email + password, magic links, passkeys or OAuth. Every internal system (deployment, observability, secret stores) sits behind Google Workspace SSO with 2FA enforced at the identity provider, and an audited allowlist of staff accounts.

• Google SSO for all internal services (deployment, observability, source control and admin tooling).
• Hardware-backed 2FA required for staff accounts; password-only access is disabled.
• Admin and observability planes are reachable only over the Tailscale mesh, with no public ingress.
• Operator-only endpoints additionally require HTTP Basic credentials provisioned per engineer.
• Workloads authenticate to cloud services with short-lived, automatically rotated credentials, so no long-lived cloud keys are stored in our systems.

Encryption in transit & at rest

• TLS 1.2+ on every public endpoint, with HSTS forcing HTTPS across all subdomains.
• AES-256 encryption at rest for all databases, caches and object storage, with keys managed in AWS KMS.
• Connections to our databases require verified TLS.
• Secrets are stored in AWS Secrets Manager and rotated into the cluster via the External Secrets Operator.
• Strict Content-Security-Policy, Referrer-Policy, and Permissions-Policy headers on every HTML response.

Infrastructure & isolation

• Hosted on AWS and Google Cloud in the EU; all customer data is stored and processed in the EU.
• Container workloads run as non-root, with hardened, read-only filesystems and enforced isolation policies.
• Version-controlled deployments: every production change is reviewed and approved before release, and operators never push to production by hand.
• Immutable, encrypted PostgreSQL backups retained with point-in-time recovery; backups are restore-tested.
• Staging and production run in fully separated networks, with isolated access controls and encryption keys.

Audit logging

Every privileged action on our admin and billing surfaces is written to an append-only audit trail. Identifiers are pseudonymised with keyed hashing (HMAC-SHA256) and IP addresses are truncated before storage, and the trail is protected at the database level so records cannot be altered or deleted.

• Tamper-evident, append-only by design; entries can be added but never edited or removed.
• Pseudonymised actors, so raw user identifiers never leave the application boundary.
• 1-year retention in primary storage, with copies kept in our central log store for long-term search.
• Structured logs with correlated request IDs across every service.

Monitoring & incident response

Automated alerts fire within 1 to 5 minutes for authentication anomalies, rate-limit spikes, error-rate regressions and any gap in the audit trail. Alerts page on-call directly, and the dashboards our team watches are the same ones we draw evidence from during reviews.

• Per-IP and per-account rate limiting on the public API.
• Request size limits to mitigate abuse.
• Documented runbooks and a defined on-call rotation back every alert.

Supply chain & vulnerability management

Every code change runs an automated security workflow covering secret, static-analysis and dependency scans across our whole codebase.

• gitleaks: secret scanning.
• bandit + semgrep: Python SAST.
• pip-audit: Python dependency CVEs.
• npm audit: JavaScript dependency CVEs.
• trivy: container image scanning.
• SPDX SBOM generated for every release.
• Vulnerability SLAs: critical < 3 days, high < 10 days, medium next sprint.

Your data & privacy

• We store only what is needed to run the service (compressed context and usage metadata), and it stays in the EU.
• Content is deleted after 7 days. Conversation content and compressed context are retained for a maximum of seven days, after which they are hard-deleted from primary storage. Aggregated usage metadata is retained longer for billing and abuse prevention.
• We do not use your data to train models.
• GDPR Art. 17 (right to erasure) and Art. 20 (data portability) are supported. To request a data export or deletion, email team@condense.chat.
• For customer data we are a Data Processor under the GDPR; our standard DPA covers Articles 28 to 32.
• A Zero-Data-Retention store is available for customers who require it: nothing is persisted beyond the response.

What we can and can't see

condense.chat is a proxy, so your prompts and context pass through our service in order to be compressed. We are deliberate about what that means for your data, and we would rather state it plainly than leave it implied.

• In transit: to compress a request we process its content in memory. This is inherent to a proxy and is required for the service to work.
• At rest: only compressed context and minimal usage metadata are stored, for at most 7 days, after which they are hard-deleted. We never sell this data or use it to train models.
• Zero-Data-Retention mode: when enabled, request content is not persisted beyond returning your response.
• Human access: operators can reach stored content only through restricted, audited paths, and every such access is recorded in the append-only audit trail (see Audit logging).
• Beyond our boundary: the upstream model you target receives your request directly. That provider is your own relationship and is outside our control (see Subprocessors).

Compliance

Subprocessors

All sub-processors are bound by written contracts that impose data-protection obligations no less protective than those in our Data Processing Addendum. Each is subject to appropriate transfer safeguards (EU Standard Contractual Clauses, UK Addendum, and Swiss modifications where applicable).

Reporting a vulnerability