Trust & Security

Every site credential, API token, TOTP seed, and captured session cookie is sealed with per-tenant envelope encryption:

• A 256-bit data-encryption key (DEK) is generated for each organization and used to AES-256-GCM the secret locally.
• The DEK itself is wrapped by a key-encryption-key (KEK) held in Google Cloud KMS. The unwrapped DEK never leaves the application process; the KEK never leaves KMS.
• Stored ciphertext is self-describing (v2:<keyId>:…), so keys can be rotated without re-reading every row.
• A database dump alone yields no credentials — recovery requires KMS access to the tenant's KEK.
• BYOK is available for enterprise tenants: enrol a Cloud KMS key in your own GCP project and grant our service account encrypt/decrypt on it. We re-wrap the organization's DEK under your KEK and you can revoke our access at any time. Configured by the organization owner from the org settings page.

LLM calls are an obvious egress point. Each organization controls, from its settings page:

• LLM tracing opt-out — prompts and responses are never sent to our observability tooling for this tenant.
• Third-party rerank opt-out — retrieved content stays in-house and is never sent to a reranking provider.
• PII redaction before egress — emails, phone numbers, national IDs (incl. Swedish personnummer and US SSN), IPv4 addresses, and payment card numbers are scrubbed from prompt text before it reaches any LLM provider.

Defaults preserve current behavior; enterprises opt into the stricter posture without changing any application code.

Every table enforces Postgres Row Level Security. Users see only their own rows, or rows belonging to an organization they are a member of. Organization membership has four roles (owner, admin, member, viewer); org-scoped policies are additive on top of personal-ownership policies.

The service role (which bypasses RLS) is confined to server-side code that genuinely needs it — e.g. decrypting credentials at the moment a run launches.

Customers choose how Bacheon authenticates into their portals. We never need — and for SSO/MFA sites never receive — the customer's primary password:

• Password — encrypted username and password, optionally with a TOTP second factor.
• API token — encrypted token applied as an HTTP header.
• Interactive session — cookies and storage captured after the user logs in themselves in a live browser. Handles SSO, MFA, captcha, and magic links.

Each customer can configure retention windows. Defaults:

• Raw metric values — 30 days
• Aggregated rollups — 365 days
• Screenshots — 7 days (deliberately short)
• AI reports — 365 days
• Chat history — 365 days

A scheduled job enforces these windows; expired data is hard deleted.

SOC 2 Type II is an audited attestation, not a feature: it requires an auditor to observe controls over a 6–12 month window. We do not hold one today. We operate as SOC 2-ready and the formal engagement is in progress.

GDPR — we sign a Data Processing Agreement with each customer, maintain the sub-processor list above, and honour data-subject deletion requests through the retention pipeline.

Zero-retention LLM terms — the chat path sets a 24-hour OpenAI prompt-cache window; longer retention with individual providers is governed by their enterprise terms, which we confirm before processing customer data through them.