Security & Trust

This page describes how Zetra is actually built to handle your data — not a marketing checklist. Every claim below reflects a real mechanism in the product, not an aspiration.

Tenant isolation

Every workspace ("tenant") and every agent within it is isolated at the database query level. Retrieval queries — the step where an agent searches your content to answer a question — are hard-scoped to the requesting tenant and agent in the query itself, not filtered afterward in application code. There is no code path that can return one tenant's content in response to another tenant's query. This isn't just a design claim: it's covered by an automated test that proves a near-identical vector match in a different tenant is never returned, even when it would otherwise be the closest match.

Authentication and sessions

• Passwords are hashed with bcrypt before storage — we never store or log plaintext passwords.
• Sessions are signed tokens stored in an httpOnly cookie, so they can't be read or exfiltrated by client-side JavaScript (including a successful XSS attempt).
• The session cookie is marked Secure in production (HTTPS-only) and SameSite=Lax to limit cross-site request risk.
• Signing in with Google uses Google's own OAuth flow — we never see or store your Google password.

API keys

Developer API keys are only ever shown once, at creation. We store a one-way hash, not the key itself — if our database were exposed, the keys in it could not be reconstructed. You can optionally restrict a key to a specific list of IP addresses, and every key can be revoked instantly.

Outbound webhooks

Outbound webhook deliveries are signed with HMAC using a secret unique to that webhook, sent as a request header. Your endpoint can verify the signature to confirm a payload genuinely came from Zetra and wasn't forged or tampered with in transit.

Embed and domain restrictions

The public chat widget can be restricted to an explicit allow-list of domains per agent. When configured, requests from any other origin are rejected rather than silently served with default settings.

Audit logging

Security-relevant actions in a workspace — logins, member invites and removals, role changes, API key creation and revocation, and integration credential updates — are written to a real, queryable audit log visible to workspace owners under Team, including the actor, the action, and the source IP address.

Rate limiting

The public chat widget enforces a configurable per-conversation rate limit to reduce abuse, and authentication endpoints are rate-limited in production.

Encryption

All traffic to and from Zetra in production is encrypted in transit over HTTPS. Encryption of data at rest depends on the database and hosting provider a given deployment uses — we don't currently apply additional application-level field encryption on top of that.

Data retention and deletion

You can permanently delete an individual agent, or delete all of an agent's conversations, at any time from that agent's Settings — both are immediate and irreversible. Full account and workspace deletion is available on request; see our Privacy Policy for how to request it.

Subprocessors

Generating a response involves sending relevant content to the AI provider your agent is configured to use. The full, current list of subprocessors — and the distinction between platform-level subprocessors and integrations you connect with your own credentials — is on our Subprocessors page.

Reporting a security issue

If you believe you've found a security vulnerability, please email security@zetra.chat with details and reproduction steps. We don't currently run a formal bug bounty program, but we will acknowledge your report and investigate every good-faith submission. Please don't access, modify, or exfiltrate other customers' data while investigating an issue — report it to us instead.