Security

Envelope per record, isolation in the database, erasure by key destruction.
And the limits, written where anyone can read them.

Category
GuaranteesSecurity
HummandSecurity

Hummand's security is the security of the record: what comes in is encrypted with its own key, isolated per client in the database, and disappears by key destruction. None of it depends on trusting whoever operates it.

A static code audit in June 2026 closed the gaps it found; the cloud console evidence (AI opt-out, key policy, permissions) was recorded in August. What is still missing is in the last band, not hidden.

Custody

Description

Centralized custody, declared. The sensitive data of every record is encrypted with its own key, and the key that opens those keys lives in a managed module. Whoever operates the service does not decrypt.

1.0Envelope per recordavailable

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.

2.0Decryption trailavailable

Every privileged decryption enters an append-only trail with a hash chain. An auditor holding the series detects removal.

3.0Receipt keyavailable

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.

See Receipt
4.0Certified component and evidenceavailable

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.

Isolation

Description

Each client sees only what is theirs, in the database and in the API. The isolation belongs to the database, not just the application.

1.0Row-level isolationavailable

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

2.0Keys, sessions and MFAavailable

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.

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

3.0Erasure scopeavailable

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.

4.0Roles inside the clienttarget architecture

Today no endpoint distinguishes the role of the caller: any authenticated user of the client invites, removes and erases. Roles by level are planned and replace the current field. Declared, not hidden.

Erasure and operations

Description

What dies, dies by key destruction. And what does not exist yet is written here, not in a promise.

1.0Crypto-shredavailable

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.

2.0Retention periodsavailable

Encrypted verdict and CPF: 90 days. Consent evidence and event trail: five years. Images and biometrics: never retained; it is a product invariant, not configuration.

See LGPD
3.0Transport, edge and releaseavailable

Automatic TLS, HSTS with subdomains, protection against type sniffing. Credentialed access only for the dashboard, the journey and the console. Every release applies the migration before the new app, with a backup first.

4.0Declared limitstarget architecture

In-memory request limiting, on one instance; no mTLS between services; secrets still in an environment file on the host; no distributed telemetry; backup restore not rehearsed yet; no production threat model nor external pentest.

Distributed limiting and mTLS are contract prerequisites; the rest is the discipline phase of the plan, not started yet.

See Status
5.0Responsible disclosure

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

Report
1.0

Verify a receipt

Paste the JSON and the public key. No account, nothing sent: it runs in your browser.

Open the verifier
2.0

Talk to us

A technical conversation, straight with the people who build it, no sales script.

Contact