Security at TelyChat AI
Live Inbox, Social Studio and Engage & Automate all hold customer conversations, which makes security a product requirement, not a compliance exercise. Sessions use httpOnly cookies and are never accepted from a URL. Every tenant's data is scoped to their own account by the session, not by a parameter the caller can choose. Inbound webhooks are token-authenticated and fail closed. Uploaded documents are screened by file content rather than by the type they claim. If you find a problem, report it to [email protected] and a person will read it.
Core Security Architecture
Four structural layers that protect customer data before any line of code runs.
httpOnly Session Isolation
Authentication tokens exist strictly in Secure, httpOnly cookies. They are never exposed to client-side JavaScript or URL query strings, eliminating token theft via XSS.
Row-Level Tenant Partitioning
Every database query scopes to the verified tenant session ID. No request can query another account's knowledge base, leads, or chat conversations.
Deep Content Upload Screening
Uploaded documents are inspected by magic-byte content inspection. Macro-enabled office docs, active PDF scripts, and archive bombs are rejected before parsing.
Self-Hostable Infrastructure
Built entirely on open-source foundations (Chatwoot, Fastify, Supabase). Regulated enterprises can deploy on dedicated, on-premise infrastructure under full control.
How Are Accounts and Sessions Protected?
A session is an httpOnly, Secure cookie. It is deliberately not readable by JavaScript, and it is not accepted from a query string, because a token in a URL travels through every access log it passes and leaks through the Referer header. Logging out deletes the session row rather than only clearing the cookie, so a captured cookie cannot be replayed afterwards.
Login and signup are protected by Cloudflare Turnstile and by rate limits. Passwords are hashed with a modern, salted algorithm and are never stored or logged in plain text at any point in the authentication flow.
How Is One Customer's Data Kept Separate From Another's?
Each business is a fully isolated tenant, and every data query is scoped to the account derived from the validated session. A request cannot name a different tenant and read their records: the account identifier is never taken from the request body, query string or a custom header.
At the database layer, row-level security is enforced and the knowledge-base retrieval functions are restricted so that a similarity search can only ever return chunks belonging to the calling tenant. Those functions are explicitly revoked from anonymous database roles. This isolation applies identically whether you're using Live Inbox, Social Studio, or Engage & Automate, since all three read from the same tenant-scoped data layer.
What Happens to Data Coming Into the System?
Webhooks are authenticated and fail closed
Inbound messaging and job webhooks require a secret. If the secret is not configured, the endpoint refuses every request rather than allowing them, so a misconfiguration fails safe.
Uploads are judged by content
Documents added to a knowledge base are checked against their actual file signature, not the extension or MIME type they claim. PDFs carrying active content, documents with macros or external references, archive bombs and known test-malware signatures are rejected. Parsing happens in an isolated process with a memory ceiling and a deadline.
Retrieved content is treated as untrusted
Text pulled from a crawled website or an uploaded document is passed to the AI as quoted material inside a marked boundary that the content cannot close. Instructions found inside a document cannot change the agent's role or rules, and a passage that looks like an instruction attempt downgrades the answer to a more cautious mode.
Server-side fetches are restricted
When the crawler fetches a page it validates the destination at connection time rather than only before the request, which closes the window a DNS-rebinding attack relies on. Redirects are re-checked hop by hop, and loopback, private and link-local addresses are refused.
How Is the Service Hosted?
The application runs on servers we operate, behind Cloudflare for TLS termination, caching and DDoS protection. Secrets are held in server-side environment files that are readable only by the service account, not in the source repository and not in the browser bundle. On qualifying plans, you also have the option of running the entire stack on your own infrastructure, in which case none of your conversation data touches ours.
Payments are processed by Korapay. We do not store card numbers; card data goes to the payment processor and never reaches our servers.
Security Notes Per Product
Live Inbox
Channel credentials (WhatsApp, Instagram, Telegram tokens) are encrypted at rest and scoped to the connecting tenant only. Agent access is role-based, so a teammate only sees the inboxes assigned to them.
Social Studio
Social account connections use OAuth tokens stored encrypted, never a shared password. Revoking access from the platform side (Meta, TikTok, LinkedIn) immediately breaks the connection on our end too.
Engage & Automate
Automations run through official platform messaging APIs and respect each platform's rate and consent rules, so flows stay compliant with Meta and TikTok policy rather than relying on unofficial scraping.
How Do I Report a Security Issue?
Email [email protected]. Include what you found, how to reproduce it, and what you think the impact is. If the issue could expose customer data, say so in the subject line and it will be treated as urgent.
Please test only against your own account, and do not access, modify or retain another customer's data in the course of research. We will confirm receipt, keep you updated on the fix, and credit you if you would like to be credited.
Want the Details Before You Commit?
Ask us. If your process requires a security questionnaire, a data processing agreement, or the current subprocessor list before you can proceed, email us and we will work through it with you.