Technical and organizational measures: TokenVeil (GDPR Art. 32)

Annex to the compliance dossier. Describes the security measures implemented in the product. To attach to the records of processing and, where applicable, to the customer’s DPIA.

1. Encryption

Item	Measure
Pseudonymization mapping (token to real value)	Encrypted at rest (Fernet: AES-128-CBC + HMAC-SHA256). Never leaves the process.
Credentials of per-user linked AI accounts	Encrypted at rest (Fernet), file permissions `0600`.
LDAP service account password	Encrypted at rest (Fernet) in the configuration database.
Transport	TLS required (termination at the upstream reverse proxy; session cookie set to `Secure` + HSTS enabled in that mode).

2. Authentication and access management

Local accounts: passwords hashed with PBKDF2-HMAC-SHA256, 600,000 iterations (OWASP recommendation), a random 128-bit salt per account.
LDAP / Active Directory: bind + search; the user password never travels in clear text and is never stored. LDAP filters are escaped (injection safe).
Sessions: a random 256-bit token; only its SHA-256 hash is persisted (a leak of the sessions table does not let anyone replay a session). Cookie HttpOnly, SameSite=Lax, Secure (under TLS).
Roles: user / administrator separation; administration routes require the admin role.
Multi-tenant (LDAP option): seat quotas per group.

3. Abuse resistance

Brute-force protection: temporary lockout after N failures per account AND per IP address (the latter against password spraying, where a single password is tried across many accounts).
Application rate limiting: a sliding window per user / API key / IP, with separate caps depending on the sensitivity of the route (authentication, AI calls, the rest). Fail-open (a limiter outage never blocks legitimate access).
API keys (integrations / IDE extension): hashed with SHA-256 (never stored in clear), configurable expiry, a daily call quota, immediate revocation.

4. Application and infrastructure hardening

HTTP security headers on every response: a strict Content-Security-Policy (no third-party origin allowed), X-Frame-Options: DENY (anti-clickjacking), X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, HSTS behind TLS.
Zero external dependency at load time: all frontend assets (JavaScript, fonts) are served locally. The product works air-gapped and exposes no supply-chain attack surface through a third-party CDN.
Non-root container: runs under a dedicated (unprivileged) user.
Data isolation: each user can only access their own conversations and work (systematic access control; generic 404 responses so the existence of someone else’s resources is not revealed).

5. Logging and auditability

Anonymization audit log: for each message, records the category and the number of pseudonymized items, never the real value. Lets you prove to a CISO/DPO that pseudonymization happened, without recreating a leak risk in the log.
License traceability: a signed periodic check, with no personal data.

6. Quality assurance of the pseudonymization engine

Annotated test set (regression): each sensitive-data category is checked on every change.
Random fuzzing: thousands of lines generated from a random seed, measuring the leak rate on a sample never seen in advance.
Continuous integration: the CI gate blocks any change that would reintroduce a leak (threshold: 0%).
Typical result: 0% leakage measured (recall), an over-pseudonymization rate below 0.1%.

7. Reversibility and erasure

Pseudonymization is reversible on the customer side only, through the local encrypted mapping.
Deleting a conversation destroys its mapping: the tokens become permanently non-reversible (supports the right to erasure, Art. 17).

The measures above describe the product’s capabilities at its current version. Their effective implementation (TLS, backups, administrator access management, retention periods) is the responsibility of the organization that deploys TokenVeil.