Trust center

Security at Fluenta

A concrete view of the controls Fluenta implements today, the data they cover, and the areas still to be built.

Encryption

Connections to Fluenta use HTTPS in transit.

Secrets are encrypted before storage with AES-256-GCM. The stored format is iv:tag:ciphertext, and the encryption key comes from the ENCRYPTION_KEY environment variable.

This encryption at rest covers these secret values:

  • WhatsApp access tokens and app secrets.
  • Connector credentials.
  • Payment-provider secrets and webhook secrets.
  • AI-provider API keys.
  • Outbound webhook signing secrets.

Tenant isolation

Every bot carries a workspaceId foreign key. A membership join table connects each user to a workspace and its role.

When access crosses a workspace boundary, Fluenta returns a 404 rather than a 403. That prevents a response from revealing that another workspace or its resource exists.

Access control

Workspace roles are ordered from least to greatest privilege: viewer < agent < editor < owner. Routes enforce their minimum required role.

Secret values are masked in the user interface.

Where data lives

Fluenta stores application data in PostgreSQL 17 with pgvector. Uploaded knowledge-document blobs are kept in blob storage.

Outbound request safety

HTTP nodes apply an outbound request guard designed to reduce server-side request forgery risk:

  • Private and loopback IP ranges are blocked.
  • Redirects from HTTPS to HTTP are blocked.
  • Credentials are stripped when a redirect crosses origins.
  • Responses are capped at 256 KB.
  • Requests time out after 10 seconds.

Webhook authenticity

Meta webhook signatures use HMAC-SHA256 over the raw request body and are checked against x-hub-signature-256. A mismatch receives a 401 response.

  • Stripe webhook signatures use HMAC-SHA256.
  • Paystack webhook signatures use HMAC-SHA512.
  • Outbound webhooks are HMAC-signed with an encrypted secret unique to each endpoint.

Retention and deletion

A scheduled job automatically purges expired conversation data after 90 days. When that retention process runs, orders are anonymised by nulling the phone number, customer text, Meta message ID, and conversation ID. Audit events for revealed identities are also deleted after 90 days.

Read how deletion works for each data class.

Audit trail

The audit_events table records privileged actions.

Backups

Scheduled database backups run on a timer.

Restore testing and a formal recovery point objective / recovery time objective (RPO/RTO) are not yet documented.

What we do not have yet

Here is exactly where we are today:

  • No SOC 2, ISO 27001, HIPAA, PCI, or other certification or audit.
  • No two-factor authentication.
  • No application-level rate limiting.
  • No self-service data export.
  • Account deletion is handled by request, not through a self-service control.
  • Logs are not yet guaranteed to be free of personal data.
  • No public status page.
  • No uptime SLA.

Reporting a vulnerability

Please report a potential vulnerability to [email protected].

Include a concise description, steps to reproduce or an affected URL, the potential impact, and a safe way to contact you. We will acknowledge receipt.