Understand how Zurvo isolates and protects your data.
How Zurvo keeps your data separate from every other business — per-tenant isolation, rate limits, CSRF and SSRF protection, encrypted secrets, and audit logs.
Your business’s data belongs to you, and Zurvo is built to keep it separate from every other business and protected in transit and at rest. This page explains the concrete mechanisms behind that — in plain language, without the jargon.
Your organization is the boundary
In Zurvo, your organization is your workspace, and it’s a hard wall around your data. Every record we store — conversations, messages, leads, and your trained knowledge — is tagged with your organization.
That tagging isn’t just a label in the app. It’s enforced at the database level with Row-Level Security (RLS) policies: the database itself refuses to return or change a row unless the person asking belongs to the organization that owns it. So even if a request tried to reach across to another business’s data, the database wouldn’t allow it. These policies also block “row-teleporting” — a record can’t be quietly moved from one organization to another.
Access inside your organization is governed by roles and permissions (owner, admin, agent, viewer, and any custom roles you create), so each teammate only sees and does what their role allows. See Team & roles for how that works.
Rate limiting keeps the service stable
To keep your chatbot responsive and to blunt abuse, Zurvo applies rate limits — caps on how many requests a single visitor IP or a single chatbot can make in a short window. These limits are enforced atomically in the database, so they hold up even under bursts of traffic. A visitor hitting the limit is asked to slow down; normal conversations are never affected.
Requests are checked before they’re trusted
Zurvo defends the parts of the app that change your data against common web attacks:
- Cross-site request forgery (CSRF). State-changing requests to the dashboard are validated against their origin, and rejected if that check doesn’t pass. This stops a malicious site from making changes to your account on your behalf.
- Server-side request forgery (SSRF). When you point Zurvo at a URL to crawl or scrape, it validates the destination first and refuses internal or private addresses — things like
localhost, private network ranges, and cloud metadata endpoints. Redirects are re-checked at every hop. That keeps the crawler from being tricked into reaching systems it shouldn’t.
Your secrets are encrypted
If you connect a handoff notification webhook — for example a Slack URL for human-handoff alerts — Zurvo stores it encrypted, not in plain text. The dashboard shows only a masked preview so you can recognize it without the full secret ever being exposed.
Everything sensitive is logged
Zurvo keeps audit logs of security-relevant actions across the platform. Each entry records who acted (or that it was a visitor or the system), what they did, the result, and request context like the IP address and browser. This gives an after-the-fact record if you ever need to understand what happened on your account.
A note on certifications
This page describes real, specific mechanisms — how isolation, rate limiting, request checks, secret encryption, and logging actually work in Zurvo. It intentionally does not claim any formal security or compliance certification. If you’re evaluating Zurvo for a requirement of your own, contact us and we’ll share what we can to support your review.
To understand exactly what data Zurvo keeps and for how long, read What data Zurvo stores.