Security

Our commitment

BayChat is built and operated by SENEKO d.o.o. from Slovenia. Security is part of the product, not a layer on top. We design for least privilege, encrypt sensitive data both in transit and at rest, isolate tenants at the database layer, log privileged actions to an immutable audit trail, and treat operational mistakes as the most likely cause of an incident — so we automate where we can.

This page summarises the technical and organisational measures we have in place today. It is a snapshot of a moving target; we will update it as the service evolves.

Article 1 — Encryption

In transit — All traffic between user devices and BayChat is protected with TLS 1.3 (with TLS 1.2 supported only for legacy clients). HSTS is enabled on baychat.io. Certificates are issued by publicly trusted certificate authorities and renewed automatically.

At rest — Message bodies and sensitive fields are encrypted at rest using AES-256-GCM with per-tenant key derivation. Database disks are themselves encrypted at the volume layer. Encryption keys are managed in a separate, restricted vault and rotated on a defined schedule. Backups inherit the same encryption.

Article 2 — Authentication and access control

User passwords are hashed using a memory-hard algorithm with a per-user salt; plaintext passwords are never stored or logged. Sessions are authenticated with short-lived JWT access tokens and longer-lived refresh tokens; refresh tokens can be revoked from the user's session list.

Agent integrations authenticate with API tokens prefixed bay_*. We store only the SHA-256 hash of each token — the plaintext value is shown to you once at creation and cannot be recovered afterwards. Agent permissions follow a least-privilege model: read-only by default, scoped per resource, optionally time-bound, and revocable at any time with a one-tap kill switch on every agent.

Article 3 — Multi-tenant isolation

BayChat is a multi-tenant service. Every query that touches user content is scoped by a verified tenantId derived from the authenticated session; cross-tenant access is treated as a fatal error and rejected by the data layer. Cache keys, file paths, and audit-log entries all carry the tenant identifier. New endpoints are reviewed against a checklist that requires explicit tenant scoping before they ship.

Article 4 — Infrastructure

Production runs on dedicated virtual servers from Contabo GmbH in Germany (EU). Traffic reaches the application through a Cloudflare Tunnel, with Cloudflare providing DNS and edge protection (DDoS mitigation, WAF). The Postgres database, Redis cache, and supporting services are isolated in a private network and reachable only through the application layer. All workloads are containerised with Docker and orchestrated through Docker Compose; 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:

• Static analysis: TypeScript strict mode in both API and frontend; linting on every commit; dependency-vulnerability scanning on every build.

• Code review: all changes to production code go through pull-request review; security-sensitive changes (authentication, encryption, tenant scoping) require an additional reviewer.

• Secrets: secrets are held in environment files outside the repository; access to production secrets is restricted to a small set of authorised personnel.

• Input validation: all API endpoints validate inputs at the boundary using schema validation; outputs are filtered to avoid information disclosure.

• Web hardening: appropriate security headers (CSP, X-Frame-Options, Referrer-Policy), CSRF protection where applicable, rate limiting on authentication and write paths.

Article 6 — Operational security

Privileged actions — agent token creation, permission changes, administrative operations — are written to an immutable audit log that customers on paid plans can export. Application errors and infrastructure metrics are collected to a monitored telemetry stack; alerts page the on-call engineer. Access to production systems is limited to a small set of authorised personnel and is logged. Production access is reviewed periodically and revoked when no longer needed.

Article 7 — Sub-processor security

Every sub-processor we use is contractually bound to confidentiality and security obligations consistent with GDPR Article 28. Our current sub-processors and the data they receive are listed on our GDPR page. We assess new sub-processors before onboarding and review existing ones periodically.

Article 8 — Backups and disaster recovery

Encrypted database backups are taken on a regular schedule and retained for up to 35 days, then rotated. Restore procedures are documented and tested. 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; we work to improve both over time.

Article 9 — Compliance and certifications

BayChat is operated in compliance with the EU General Data Protection Regulation and the Slovenian Personal Data Protection Act (ZVOP-2). Our supervisory authority is the Information Commissioner of the Republic of Slovenia.

We are actively building toward SOC 2 Type I: we have implemented foundational controls (encryption, access control, logging, change management, vendor review) and are documenting the policies and evidence needed for an independent assessment. SOC 2 is not yet certified; we will publish the report once available.

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.

SENEKO d.o.o. — BayChat, Liminjanska c. 25, 6320 Portorose, Slovenia.