Security overview

1. Keeping workspaces apart

Every record belongs to exactly one workspace, and every request is scoped from the account that made it rather than from anything the browser sends. A user cannot ask for another workspace’s data by changing an identifier, because the workspace is never taken from the request in the first place.

A conversation is keyed by the workspace, the channel, the business identity that received the message and the customer — so the same person reaching two businesses, or reaching one business through two numbers, produces separate conversations that never merge.

Where several businesses share one platform number, which business a conversation belongs to is recorded using a salted one-way hash of the customer’s identifier rather than the identifier itself.

2. Signing in

• Passwords are stored hashed, never in a readable form, and repeated failed attempts lock an account.
• Access tokens are short-lived — capped at fifteen minutes in production — so a leaked one is useful only briefly.
• Refresh tokens rotate on every use. If an old one is replayed, which is what a stolen token looks like, the entire session family is revoked rather than the attacker being handed a fresh token.
• Permission is re-checked against the database on every request, so disabling an account, changing a role or suspending a workspace takes effect immediately rather than when a token expires.
• Multi-factor authentication is enforced for platform operator accounts in production and available to workspace administrators; the authenticator secret is encrypted at rest.
• Console sessions live in host-only, httpOnly cookies that JavaScript cannot read, protected by an origin check on every state-changing request. The cookie notice names them.

3. Encryption

In transit: everything runs over HTTPS. The production configuration refuses to start if a provider endpoint is not HTTPS, if the connection to the cache is not encrypted, or if a managed database connection is downgraded to plaintext — a misconfiguration fails loudly instead of quietly running unencrypted.

At rest: the managed database and object storage apply their providers’ own encryption at rest, which is their commitment rather than ours to guarantee. On top of that the platform encrypts specific things itself, so that a copy of the database alone does not hand over credentials:

• WhatsApp and Telegram credentials for every connected channel;
• multi-factor authentication secrets and invitation payloads;
• the bodies of operational emails, which are cleared once delivery finishes;
• uploaded knowledge documents while they wait to be indexed, and the text extracted from customer documents.

Encryption keys are held in the deployment’s secret manager, and the channel key supports rotation: a new key becomes the encrypting key while the old one remains decrypt-only until everything has been re-encrypted.

4. Making sure a message really came from the channel

Inbound WhatsApp webhooks are verified with a cryptographic signature over the original request body, checked against the secret of the channel that owns the number. A forged webhook does not reach the pipeline.

A channel cannot be enabled until the whole path has been proven end-to-end, and if verification later fails the channel is disabled automatically. A visible outage is better than silently dropping a customer’s message.

5. What ends up in logs

Logs are for diagnosing faults, and they are one of the easiest places for personal data to leak. Email addresses, phone numbers, URLs, bearer tokens, signatures and stack traces are redacted at the logging boundary, so a value has to survive that filter to be recorded.

Operational analytics store categories and counts — how a conversation turn ended, how long a reply took, how many tokens it used — with no message content and no customer identifier. Where the platform needs to recognise a repeated question, it uses a hash of the normalised request rather than the text.

6. Audit trails

Actions that change security-relevant state are recorded with who did it, what they touched and the reason they gave: channel credential changes, routing changes, platform configuration, privacy exports and deletions, media operations, and workspace or account deletion.

Two of these trails are append-only at the database level: an attempt to modify or remove a row is rejected by the database itself, not merely by the application. Audit rows never carry message content, and privacy audit rows identify the person by a salted hash rather than by their phone number or user id — so the record that something was erased does not recreate what was erased.

7. Files a customer sends

Reading an untrusted file is one of the riskiest things a system can do, so the order of operations matters:

• Scanned before anything opens it. A file is checked by a malware scanner before any parser touches the bytes, because probing a file to identify it is already parsing it. If the scanner is unavailable, the file is not parsed at all — the check fails closed.
• The bytes decide what it is. The filename, extension and the type the provider claims are ignored. Executables, archives, macro-enabled documents, password-protected files and PDFs containing active content are rejected outright.
• Extraction runs under hard limits on pages, characters, rows and time, and spreadsheet formulas are treated as inert text.
• Infected files are deleted without being parsed, recorded as a security event, and can never be downloaded through the application. The customer gets a neutral message that names no scanner or signature.
• Storage is private. Files are stored under opaque keys the backend generates, partitioned per workspace, with no public access and no shareable links. Customer filenames never appear in a storage key.

8. The AI layer

