Start here: Compliance / DPO

Quadrant: How-to / navigation hub. Audience: Data-protection officers, privacy counsel, and compliance owners evaluating or operating humanymous Gate.

humanymous Gate is a reference implementation, not a production-hardened build; treat the behaviour described here as the documented design, and validate it against your own deployment.

What Gate gives you

Gate is built so that its bot-detection processing can be reasoned about under a data-protection regime. Raw identifiers — IP address, JA4, HTTP/2 fingerprint, user agent, SNI, device fingerprint — are never stored in the clear; each is written only as a per-subject-key-derived pseudonym (64-hex, scrypt KDF-stretched), so the audit record is pseudonymous, not anonymous (GDPR Recital 26): re-identification remains possible offline for anyone who holds the keystore and HMN_UNSEAL (Gate exposes no re-identification API; dual-control does not gate this). The audit subject is a session, not a natural person — many visits mean many unlinkable subject keys. Every enforcement decision is emitted to an append-only, hash-chained audit log with a per-record HMAC and an Ed25519 Signed Tree Head checkpointed every 32 records and co-signed by a local witness (same process / same keystore — not an external multi-party notary), giving you a tamper-evident (not tamper-proof) record. Right-to-erasure is cryptographic erasure (crypto-shred): destroying the per-subject linkage key renders that session subject’s identifiers unrecoverable while the chain stays verifiable; completion evidence is an erasure.completed audit record (HMAC-chained, covered by the next STH — not a separately signed certificate blob). Administrative access uses RBAC (Auditor, Operator, Approver, DPO) with dual-control on permanent/CIDR bans, erasure (DPO), and the kill switch. Behavioral interaction timings are component-scoped: controllers who deploy Gate only (no Core Pass / full client behavioral path) must not claim mouse/keystroke timing dynamics in an Article 13 notice that the Gate deployment does not collect. Taken together, these features support your GDPR/PIPA erasure and audit workflows; they do not, on their own, make you compliant.

Warning: Cryptographic erasure is irreversible. Once the per-subject linkage key is shredded, the pseudonyms for that session subject can no longer be resolved, and the erasure.completed audit record is the reference evidence of completion. A cancellable hold window (default 5 minutes) precedes execution; after that window, the shred cannot be undone.

Your next three reads

Right-to-Erasure (crypto-shred) Runbook — the DPO-gated, two-person, two-phase procedure for accepting an erasure request, the hold window and its cancellation path, and how to retrieve the erasure.completed audit evidence. Read this first: it is the workflow you will operate.
Concepts & Glossary — audit-log and pseudonymization vocabulary (hash chain, STHs, local witness, integrity classes). Retention labels HOT/WARM/COLD are declared only in the reference — not auto-enforced.
RBAC, separation-of-duties & dual-control reference — the role×capability matrix (Auditor / Operator / Approver / DPO), server-derived actor identity, and which actions need a distinct committer (permanent/CIDR bans and the kill switch need a distinct Approver; erasure needs a distinct DPO). This is your separation-of-duties evidence for an audit.

Verify it yourself

The audit and integrity surfaces are exposed on the authenticated admin listener (default 127.0.0.1:8445 (loopback)), under the admin API base /__hmn/admin/ with bearer-token auth. Relevant read-only endpoints for a DPO or auditor include GET /__hmn/admin/integrity, GET /__hmn/admin/audit (filterable by verdict, host, route, rule, minimum risk, and a before cursor), and GET /__hmn/admin/erasures. Every authenticated access is itself meta-audited before the response is served.