Report a vulnerability privately
Don't open a public issue for an unpatched vulnerability. Use one of these two channels:
Please include:
- the affected revision, release, URL, component or provisioner version
- a minimal reproduction, and the boundary you expected versus the one you observed
- the likely impact, and whether anyone has tried to exploit it
- relevant logs, with credentials, customer data, host addresses and reusable access material removed
- a safe way to contact you for follow-up
Don't send live private keys or reusable credentials. If one has been exposed, revoke it first when that's safe, then send only its identifier or cryptographic fingerprint.
While you're researching, please don't access other users' data, change paid infrastructure or degrade a shared service.
Hivra acknowledges a report through the same channel it came in on, then coordinates a scoped fix and verification plan. If you ask for credit, Hivra publishes it once affected users can be protected. No response-time promise is made until Hivra documents a staffed public security-response rotation.
Supported versions
Until the first tagged public release, Hivra applies security fixes to the latest commit on the main branch. It doesn't maintain older commits, old provisioner bundles or independently modified deployments.
What Hivra claims and what it doesn't
Hivra runs capable, long-lived agents with code execution, files, browsers, networks and credentials. The security model is a target contract. It says what must be true, and it does not claim that every control is already in place.
Hivra cannot guarantee that capable agents are harmless or that compromise is impossible. The security claims on this site are meant to stay narrow, each one tied to behavior that has been checked.