Security

Every sensitive record has its own data key, wrapped by the master key in the key module. Decrypting one record opens no other.

Privileged decryption only happens in a separate service, with its own cloud profile; the application that serves the API has no such right.

Every privileged decryption enters an append-only trail with a hash chain. An auditor holding the series detects a gap in the middle, reordering and forking.

ECDSA P-256 in the key module; the private key never leaves. The key policy grants the right to sign only to the service that issues receipts, and the right to read the public key to the application. The public key is published as a JWKS.

Live presence comes from an AWS-certified component, declared in the receipt with its version. The opt-out from using data to train AI, the key policy and the permissions were checked in the cloud console and recorded with a date.

Real row-level security in Postgres, with an application role that cannot bypass it. A query without a client returns nothing.

API keys per client and per scope. Dashboard sessions with app-based MFA and recovery codes, seed encrypted at rest, hardened login with attempt limits. SSO with Google, optional per client, sign-in with a passkey and an IP list for the dashboard and the API, set by the administrator.

Hummand's operations console has short sessions and MFA delegated to the edge access.

Erasing is the only irreversible operation: it has its own scope, which no integration receives by default. In practice, the dashboard session erases, at the data subject's request.

Three levels, from narrowest to widest: analyst, supervisor and administrator. Authorization is by floor: every session route declares the minimum level that opens it, and a test suite reads the router to prove none was left without a declared floor.

The minimum of two administrators is a lock on the way out and a warning on the way in. Live since 2026-09-14. Since 2026-09-28, the dashboard write routes also have a floor per level, and an administrator cannot change or remove another: there is no hierarchy between peers, and a compromised administrator is removed by Hummand, with a record in the trail.

Since 2026-10-19, the Auditor profile, which reads what the supervisor reads and writes nothing, and the periodic access review.

The internal console has no levels, by decision: it exists to support and debug, and its control is the record. Every view of client data through the console leaves a record attributable to a person, not just changes.

Opening the encrypted content of an act requires a declared reason, and the client reads on their own dashboard who opened it, when and why, including when the one who opened it was Hummand.

Erasing a record is destroying its data key: the ciphertext becomes unrecoverable. On request, by act or by the client's reference, or by retention period, with a sweep every six hours.

Encrypted verdict and CPF: 90 days. Consent evidence and event trail: five years. Images and biometrics: never retained after the act; the reference photo stays encrypted only while the act is open, up to 30 days. It is a product invariant, not configuration.

The client can keep the encrypted part of a type for longer, up to 20 years, only with a declared legal basis, and preserve an act under dispute.

Automatic TLS, strict transport with subdomains included and a browser preload request, protection against type sniffing and no-store API responses by default. Credentialed access only for the dashboard, the journey, the console and the review queue. Every release applies the migration before the new app, with a backup first.

Server and database at Hetzner, in Helsinki, Finland. Backups on Cloudflare R2, with EU jurisdiction, encrypted with a key only Hummand holds, and the restore is rehearsed rather than assumed. Live presence, face comparison, the key module and operations secrets on AWS, region us-east-1, in the United States. Operations telemetry on Grafana Cloud, São Paulo region. Edge and sites on the Cloudflare global network. The transfer mechanism for each provider is described in the processing record, which the client receives on contracting.

By agreement in the contract, the operation can be entirely national: server, database, backups, keys and live presence itself, because the component also runs in a Brazilian region. The installation in place today is the one described above; national residency is sized per contract. A national live-presence source remains in the plan, labeled target architecture until it enters the catalog.

Client mTLS, in layers: the origin only accepts the edge since 2026-09-24, and the binding between certificate and contract is in the code since 0.17.0, switched off until the edge authenticates the origin with a certificate of its own. Path protection stays at the edge in front of the API and in request limiting in three layers, per key, per client and per IP, counted in the shared database. mTLS between internal services comes later.

A national live-presence source remains target architecture. What has landed changes label here, with a date, and does not stay pending: access levels inside the client landed on 2026-09-14 and the line above became available.

Found something? Write to [email protected] with the subject "Responsible disclosure". The address is also in /.well-known/security.txt.

Personal data only leaves for an authority under a written order from whoever has legal competence to ask for it, in the narrowest scope the order supports, with a legal opinion before and a record after, and the client is informed unless the law forbids it. Biometric data does not exist at rest, and that is the answer to any request for it. Data-subject content, only under a court order that identifies the record; decryption goes through the single point and is visible to the client on their own dashboard. For requests without a court order, the court order is the rule. Channel: [email protected].

Count published here, per year, starting from zero. 2026, as of 2026-10-08: no order received.

By legal obligation (Brazilian Internet Civil Framework, art. 15), which sets a minimum of six months, Hummand keeps for 190 days from the access a record of each access to the pages and to the API: date and time, IP address, the connection protocol and, on the pages, the first part of the address. Nothing else: not the browser, not the content, not the full address. It is a separate, restricted record, outside the database, the backups, the receipt and the telemetry, which remain without IP; the one for the pages lives in storage in the European Union, the one for the API on the origin server. Deleted automatically at the end of the period.

The logical source port goes into the record when the network reports it: on the pages since 2026-09-26 and on the API since 0.20.0; when it does not, the field stays empty, and that is declared. These records only leave for an authority under an order, by the rule in 7.0. Live since 2026-09-25.