Last updated: August 18, 2026
Teaflask puts an agent inside your product and lets it take real actions through your own APIs. The interesting security questions for a system like that are not the usual ones — they are about what the agent is permitted to do, whose credentials it uses, and what leaves your tenant. This page answers those in plain terms. Our audit reports, current control status, named subprocessors and data processing addendum live in the Trust Center.
1. What the agent is allowed to do
An agent that can only answer questions has a small blast radius. Teaflask agents take actions, so the boundary is drawn explicitly and by you, not inferred by a model at runtime.
- Every action your agent can take is registered and carries one of three dispositions: allowed outright, allowed only after a human approves that specific call, or denied. Nothing is available to the agent that has not been admitted.
- New actions arrive denied or approval-gated rather than enabled. Widening what an agent may do is always a deliberate act, never a side effect of connecting something.
- Actions run against your systems through credentials you supply and scope. Teaflask cannot reach further than the credential you gave it, and when a credential does not permit something the agent refuses rather than improvising a way around it.
- Every action attempt is recorded — what was called, on whose behalf, with what outcome, including the refusals.
2. Why the agent says what it says
Answers are grounded in your own material rather than in a model's recollection, and the claims in that material are re-checked against the sources they came from so an agent stops repeating something that has quietly stopped being true. An answer you cannot trace is a security problem as much as a quality one.
3. What we send to model providers, and what we keep
- Conversation content is processed by foundation-model providers to generate responses, under agreements that prohibit them from training their models on it.
- Conversation content is kept out of our operational telemetry by construction, not by convention: the pipeline that carries our logs, metrics and traces forwards only an explicit allowlist of fields we maintain in code, and discards everything else — so prompts and responses cannot reach a monitoring provider even if an upstream library starts emitting them.
- Sensitive values encountered while reading a page are redacted before they reach a model.
- Credentials you give us, including model-provider keys, are encrypted before storage and are never readable through the API once saved.
4. Keeping tenants apart
Every record carries the organization it belongs to, and the boundary is enforced by the data layer itself rather than by application code remembering to ask. The service connects with a least-privilege identity that cannot override that boundary, so the failure mode of a mistake is that data becomes unreachable, not that it becomes visible to the wrong tenant. Production and pre-production are separate systems with separate credentials, and production is never populated with test data.
5. Encryption
Data in transit is protected with TLS, on every surface — the dashboard, the embedded assistant, and the APIs behind them. Data at rest, including backups, is encrypted with AES-256 using managed keys.
6. Identity and access
- There are no passwords. Signing in is passwordless, which removes password reuse, credential stuffing and stored password databases from the problem entirely.
- Organizations can bring their own SAML identity provider and require it for everyone on an email domain they have proven by DNS, so joining and leaving are decided where the rest of your access is decided.
- Access within an organization is role-scoped, and those roles are resolved in one place rather than re-checked surface by surface.
- Internal access to production follows least privilege, and the routine operational credential is read-only.
7. How changes reach production
Nobody pushes changes straight into Teaflask, including the people who administer the code — every change goes through review and an automated gate that administrators cannot bypass. Merging does not deploy to production; production moves only when a release is published, through the same pipeline every time. A direct path exists for recovering from an incident, and it is treated as the exception it is.
8. Availability and recovery
The service runs redundantly, so routine infrastructure replacement is absorbed rather than noticed, and availability is measured by a probe outside our own infrastructure — an outage is not something we depend on ourselves to spot. Databases are backed up automatically on a daily cycle.
9. Compliance and reports
Our certifications, current control status, audit reports and the named list of subprocessors are published in the Trust Center, which reflects our live compliance monitoring rather than a snapshot taken when this page was last edited. Reports are available on request there. A data processing addendum is available to customers, and how we handle personal data — and in which role — is set out in our Privacy Policy and Customer Agreement.
10. Reporting a vulnerability
If you have found a vulnerability, please tell us at security@teaflask.com. We will acknowledge your report, keep you posted while we work on it, and we will not pursue legal action over research conducted in good faith against your own organization’s data. Please give us a reasonable chance to fix an issue before publishing it.