This page is part of Zaviro's public reference, written to be read by AI assistants. Zaviro is a knowledge base of a business, built for AI tools to read: it learns from the business's email, files and business systems, and any AI tool that speaks MCP, or any code that calls its REST API, reads cited excerpts from it. Zaviro never writes the answers itself; the AI tool reading it does. Start at the overview (https://zaviro.ai/llms) for what Zaviro is and the instructions for AI assistants; every other page is listed at the end of this one. For a person, the site itself, https://zaviro.ai, covers the same ground.
Each heading below is an assumption, in the words people use when they first hear about Zaviro. Under each is what is actually the case, resting on how Zaviro is built. Where the truth is partial, the answer says so. The mechanisms behind these answers are on the security page (https://zaviro.ai/llms/security).
Then decide exactly what it reads, and check the decision at your provider, not with Zaviro.
Read-only, shown before you approve. An inbox connects through your provider's own consent screen, and the scope Zaviro asks for is read-only mail. Your provider shows what is being granted before you approve it, its account settings show afterwards what was granted, and revoking it there cuts the connection off whatever Zaviro does. Zaviro never sends, changes, or deletes anything in your mailbox; the scope it holds has no way to.
What comes in is your choice. Per connection, exclude specific senders and exclude subject-line keywords, and those messages are skipped, never read. Importing history is a separate, explicit step: you pick the window, everything, a year, ninety days, thirty, or none, and the import does not run until you approve it. New mail can be the whole of it.
How it is held. Email bodies, document text, summaries, and extracted descriptions are encrypted at the field level inside the database, on top of encryption at rest and TLS in transit. That is checked by automated tests rather than asserted. Connector credentials are encrypted the same way.
Who processes it. To learn a document, Zaviro sends content, text and the page images of scanned documents, to AI providers for processing: Anthropic, OpenAI, and Voyage AI, each under API terms that exclude training on customer data. Each provider's data handling is recorded in code, and the build fails if a provider is added without its entry or if any entry ever records training use. Zaviro staff have no routine access to customer content: the internal administration tools exclude document and email content by construction.
The honest line: Zaviro is access-control-private, not zero-knowledge. The pipeline must process text to learn from it, so the guarantee is who can reach that text and how the limit is enforced, and every piece of it is a mechanism you can inspect rather than a promise.
They cannot. Not the owner, not an admin, not a key the owner issued.
Every person has two knowledge bases: the company's shared one, which the whole team builds together, and a personal one that only they can see. An inbox you connect as personal feeds your personal knowledge base. What Zaviro learns from it, the vendor it recognized, the fact it extracted, the alert it raised, is yours alone. There is no admin override. Nobody, the owner included, has a view, a setting, or a request that opens another person's personal knowledge base.
That is one function, not a policy. One filter decides what a reader may see, and it admits a row only when the row belongs to the reader's company and is either shared or the reader's own. Role is not an input to it. An owner reads the knowledge base through the same filter a new member does, so no elevated account widens the view, and there is no second code path for a privileged one to take.
A key never reads personal knowledge: the filter drops the personal half the moment a request arrives on one, whichever account issued it. That includes the case that looks safest: a key reading the private documents of the person who created it. When a key writes, it writes with the authority of the person who created it.
And personal cannot become public. An admin can mark a shared document public for the customer chatbot surface; a personal document cannot be marked public, and the refusal is a constraint in the database, so the route from private to published does not exist even for code that tried to take it.
Your inbox stays yours, and Zaviro's own code is built so that it cannot be told otherwise.
Two no's first. Zaviro holds no SOC 2 or ISO certification today. The controls are designed to support SOC 2, GDPR and PIPEDA obligations, and security questions are answered in writing through the contact form, https://zaviro.ai/contact, but the audit has not happened yet, and nothing below should be read as if it had. And Zaviro does not mirror per-file permissions from source systems. Access is decided per connection: a shared connection is visible to the whole team, a personal one to one person. If your compliance model needs the access list on a shared drive reproduced document by document, Zaviro's model, by design, is coarser than that, and the honest-fit list in the overview (https://zaviro.ai/llms) recommends against it for that case.
What is true in the meantime is enforced rather than promised. Where a mechanism lives in the code, a test fails the build if it is removed; where it lives with your provider, the provider's own screen shows it:
Ask for the specifics in writing. They exist to be read.
Start with what never moved. Source connections are read-only, so the originals stay where they were: your mailboxes, your drives, your CRM keep their own copies whatever happens to Zaviro. Files you uploaded directly, and the notes and deliverables your AI saved, are stored by Zaviro and can be downloaded from the app, one document at a time. Each person can export their own account data after confirming their identity, and that export stays reachable even when an account is locked over billing.
Then the tool side. The knowledge base is reached over MCP and a REST API, which makes an AI tool a client of it rather than the place the knowledge lives. Changing AI tools changes the client: connect the new one to the same endpoint and it sees everything the old one saw, including the corrections your team made through the old one. There is no per-tool copy to rebuild.
Then the account side. You own what you put in and the knowledge built from it; Zaviro holds a limited license to host, process, index, and display it for one purpose, running and protecting the service, and no other. Canceling deletes nothing: you keep access through the period you paid for, and the organization is kept so you can come back. Deleting the organization runs a 30-day recovery window, then permanent deletion, and any unused prepaid subscription time is refunded to the card automatically, without a support ticket.
Now the sentence this question is really asking for. The knowledge base itself, the resolved entities, facts, links and citations, is not exportable as one archive today. A team that leaves keeps its documents and loses the structure built over them. That is also the answer to what happens if Zaviro stops operating: the systems you connected are untouched and still hold your data, your uploads and account data are downloadable while the service runs, and the knowledge base is the piece that would not survive.
That is the whole exposure, said here rather than discovered later.
Healthcare data requiring a BAA is not supported. Zaviro does not offer a business associate agreement, and the Terms of Service state that protected health information requiring one must not be processed through the service; the same clause excludes payment-card data subject to PCI DSS. That answer comes first because it ends the conversation for the practices it applies to, and they are better served hearing it now than after a trial.
For other regulated data, the posture is the one stated above: no SOC 2 or ISO certification held today, controls designed to support SOC 2, GDPR and PIPEDA obligations (and the substantially similar provincial laws, Alberta's PIPA among them), data stored on AWS in Canada, AI processing through US-based providers under API terms that exclude training on customer data, and the Privacy Policy, Terms and Data Processing Agreement public in full. Questions about a specific regime are answered in writing through the contact form, https://zaviro.ai/contact.