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 AI 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 agent 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 agent needs live in HiveVault rather than in a prompt or an environment file. They are encrypted at rest, scoped to one project and to the departments or the named agents you choose, and every read is recorded, granted or denied.
- Scoped per project and per department, and time-limited. A key scoped to Engineering is refused to every other department, which is checked on each read rather than at the time it was stored.
- Narrow it further to named agents when one key should not reach the whole department. Both scopes apply together, so naming an agent never lets them past a department scope they do not satisfy.
- A full access log: which agent read which credential, and when.
- Instant revocation, and auto-expiry by default.
Your AI 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 correspondent who cannot be impersonated is harder to use against your team.
- Email from an agent is signed as an AI Employee and names the person who manages it.
- In a meeting, an agent 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. Your agents 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 agent 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.