TolavoSecurity
How Tolavo handles security.
At a glance
Access controls
In place
Your records are scoped to your workspace; only Tolavo’s operator area reads across workspaces. Two-factor sign-in is available but not forced.
Data handling
In place
Credentials are encrypted or refused. Run contents are not kept by default. You can export your workspace.
Hosting
Declared
Your AI runs where you host it. Tolavo’s own providers are listed under sub-processors.
Responsibility
Shared
You run your AI and support your clients. Your clients pay you directly.
Support
Available
Signed-in customers raise requests with a reference. Anyone locked out can ask a person.
Independent assurance
None yet
No SOC 2 report, ISO 27001 certificate, external penetration test or independent review yet.
Who can do what is settled on the server.
Checked on the server
Every request is checked against its role, and every record of your work belongs to one workspace.
Two-factor sign-in
Available to every account and not forced; Tolavo’s own console always asks for it.
Passwords and links
Stored only in a form that cannot be turned back.
How this works: sign-in and access
- A role that does not hold a permission is refused by the API, and a refusal at a route’s permission gate is written to the audit trail, as is a refused attempt to change a colleague’s ticket or read a colleague’s support request. A request for a record in another workspace is answered “not found” and writes nothing.
- Every query for a workspace’s data is scoped by that workspace on the server. Only Tolavo’s own operator area reads across workspaces, and it admits only an operator with an authenticator enrolled. A request aimed at another workspace’s system or team member is refused outright rather than filtered out of the interface, and that refusal is tested by firing real cross-workspace requests at a running server. Workspace separation is not offered as a guarantee: nothing measures isolation at request time, so what is claimed is the behaviour and the test, not a proof.
- An authenticator app (TOTP) is available to every account, and once an account sets it up Tolavo asks for a code at every password sign-in and rejects one that has already been used. Setting it up is not forced and a workspace cannot make it mandatory for its people, so this is a control an account holds rather than one Tolavo imposes. A sign-in through your own identity provider is not challenged here — your provider decides what it asks for.
- The operator console Tolavo staff use has no password-only path: two-factor is required there. On the HQ console, deleting, resetting or suspending a workspace and signing everyone out also need a typed confirmation phrase and, outside Tolavo’s demo environment, a fresh code.
- Passwords are kept only as bcrypt hashes and are never logged. Invite links, password-reset links and inbound webhook keys are random values shown once and kept only as SHA-256 hashes, so a stolen copy of the database contains no usable link or key — apart from an email carrying a link or a temporary password while it waits to be sent: the send queue clears it once the email has gone out or has finally failed.
Secrets are sealed one value at a time.
Encrypted credentials
Sealed one value at a time, or not stored at all.
Run contents
By default a run keeps the shape of a call, not its contents.
Tampering shows
Linked audit entries make an edit or a removal visible.
How this works: how data is protected
- Stored secrets are sealed value by value with AES-256-GCM under a rotatable key ring, and where no encryption key is configured Tolavo refuses to store a credential rather than keeping it in the clear. Authenticator seeds are the one exception: on a deployment with no key they are kept unsealed, so accounts that already use them are not locked out.
- What is sealed: a connected system’s credential, integration credentials, SSO client secrets, onboarding secrets, callback secrets for each client installation and outbound webhook signing keys.
- A retired key stays on the ring so existing data keeps decrypting, and one operation re-encrypts every sealed value under the new key in a single transaction. If a key is rotated out before that runs, Tolavo reports it when it starts and the affected secrets fail closed rather than quietly becoming usable.
- Stored data as a whole is not encrypted; credentials are. The key is held as an environment variable on the same host as the data, with no KMS and no HSM.
- Every entry in the audit trail is chained to the one before it with a SHA-256 hash covering who did it, in which workspace, and what changed. Tolavo walks the whole chain against the stored records at start-up, checks the newest links every sixty seconds, and walks the whole chain again sixty seconds after each full pass ends, and reports the result. You can export your workspace’s entries with their hashes, so your own auditor can recompute each one without taking our word for it. One other log sits beside it, append-only in the database but not chained: the one kept with payments. Actions in Tolavo’s HQ console go to a second, separate chain.
- Tamper-evident is not tamper-proof: the chain does not stop somebody with direct access to the stored data from altering a record; it makes the alteration impossible to hide.
- A run record holds the byte count, a truncated hash and the names of the top-level fields of a call. No screen in Tolavo switches payload storage on. Where it is on for a connection, up to 4,000 characters of the request and of the response are kept. A run record cannot be deleted, and the only change allowed to that stored request and response is clearing them; nothing in Tolavo lets you do that yourself.
- HSTS is set for two years, including subdomains. The content-security policy allows no third-party scripts, fonts or connections, the site refuses to be framed, and the referrer policy is “no referrer”. TLS itself is terminated by the hosting platform in front of the application.
Tolavo checks the address before it calls it.
Public HTTPS only
Private, internal and loopback addresses are refused; the checked address is the one called.
Inbound calls are authenticated
Each inbound connection gets its own address and a key shown once.
Sensitive actions wait
They do nothing until approved, unless a workspace sets onboarding to Autopilot.
How this works: calls and approvals
- An endpoint you give Tolavo must use https, and Tolavo resolves the name before calling it: an address that is — or that resolves to — a private, loopback or internal address is refused. The call is then made on the exact address that was checked, with redirects refused, so the check and the call can never mean two different hosts. A Slack notification is held to the same check, and goes only to Slack’s own webhook host or one the operator adds.
- Tolavo can allow exact hosts, or host and port, in its configuration. Wildcards and address ranges are refused, and for a system connection every call that only works because of that permission is written to the event log. This is not an approved-destination list: any public https endpoint a seller configures can be called.
- An inbound key is kept only as a hash and checked, in constant time, on every call.
- Actions the connector catalogue marks as sensitive — creating a user account, disabling one, creating an employee record — are recorded as proposed and perform nothing until they are approved: in the approvals list, by a manager or above, or by someone allowed to manage integrations who confirms the action itself. A workspace that sets onboarding to Autopilot lets the onboarding agent create accounts without asking.
Your AI stays where you built it.
Where your AI runs
Where you built it; Tolavo calls it and does not host or run your system.
Who supports your client
You do. Tolavo takes no payment from your clients.
What leaving costs
Nothing switches off: your AI keeps running where it always did. A manager can export the whole workspace while it exists; after a subscription ends there are 30 days to do so. A workspace Tolavo has suspended or cancelled is closed to every request.
How this works: where Tolavo runs
- Traffic to Tolavo is HTTPS.
- Tolavo’s own hosting and email providers are named on the sub-processors page.
Nobody outside Tolavo has checked any of this.
The controls above are real, and we will show any of them on request.
- SOC 2 and ISO 27001
- Not completed
- Independent review and penetration test
- Not commissioned
Ask us what your review needs to know.
Vulnerability reports go to the security contact listed on /contact, if one is published, and otherwise through the security form.