How we secure the software that sees everything

The boundary, drawn explicitly

There are three deployment shapes and the security story differs between them, so this page states which one it is describing.

Most of what follows describes the self-hosted shape, because that is the one that removes us from your trust boundary entirely rather than relying on a contractual promise.

What we collect, and what we never read

The platform reads configuration, audit trails, pipeline metadata, certificate transparency and reachability relationships. It does not read the contents of what it protects. That distinction is specific rather than general, so here is the list of things that are never collected.

• Object contents. An S3 bucket is described — policy, exposure, encryption, logging — not downloaded.
• Database rows. Schema, configuration and access controls, never records.
• Prompt and completion text. The AI surfaces collect which identity reached which model endpoint, when and from where. Inference payloads are not collected.
• Application logs by default. They are a high-volume, high-sensitivity source; they are not ingested unless you connect them deliberately.
• Endpoint file contents. Runtime and endpoint detections are ingested from CrowdStrike and SentinelOne rather than collected by an agent we ship.
• Source code. Static analysis results are ingested; repositories are read for exposure, history and pipeline metadata rather than mirrored.

This is a design choice with a cost attached: because we do not read payloads, the platform cannot answer "what data left" in an incident. It can answer which identity, which endpoint, when and from where, which is the question that determines containment.

Credentials and access

The application container runs read-only. It does not need write access to its own filesystem, which removes a class of persistence and post-exploitation technique from the threat model rather than mitigating it.

Isolation between tenants

Tenants are a first-class concept with data separation at the query layer and a per-tenant audit log. If you run one boundary, you can ignore them entirely; if you run several, the separation is enforced in code rather than by convention, and each tenant's activity appears only in its own log.

Six RBAC roles ship built in — OWNER, ADMIN, SECURITY_ENGINEER, ANALYST, DEVELOPER, VIEWER. Custom roles are an Enterprise capability. There is no SCIM integration, so identity is managed inside the platform or through SSO/SAML where that edition includes it.

The audit log, described accurately

Every tenant has a hash-chained audit log. Each entry incorporates its predecessor, so an edit or deletion within the log is evident when the chain is walked, and retention is configurable to match your longest audit obligation.

Attestation: what exists and what does not

Evidence engines are worth being precise about too: they generate evidence about controls the platform can observe from live findings. That is a different claim from a certification, and blurring the two is the most common piece of dishonesty in this category.

The software supply chain behind the software

The repository is the reference implementation for every number on this site, and the release process is the one the product argues you should have.

• Third-party actions are referenced by commit SHA, not by mutable tag — the check the platform asks of you in its own pull-request gate.
• Release artefacts carry provenance, and a release without it is treated as an anomaly rather than as normal.
• Detection rules ship with their ATT&CK mapping, their evidence fields and a test; a registration guard fails the build if a rule is exported but not wired into a tier index.
• There are no LLM calls in the detection, correlation or scoring path, so a compromised model dependency cannot reach a decision the platform makes about your estate.
• The licence text, the compose file and the scanning configuration are all in the tree for inspection rather than summarised for you.

Reporting a vulnerability

Report security issues to security@hanu.security. Include enough to reproduce — an affected version, the configuration, and what you observed. We acknowledge within two business days and will credit you in the advisory unless you prefer otherwise.

Please do not test against production instances you do not own, and do not include real customer data in a report. If you are unsure whether something is in scope, ask first; a question costs less than a disclosure that has to be walked back.

Questions