The assistant is treated as a component that can be wrong or manipulated, and the guardrails around it are ordinary code rather than instructions to the model:

• Content from customers is data, never instructions. A document or message telling the assistant to ignore its rules is text to be summarised, not a command. Documents are never added to the knowledge base automatically, and are never used to confirm a payment or verify an identity.
• Sensitive fields are refused. The assistant will not ask for card numbers, security codes, PINs, passwords, one-time codes, bank details or government identity numbers, and will not store them as conversation state, whatever a configuration requests — recognised in English, French and Spanish.
• Promises are checked. A reply claiming an ability the platform does not have is replaced before sending; an action agreed to is recorded as under way and can only be reported as done once it genuinely completed.
• Reuse is gated. Answers containing email addresses, phone numbers, long card-like numbers or labelled codes are kept out of the answer-reuse cache, and text stored for optional quality review has those values masked first.
• Conversation working state is short-lived — it expires thirty minutes after the last message, is kept separate from durable customer memory, and is re-validated against the same limits when read back.

9. Deletion and retention

Data has a defined end, not just a beginning. Temporary state expires on a timer; inactive conversations the assistant handled are swept after the configured retention period; delivery records and duplicate-delivery protection records are pruned on their own schedules; raw uploaded files are deleted as soon as their text has been extracted, by default.

A workspace administrator can export or erase one customer’s data. The erasure is serialised with message processing, so work accepted just before it either completes and is removed, or is suppressed afterwards — a reply cannot arrive after someone asked to be forgotten. The Privacy Policy lists exactly what it removes, including the two record types it does not yet cover.

Deleting a whole workspace removes everything it owns in a single transaction — either all of it goes or none of it does — and the files in object storage are removed by a cleanup job that commits with that transaction, so a crash cannot leave them behind. Platform audit records survive by design, and carry no message content.

10. Backups and recovery

Database backups are encrypted before they leave the host, so the backup file is unreadable without a key held separately from the application. They are taken on a schedule, kept for a rolling window, and stored separately from the running system.

Restoring is a documented procedure with an integrity checklist, and it is practised rather than assumed: the most recent documented restore drill was on 2 August 2026, into a disposable database, verified against that checklist. Recovery times measured at drill scale do not yet prove recovery times at production scale, which is stated in the runbook and repeated here rather than glossed over.

Because backups are not edited individually, data you delete leaves them as they age out and are pruned, not at the moment of deletion.

11. How changes reach production

• Every change goes through version control and automated checks: linting, type checking, an extensive test suite, dependency auditing, and database migration checks.
• Risky capabilities ship behind switches that default to off — document reading, image reading, transcription and web search all had to be deliberately enabled.
• The production configuration validates itself at startup and refuses to run with weak keys, an unencrypted datastore connection, disabled multi-factor enforcement, a non-HTTPS provider endpoint or unprotected metrics. A misconfigured deployment fails to start rather than serving traffic insecurely.
• Public surfaces carry strict security headers and a content security policy, request size limits, and rate limiting.

The product documentation describes how these appear in the console.

12. What we do not claim

• No certification. No SOC 2 report, no ISO 27001 certificate, and no independent audit of the controls above.
• No uptime guarantee. No service level agreement and no service credits.
• No data residency guarantee. Providers operate internationally and the AI provider may route a request onward. See the sub-processor list.
• No end-to-end encryption of messages. The platform reads a message in order to answer it, and staff with production access could in principle see conversation content. Access is limited to people who need it to operate the platform.
• Redaction is best-effort. Masking of card-like numbers, codes and contact details is pattern matching. It catches the common cases; it is not a guarantee, which is why short retention rather than filtering is the real protection.
• Duplicate delivery is possible in rare cases. Messaging providers that offer no idempotency key cannot guarantee a message is delivered exactly once if a crash happens at exactly the wrong moment.
• Scale is not certified. Performance and isolation under very large load have not been independently verified.
• Organisational controls are still being formalised. Background checks, security training and formal policy review are marked as open items in the DPA security annex rather than claimed here.

13. Reporting a security problem

If you find a vulnerability, tell us at [SECURITY CONTACT] or support@tephlo.com. Include enough detail to reproduce it, and please do not access, modify or retain anyone else’s data while investigating.

Contact

General questions about this document go to support@tephlo.com. Questions about personal data, including requests from individuals, should go to the data protection contact at [DATA PROTECTION CONTACT]; until that address is published, the general address above reaches the same team.

Postal address: [REGISTERED COMPANY NAME], [REGISTERED ADDRESS].