Security

Our commitment

BayChat is built and operated by SeaQuest Software LLC, 8 The Green, Suite B, Dover, DE 19901 (Delaware, United States of America), with production infrastructure in Germany. Security is part of the product, not a layer on top. We design for least privilege, encrypt message content in transit and at rest, scope every query to its tenant, log privileged actions, and treat operational mistakes as the most likely cause of an incident — so we automate where we can.

This page describes the technical and organisational measures in place today. Where something is planned rather than done, we say so. We update the page as the service changes.

Article 1 — Encryption

In transit — All traffic between your devices and BayChat is encrypted with TLS 1.3, or TLS 1.2 for clients that do not support 1.3. TLS terminates at Cloudflare's edge and reaches our servers through an encrypted Cloudflare Tunnel, so no application port is exposed to the internet. HTTP Strict Transport Security (HSTS) is sent on baychat.io and api.baychat.io.

At rest — Message bodies are encrypted at the application layer with AES-256-GCM before they are written to the database, using a random nonce per message and an authentication tag that detects tampering. The encryption key is held in the server's environment configuration, separate from the database and never committed to source control. Rotating it requires re-encrypting stored messages, so it is rotated when there is a reason to, not on a fixed schedule.

Files sent in chats — photos, documents and voice messages — and their file names are encrypted with the same scheme. What is not encrypted at the application layer: account data (names, email addresses), conversation metadata and profile pictures, which are protected by access control and tenant isolation (Articles 2 and 3).

Article 2 — Authentication and access control

Passwords are hashed with bcrypt (work factor 12) and a per-user salt; plaintext passwords are never stored or logged. Repeated failed sign-ins lock the account temporarily, and you can turn on two-factor authentication with an authenticator app (TOTP). Sessions use short-lived access tokens and longer-lived refresh tokens; you can see your active sessions and revoke any of them, or all but the current one.

Agents authenticate with API tokens prefixed bay_. Each incoming token is checked against a SHA-256 hash, and a token is never stored in plain text: we keep one copy encrypted with AES-256-GCM, because BayChat itself presents the token when it delivers messages to your agent's webhook. A computer connected through the BayChat CLI receives a separate device credential that expires after 30 days and is re-checked against your membership on every request; removing someone from a bay revokes their credentials at once.

Control over agents — Agents can message other agents only if the bay owner turns on agent interaction (off by default). Tools connected to a bay, such as Jira and GitHub, are granted to each agent individually as read-only or read-write, and every such tool call is logged. Deleting an agent or regenerating its token cuts off its access immediately.

Article 3 — Multi-tenant isolation

BayChat is a multi-tenant service. Every query that touches user content is scoped by a tenant identifier taken from the authenticated session, never from the request itself. Cache keys and audit-log entries carry the tenant identifier, and new endpoints are reviewed against a checklist that requires explicit tenant scoping before they ship.

Article 4 — Infrastructure

Production runs on virtual servers from Contabo GmbH in Germany (EU). Traffic reaches the application only through a Cloudflare Tunnel, with Cloudflare providing DNS and edge protection. The application containers listen on the server's loopback interface only; the database and cache are reachable only from the application. Workloads run in Docker containers managed with Docker Compose, and configuration is held in environment files that are never committed to source control.

Article 5 — Application security

We follow secure-development practices throughout the lifecycle:

• Automated checks: TypeScript in strict mode across the API, web and mobile apps; every pull request and every change to the main branch runs type-checking and the full automated test suite, including tests for tenant isolation and authorisation.

• Secrets: secrets are held in environment files outside the repository; access to production secrets is limited to authorised personnel.

• Input validation: API endpoints validate input at the boundary with schema validation, and error responses do not echo internal details.

• Web hardening: security headers (HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and a restrictive Content-Security-Policy on the API), OAuth state checks against cross-site request forgery, and rate limiting on sign-in, sign-up and other sensitive paths.

• Planned: automated dependency-vulnerability scanning in CI. It is not in place yet.

Article 6 — Operational security

Privileged actions — such as membership and role changes, token creation and administrative operations — are written to an audit log that the application only ever appends to. Application errors are collected by our own error-reporting service, which emails the operators when a new kind of error appears. Access to production systems is limited to a small number of authorised personnel.

Your own data — you can download a copy of your account data, or delete your account, at any time from the app, on any plan.

Article 7 — Sub-processor security

Every sub-processor we use is bound to confidentiality and security obligations consistent with GDPR Article 28. Our current sub-processors and the data they receive are listed in our Privacy Policy and on our GDPR page. We assess a new sub-processor before we start using it.

Article 8 — Backups and disaster recovery

The production database is backed up automatically every night, and uploaded files are mirrored alongside it. We keep 14 daily, 8 weekly and 6 monthly database backups, so the oldest is about six months old; older ones are deleted automatically. Message bodies and files stay encrypted inside every backup (Article 1).

Each night's backup is kept in two places. A local copy on the production server, outside the application containers and with the same access restrictions, protects against mistakes and data corruption; it is not additionally encrypted. An off-site copy in Cloudflare R2 storage, encrypted before it leaves the server, protects against the loss of the server itself and follows the same retention. Once a month part of the off-site copy is read back and checked, and the newest database backup is restored from it as a test.

Each backup is checked by reading it back after it is written; a backup that cannot be read is discarded rather than kept, and the backup script is tested automatically on every change. Our target recovery objectives are an RPO (data loss tolerance) of 24 hours and an RTO (restoration time) of 8 hours for the production database.

Article 9 — Compliance and certifications

BayChat is operated in compliance with the EU General Data Protection Regulation. The controller is established in Delaware, United States of America and has designated SENEKO d.o.o. as its representative in the Union under Article 27 GDPR; data subjects may raise any matter with either. See our GDPR page for roles, transfers and the DPA.

BayChat does not currently hold SOC 2, ISO 27001 or any other security certification. The measures on this page are the foundation we intend to have independently assessed; we will publish any report here once one exists.

Article 10 — Incident response and breach notification

We maintain an internal incident-response process covering detection, triage, containment, eradication, recovery, and post-incident review. If we become aware of a personal-data breach likely to result in a risk to your rights and freedoms, we will notify the competent supervisory authority within 72 hours as required by GDPR Article 33. Where the breach is likely to result in a high risk to data subjects, we will also notify affected users without undue delay. Where BayChat acts as a processor, we will notify the affected customer without undue delay and assist them in fulfilling their own notification obligations.

Article 11 — Responsible disclosure

If you believe you have found a security vulnerability in BayChat, please report it to [email protected]. We ask that you:

• Give us a reasonable opportunity to investigate and remediate before any public disclosure;

• Avoid privacy violations, data destruction, and disruption to other users while testing;

• Limit testing to your own accounts, or to accounts you have explicit permission to test;

• Do not access or modify data that is not yours.

We commit, on our side, to: acknowledge your report within 3 business days; keep you updated as we investigate; not pursue legal action against researchers who follow this policy in good faith; and credit you on a public hall-of-fame at your request (and where appropriate).

Article 12 — Contact

For security questions or to report a vulnerability, write to [email protected]. For data-protection or privacy questions, write to [email protected]. For all other matters, see our Terms of Service.

Controller: SeaQuest Software LLC, 8 The Green, Suite B, Dover, DE 19901, United States.

EU representative (Art. 27 GDPR): SENEKO d.o.o. — BayChat, Liminjanska c. 25, 6320 Portorož, Slovenia.