Files
hanzo.ai/content/legal/cybersecurity.md
zooqueenandHanzo Dev 1cc301fb2c A cybersecurity policy, at the address reviewers look for it
Security reviewers ask for a document with this name and these headings —
who can reach the data, how it is encrypted, what happens in an incident.
/security and /trust already answer all of it, but they answer it as prose
about mechanisms, which is the right shape for an engineer and the wrong
shape for a questionnaire.

This is the short version, and it is one markdown file: content/legal
discovers it, /legal/cybersecurity renders it through the same component
every other document uses, and it inherits the draft-pending-counsel line
from its own front matter. No new route, no new component, nothing to keep
in sync.

Every claim in it was read off /security or /trust before it was written
here: TLS 1.3 with hybrid ML-KEM-768, AES-256-GCM at rest under a
per-tenant derived key, age for backups, per-file isolation between
organizations, 72 hours to notify, no model training on customer content.
The isolation section keeps the distinction those pages are careful about —
two key derivations exist and one is tied to the organization, so it is
per-file isolation and says so.

On certifications it says what we do: controls built to be compatible with
SOC 2, audited continually, report on request with no questionnaire first.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-06 21:12:32 -07:00

3.8 KiB

title, slug, kind, status, version, updated, summary, order
title slug kind status version updated summary order
Cybersecurity Policy cybersecurity policy draft 2026-09-06 2026-09-06 How we protect your data — who can reach it, how it is encrypted, and what happens if something goes wrong. 7

How we protect your data. /security describes the same controls in the source code; this is the short version.

What we protect

Your content, your agents' memory, your passwords, and the keys and tokens that connect Hanzo to your other services. All of it is encrypted, reachable only by people who need it, and kept separate from every other organization's.

Operational data — usage, logs, billing — is handled with the same care and a lighter hand.

We do not train models on your content. Not your prompts, not your agent memory, not your files. The Privacy Policy says what happens to your data in every case.

Who can reach it

People here get the least access their job needs, and lose it the day they change roles or leave. Anyone with production access signs in as themselves, with a second factor. There are no shared admin accounts.

Inside the product, you set the rules: who can see what, and which actions an agent must ask you about first — spending money, publishing, or writing to a system you have connected.

Keys and tokens for your other services are encrypted, scoped to the one workflow that uses them, and revocable by you at any moment. They never appear in a log or on a screen.

How organizations stay separate

Each organization's data is its own file. A query in one cannot reach the other, because the other file is not open. Where a master key is set, each file is opened under its own derived key, so one leaked key exposes one file.

To be precise, since reviewers ask: this is per-file isolation. Two key derivations exist and one of them is tied to the organization.

Encryption

Moving — TLS 1.3, plus hybrid ML-KEM-768 key exchange at the edge. Traffic captured today stays unreadable when quantum computers arrive.

Stored — AES-256-GCM, under a key derived for your tenant alone. Backups use age, which also has a post-quantum option.

Keys live apart from the data they open.

Keeping it current

We watch our dependencies and infrastructure for known vulnerabilities and fix by severity. Every change gets code review and automated checks before it ships. Our infrastructure providers patch the systems underneath.

If something goes wrong

We have a process to spot, contain, investigate, and fix a security incident, with named people and a clear escalation path.

If a confirmed incident affects your data, we tell you within 72 hours of confirming it. If a credential looks compromised, revoking it cuts off access immediately.

Your data is backed up through our managed database providers.

Certifications

Our controls are built to be compatible with SOC 2, and we audit them continually. Ask for the report and it comes back — no questionnaire first.

If your review runs on a named framework, tell us which one and what your reviewer needs to see. We scope it with you as part of the engagement.

Where it runs

Our cloud runs on established providers, in facilities with their own physical security under recognized attestations. We secure the devices and accounts our people use to connect.

You can also run Hanzo on your own Kubernetes or your own machine. Then the infrastructure is yours and the software is ours.

Who we share it with

Any provider that will touch your data is reviewed before we onboard them, and gets only what its job requires. The current list is published as our Subprocessors register.

Found a weakness?

Write to [email protected]. We would rather hear it from you than read it later, and we do not go after researchers who report in good faith.