Security At ChatOTL
ChatOTL enforces isolation in the database rather than only in application code: every table carries an owner column with row-level security policies, uploads live in private buckets read through short-lived signed URLs, and elevated database helpers live in a non-public schema unreachable by anonymous clients.
This page describes how the application is built, so you can judge the boundary yourself instead of trusting a slogan. It also states plainly what is not covered.
Authentication
- Email and password sign-in plus Google sign-in, handled by the managed auth service.
- Sessions are bearer tokens attached to server calls; protected routes reject unauthenticated requests before any data is read.
- No anonymous sign-ups.
Data isolation
- Conversations, messages, user settings, uploads, prompt presets and knowledge-base rows all enforce row-level security keyed to the owning account.
- Table privileges are granted explicitly per role; anonymous clients have no read access to workspace data.
- Role checks use a security-definer helper in a private schema, so roles cannot be escalated from the client.
File storage
- Chat uploads and knowledge documents go to private buckets under a path derived from your account and conversation.
- Reads happen through short-lived signed URLs, not public object URLs.
- Uploads are limited to 5 files per message at 15 MB each.
Agent (MCP) access
The MCP server is OAuth protected. An agent client only gets access after you grant consent, and every tool call runs with your own permissions — it cannot read another account's data.
Model providers
To produce a reply, the message and any extracted file text are sent to the model provider you selected. That request is governed by that provider's terms. Using your own API key keeps the request inside your own provider account.
Ongoing checks
- Automated tests assert that row-level security blocks cross-account reads of conversations, messages, files and stored keys.
- Public webhook endpoints require a shared secret header rather than being open.
Limitations
- No end-to-end encryption: the server must read your message to forward it to a model.
- No SOC 2 or ISO 27001 certification is claimed.
- Security depends partly on your own account hygiene, including password strength and client devices.
Frequently asked questions
Can another user read my messages?
No. Row-level security policies restrict reads and writes to the owning account, and automated tests verify this.
Are uploaded files publicly accessible?
No. They are stored in private buckets and read only through short-lived signed URLs.
Is ChatOTL certified against a security standard?
No certification is claimed. This page describes the implemented controls so you can evaluate them directly.
What can an MCP client do with my account?
After you grant OAuth consent, it can list, read, search, rename and create your conversations. It cannot reach other accounts.
Questions about the boundary?
The privacy page covers what is stored, for how long, and what leaves the workspace.
Read the privacy details