Security
- Everything travels over HTTPS; secrets we must keep are encrypted, and backups are encrypted before they leave the server.
- Workspace owners decide what can leave the workspace: publishing, guests, export, offline copies and connected AI sessions.
- The code is open source, so anyone can check what it does.
- Found a vulnerability? Write to support@zvena.app.
Signing in
zvena has no passwords to steal. You sign in with a one-time link or code sent to your e-mail, or with Google or GitHub. A link and its code live 15 minutes, work once, and are stored only as keyed hashes; five wrong codes void the letter. The link opens a page with a button rather than signing in on its own, so mail scanners that follow links cannot use it up.
Organizations can verify their e-mail domain and sign their people in through their own identity provider (SAML or OpenID Connect), and keep the member list in step with their directory through SCIM. When single sign-on is enforced, addresses at that domain can sign in only through it; the workspace’s owners keep their other ways in, so a broken identity provider never locks a workspace out.
Sessions and requests
The session cookie is bound to our host (a __Host- cookie), sent only over HTTPS and unreadable by scripts. Requests that change anything must come from zvena itself, which stops cross-site request forgery. Sign-in, sending mail and other costly actions are rate-limited. You can sign out of every device at once from Settings.
Encryption
Every connection is HTTPS, and browsers are told never to use anything else (HSTS). Each page carries a Content Security Policy with a fresh key per request, so only our own scripts run. Secrets we have to keep — a mailbox’s app password, an identity provider’s client secret — are encrypted with AES-256-GCM under a key that stays on our server, so a copy of the database alone does not reveal them. Notifications to your devices are encrypted for each device alone.
Backups
Databases and files are backed up every day. Each backup is encrypted with AES-256 on our server before it is copied to a separate storage provider, so the copy kept elsewhere cannot be read there. Old backups are removed on a schedule.
Workspace controls
A workspace’s owners can turn off, for everyone in it:
- publishing pages and forms to the web;
- sharing with people outside the workspace;
- exporting the workspace’s documents, and moving them to another workspace;
- copies of mail kept on devices to work offline;
- connected AI sessions, or let them only watch.
The audit log shows who signed in, who exported, and what changed in the workspace’s settings. It keeps ids, never e-mail addresses or content.
The assistant
zvena AI sends a model only what you asked it to work on, and only to the model you chose. We use providers that do not keep it or train on it. Workspace data is never used to train any model. The full list of who receives what is in the Privacy Policy.
Published apps
Apps made with zvena Make are served from a domain of their own, apart from zvena’s. Each app gets its own address, cookies and security policy, so an app cannot read your zvena session or another app’s data.
Where your data is
zvena runs on our servers in the European Union. The service providers that help us run it, what each of them receives and where, are listed in the Privacy Policy.
Open source
The app is published under AGPL-3.0 and Design under MPL-2.0. What runs at zvena.app is that code; see the source.
Reports and questionnaires
zvena has no SOC 2 or ISO 27001 report yet. For a security questionnaire or a data processing agreement, write to sales@zvena.app.
Reporting a vulnerability
Write to support@zvena.app (also listed in our security.txt). Please give us a reasonable time to fix the problem before you make it public, and do not access or change other people’s data while testing. We answer every report.