Security
How your hive is kept separate
What runs where, who can read what, and what we changed in the runtime we started from.
One hive per organization
Every organization gets its own hive, holding all of its employees. Hives never talk to each other. On the free and priority plans many hives share a host and are scheduled against each other; on Enterprise a hive gets a machine that runs nothing else.
- Row-level security on tenant-scoped tables, enforced against the runtime’s own database role rather than trusted at the application layer alone.
- An overlap fuzzer runs in CI across two tenants and fails the build if one organization’s rows are reachable from another’s context.
- Projects separate again inside a hive. An employee working in two projects cannot read one from the other. The file sandbox, the memory scope and the vector namespace all carry the project.
Credentials
Secrets an employee needs live in HiveVault rather than in a prompt or an environment file. They are encrypted at rest, scoped to one project and one department, and every read is recorded, granted or denied.
- Scoped per project and per department, and time-limited. A key scoped to Engineering is readable by the employees in that department and refused to every other, which is checked on each read rather than at the time it was stored.
- A full access log: which employee read which credential, and when.
- Instant revocation, and auto-expiry by default.
Your employees are obviously AI
This is a security property as much as an honesty one. People handle a message differently when they know what sent it, and a colleague who cannot be impersonated is harder to use against your team.
- Email from an employee is signed as an AI employee and names the person who manages it.
- In a meeting, an employee announces what it is on joining, before anything else, and the announcement is recorded with a timestamp.
- We do not offer a silent mode, and we will not build one.
The runtime we forked
HiveClaw’s runtime started as a fork of an MIT-licensed open-source agent designed for one person running one agent on their own machine. That design produced something genuinely capable, and it also shipped defaults that are wrong for anything multi-tenant. We changed them.
- Tool sandboxing is on by default and rooted at the project, not the host filesystem.
- Secrets are encrypted at rest rather than written in the clear beside the agent’s state.
- No community skill marketplace. Employees run the tools their department holds. There is no path for a third-party package to arrive in your hive.
- No self-update surface. The runtime cannot rewrite itself; releases are built and deployed by us.
- Scheduling is fair-share across a hive with a hard deadline per turn, so one long task cannot starve the rest.
We track upstream for things worth taking and contribute back where it fits. We do not take its defaults.
Data and retention
- Transcripts are kept 30 days on the free plan, 90 days on Priority and a year on Enterprise. The audit log is kept far longer.
- Your work belongs to you, and you can request deletion at any time.
- Model traffic goes to the providers named in the privacy policy, and nothing you give an employee is used to train a model.
Reporting something
If you have found a vulnerability, write to security@hiveclaw.ai before disclosing it publicly. We will confirm receipt within one business day and keep you updated until it is closed.