Privacy-compliant proxy system for large language models with hybrid post-quantum secure audit chain and zero-knowledge encryption

Abstract

Privacy-compliant proxy system for large language models, comprehensive: a) an authentication module for validating user access using API keys, JWT tokens or cookies with role-based access control, b) a multi-layered PIl recognition module with at least four parallel recognition layers, comprising a neural named entity recognition layer, a rule-based regex recognition layer, a keyword-based recognition layer, and a context-based recognition layer, c) a pseudonymization module for replacing identified personal data with type-preserving pseudonyms with session-consistent assignment and randomized starting counters as an anti-cardinality measure, d) a multi-provider proxy module for forwarding pseudonymized requests to at least one external AI language model provider, e) a de-pseudonymization module for retranslating the pseudonyms in the AI ​​response and a response PII redaction module for detecting and redacting AI-generated new personal data in the response, characterized in that f) a hybrid signature and audit chain module is provided which generates an audit entry for each transaction, signs it with both a classical signature method (Ed25519) and a post-quantum secure signature method (ML-DSA-65), and links the entries in a hash chain, with each signature being verified immediately after generation and before being written to the database (write-time verification), and g) a zero-knowledge encryption module is provided which encrypts the audit entries after signing with a user-specific Data Encryption Key (DEK), the DEK being derived from the user password and existing only in volatile memory during the active session, and the hash chain and signatures being preserved in plaintext so that the integrity of the audit chain can be verified without decrypting the contents.

Description

Technical field

[0001] The invention relates to a system for the data protection-compliant forwarding of requests to AI-based large language models (LLMs), in particular a proxy system with integrated recognition and pseudonymization of personal data (PII), a cryptographically secured audit chain with hybrid post-quantum secure signatures and a zero-knowledge encryption architecture. State of the art

[0002] Large language models (LLMs) such as GPT, Claude, or Gemini are increasingly being used in companies. This involves sending requests to external AI providers, which often contain personal data.

[0003] This presents companies with significant data protection challenges, particularly with regard to the General Data Protection Regulation (GDPR) and the EU General Data Protection Regulation (GDPR).

[0004] Known solutions in the prior art have the following disadvantages: (a) LLM proxy systems such as LiteLLM or Portkey offer a unified interface to multiple AI providers and some have PIL detection capabilities via third-party software (e.g., Presidio), but do not offer an integrated cryptographically secured audit chain with hybrid post-quantum secure signatures, a zero-knowledge encryption architecture, or a bidirectional pseudonymization pipeline with round-trip guarantee and anti-cardinality protection. (b) Pil detection systems such as Microsoft Presidio or Google Cloud DLP offer detection of personal data, but are not designed as a transparent proxy for LLM-APls and do not offer a bidirectional pseudonymization pipeline with a round-trip guarantee. (c) Audit log systems such as Hyperledger-based solutions offer tamper-proof logging, but do not use hybrid post-quantum secure signatures (Ed25519 + ML-DSA-65) and do not offer zero-knowledge encryption where the operator cannot technically view the audit contents. (c2) AI-specific data protection platforms such as Nightfall Al or Protecto.ai offer PII detection and partial pseudonymization for AI applications, but do not have a cryptographically signed audit chain, post-quantum secure signatures, or a zero-knowledge encryption architecture with client-side key management. (c3) In the academic literature, the publication arXiv:2502.15233 (February 2025) describes a general pseudonymization framework for cloud-based LLMs. However, this framework deals exclusively with the pseudonymization component and does not offer a cryptographically signed audit chain, zero-knowledge encryption, or post-quantum signatures. (d) Zero-knowledge encryption systems such as ProtonMail or Signal offer end-to-end encryption, but are not tailored to the specific requirements of AI compliance proxies and, in particular, do not provide a verifiable audit chain while encrypting the audit content. (e) Patent US20220164474A1 describes real-time pseudonymization for cloud services, but is not designed for LLM-specific proxy architectures with bidirectional PII control and cryptographic chain of proof. (f) Patent US20200074117A1 describes tamper-proof audit logs, but uses only classical cryptography without post-quantum signatures or zero-knowledge encryption.

[0005] None of the known systems combines all the aforementioned functions in one integrated system. Object of the invention

[0006] The invention is based on the objective of creating a system that enables the data protection-compliant use of large language models by automatically recognizing and pseudonymizing personal data, generating a tamper-proof and quantum computer-resistant audit chain, and implementing a zero-knowledge architecture in which even the system operator has no access to the stored user data. Solution

[0007] The problem is solved by a system with the features of claim 1.

[0008] The system according to the invention comprises the following components, which interact in a defined pipeline: 1. Authentication module

[0009] The system includes an authentication module with three cascading authentication paths: API key-based authentication for machine access, JWT token-based authentication for API clients, and cookie-based authentication for web users. The authentication module supports two-factor authentication using TOTP (Time-based One-Time Password) and implements role-based access control (RBAC) with plan-based feature control. 2. PII detection module

[0010] The system includes a multi-layered PIL detection module that combines four parallel detection layers: (a) A neural named entity recognition layer based on a pre-trained German language model (e.g. spaCy de_core_news_Ig); (b) A rule-based recognition layer with at least 27 regex recognizers for structured identifiers, in particular German formats such as IBAN, health insurance number (KVNR with ISO 7064 Mod 11,10 check digit validation), tax ID, identity card number, vehicle registration number, file number, commercial register numbers, BIC / SWIFT, VIN, IMEI and driving licence numbers; (c) A keyword-based recognition layer with at least 14 recognizers for special categories of data pursuant to GDPR Articles 9 and 10, including genetic, biometric and health data as well as criminal and children's data; (d) A context-based recognition layer with natural language analysis, which in particular recognizes access data in natural language (e.g. “My password is…”) using verb-connector analysis and meta-word filtering.

[0011] The PII detection module also includes a post-processing pipeline with a defined processing sequence: Unicode NFKC normalization against homoglyph attacks, NER false positive filtering before overlap resolution, gazetteer injection for geographic entities before overlap resolution, organization injection after overlap resolution, and context-based type conflict resolution. 3. Pseudonymization module

[0012] The system includes a pseudonymization module that replaces recognized personal data with type-preserving pseudonyms. The pseudonymization is session-consistent, ensuring that identical entities within a session always receive the same pseudonym. The module uses randomized starting counters (offset 100-899) as an anti-cardinality measure, preventing the number of recognized entities from being inferred from the pseudonym. 4. Multi-Provider Proxy Module

[0013] The system includes a provider proxy module that forwards pseudonymized requests to at least one external AI provider. This module supports at least three different API formats from major AI service providers via a registry-based provider abstraction. Each provider is equipped with its own circuit breaker module, which implements three states (closed, open, half-open) with time-window-based error accumulation. 5. De-pseudonymization and response PII editorial module

[0014] The system includes a de-pseudonymization module that replaces pseudonyms in the AI ​​response with the original data. Subsequently, a response PII redaction module performs a new PII detection on the de-pseudonymized response to identify and redact any new personal data that the AI ​​model has independently generated. The module distinguishes between user-entered PII (which is not redacted) and AI-generated PII (which is redacted) using a substring-based re-identification check.

[0015] For streaming responses (server-sent events), the system implements a chunk-spanning de-pseudonymization with a final overall check at the end of the stream for pseudonyms that were shared across chunk boundaries. 6. Hybrid Signature and Audit Chain Module

[0016] The system includes an audit module that generates an audit entry for each AI transaction and inserts it into a tamper-proof hash chain. Each entry includes: (a) A SHA-256 content hash of the audit content; (b) A chaining with the previous entry via its content hash (hash chain principle); (c) A first digital signature using Ed25519 (classic signature method) via the concatenation content_hash:previous_hash; (d) A second digital signature using ML-DSA-65 (post-quantum secure signature scheme according to NIST FIPS 204) over the same chain; (e) Write-time verification, in which each generated signature is verified immediately after generation and BEFORE being written to the database; if the verification fails, the write operation is aborted (fail-closed principle); (f) Atomic serialization using database advisory lock and sequence number to prevent chain forks in the case of multiple replicas; (g) A graceful degradation mode in which, if the Post-Quantum library is unavailable, the chain is continued with only Ed25519 signatures, with the number of degraded entries being explicitly counted. 7. Zero-knowledge encryption module

[0017] The system includes an encryption module that implements a zero-knowledge architecture: (a) A user-specific Data Encryption Key (DEK) is derived from the user password using Argon2id and exists only during the active session in volatile memory (e.g. using an in-memory data storage system with TTL support); (b) After signing with the user-specific DEK, the audit entries are symmetrically encrypted (e.g. using AES-based authenticated encryption), whereby the plaintext fields (content hash, previous hash, signatures) are preserved and only the audit body is encrypted; (c) The hash chain and signatures remain in plaintext, so that the integrity of the audit chain can be verified by third parties without having to decrypt the encrypted contents; (d) A recovery key mechanism enables the recovery of the DEK in case of password loss using a separate 256-bit key that stores the DEK in wrapped form; (e) When a password is changed, all encrypted data (conversations, messages, PII mappings, TOTP secrets, provider keys, audit entries) will be transactionally re-encrypted with the new DEK, with failed individual operations being counted and logged. 8. Blockchain Anchoring Module

[0018] The system includes an anchoring module that periodically anchors the current state of the audit chain to a public blockchain. An anchor hash is calculated from the last chain hash, the chain length, and a timestamp, and signed using both signature methods (Ed25519 and ML-DSA-65). Additionally, an internal timestamp is generated, the structure of which serves as a basis for later connection to a qualified eIDAS trust service provider. 9. Trust Monitor Module

[0019] The system includes a trust monitoring module that periodically checks the cryptographic integrity of all components: (a) Round-trip self-tests of both signature methods (signing and verification of a test message); (b) Retroactive verification of the entire audit chain (hash chaining, Ed25519 signatures, ML-DSA-65 signatures); (c) Certificate expiry monitoring for mTLS certificates; (d) Aggregated health status with a three-level condition model (not checked / correct / faulty) to avoid false alarms at system startup. Advantages of the invention

[0020] The system according to the invention offers the following advantages over the prior art: (a) Full data protection: Personal data is automatically recognized and pseudonymized before being transferred to external AI providers. The recognition encompasses 42 categories with specific support for German identification numbers and special categories of data pursuant to GDPR Articles 9 and 10. (b) Quantum computer resistance: The hybrid dual signature using Ed25519 and ML-DSA-65 protects the audit entries against both current and future quantum computer-based attacks. This is particularly relevant for audit logs that must be retained for decades. (c) Zero-Knowledge Guarantee: The system operator cannot technically access the stored user data, as encryption is performed with a user-specific key derived from the password. At the same time, the integrity of the audit chain remains verifiable by third parties, as the hash chain and signatures are preserved in plaintext. (d) Tamper protection: The combination of hash chain, hybrid dual signature, write-time verification and blockchain anchoring provides a multi-layered integrity safeguard that virtually eliminates tampering. (e) Bidirectional PII control: The system not only protects against PII in queries, but also detects and redacts PII that the AI ​​model independently generates in its responses. (f) Graceful Degradation: If the post-quantum library is unavailable, the system remains functional using classical cryptography without breaking the integrity of the audit chain. Example of implementation

[0021] The following is an example of the invention's implementation based on a typical usage scenario.

[0022] A business user sends a request to a large language model via a chat application. The request is, for example: "Create a summary of the contract with Max Mustermann, IBAN DE89 3704 0044 0532 0130 00."

[0023] The system processes this request in the following steps: Step 1 -- Authentication: The authentication module validates the user's API key, checks the plan permissions, and loads the user-specific DEK from the in-memory session storage. Step 2 -- PII Recognition: The PII recognition module identifies two personal data entities: “Max Mustermann” (category PERSON, recognized by the NER layer) and “DE89 3704 0044 0532 0130 00” (category IBAN, recognized by the Regex Recognizer with IBAN check digit validation). Step 3 – Pseudonymization: The pseudonymization module replaces the recognized data with type-preserving pseudonyms: “Max Mustermann” becomes “PERSON_547” and the IBAN becomes “IBAN_312”. The mapping between original and pseudonym is encrypted using the user-specific DEK and stored in the database. Step 4 -- Provider forwarding: The proxy module forwards the pseudonymized request ("Create a summary of the contract with PERSON_547, IBAN IBAN_312.") to the configured AI provider. Step 5 -- De-pseudonymization: The KL response is de-pseudonymized, with “PERSON_547” being replaced by “Max Mustermann” and “IBAN_312” being replaced by the original IBAN. Step 6 – Response PII Redaction: The de-pseudonymized response is checked again for PII. If the AI ​​model has independently generated new personal data in its response (e.g., a fictitious phone number), this is detected and redacted. Step 7 – Audit Entry: An audit entry is generated that logs the transaction (timestamp, provider, model, number and types of detected PII, latency) without containing the actual personal data. The content hash is calculated, the entry is signed with Ed25519 and ML-DSA-65, both signatures are immediately verified (write-time verification), and the entry is inserted into the hash chain. The audit body is then encrypted with the user-specific DEK. Step 8 -- Response: The cleaned response is returned to the user. Commercial applicability

[0024] The system according to the invention is directly applicable to commercial use as a Software-as-a-Service (SaaS) product for companies that wish to use large language models in compliance with the GDPR and the EU General Data Protection Regulation (GDPR). It can be operated as a cloud service or as an on-premises installation and is implemented in a production environment with containerized microservices, a relational database, an in-memory cache, and a reverse proxy. The system achieves technical effects in the form of cryptographically guaranteed tamper resistance and information-theoretically secured confidentiality. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 20220164474A1

[0004] US 20200074117A1

[0004] Cited non-patent literature

[0000] Create a summary of the contract with Max Mustermann, IBAN DE89 3704 0044 0532 0130 00

[0022]

Claims

[1] Privacy-compliant proxy system for large language models, comprehensive: a) an authentication module for validating user access using API keys, JWT tokens or cookies with role-based access control, b) a multi-layered PIl recognition module with at least four parallel recognition layers, comprising a neural named entity recognition layer, a rule-based regex recognition layer, a keyword-based recognition layer, and a context-based recognition layer, c) a pseudonymization module for replacing identified personal data with type-preserving pseudonyms with session-consistent assignment and randomized starting counters as an anti-cardinality measure, d) a multi-provider proxy module for forwarding pseudonymized requests to at least one external AI language model provider, e) a de-pseudonymization module for retranslating the pseudonyms in the AI ​​response and a response PII redaction module for detecting and redacting AI-generated new personal data in the response, characterized by , that f) a hybrid signature and audit chain module is provided which generates an audit entry for each transaction, signs it with both a classical signature method (Ed25519) and a post-quantum secure signature method (ML-DSA-65), and links the entries in a hash chain, with each signature being verified immediately after generation and before being written to the database (write-time verification), and g) a zero-knowledge encryption module is provided which encrypts the audit entries after signing with a user-specific Data Encryption Key (DEK), the DEK being derived from the user password and existing only in volatile memory during the active session, and the hash chain and signatures being preserved in plaintext so that the integrity of the audit chain can be verified without decrypting the contents. [2] System according to claim 1, characterized by , that the hybrid signature and audit chain module has a graceful degradation mode in which, if the post-quantum secure signature method is unavailable, the audit chain is continued with exclusively classical signatures, with the number of degraded entries being explicitly counted and monitored. [3] System according to claim 1 or 2, characterized by, that the hybrid signature and audit chain module includes atomic serialization using database advisory lock and sequence number, which prevents chain forks with multiple parallel writing replicas. [4] System according to one of the protection claims 1 to 3, characterized by that the zero-knowledge encryption module includes a recovery key mechanism in which a separate random recovery key stores the DEK in wrapped form, so that in case of password loss the DEK and thus access to the encrypted data can be restored. [5] System according to one of the protection claims 1 to 4, characterized by , that the zero-knowledge encryption module performs a transactional re-encryption of all encrypted data records with the new DEK when the password is changed. [6] System according to one of the protection claims 1 to 5, characterized by, that a blockchain anchoring module is provided which periodically anchors the current state of the audit chain to a public blockchain, calculating an anchor hash from the last chain hash, the chain length and a timestamp, and signing it with both signature methods (Ed25519 and ML-DSA-65). [7] System according to one of the protection claims 1 to 6, characterized by , that a trust monitor module is provided which periodically performs round-trip self-tests of both signature methods, retrospectively checks the entire audit chain for integrity, and monitors certificate expiry times, with a three-stage state model (not checked, correct, faulty) preventing false alarms at system startup. [8] System according to one of the protection claims 1 to 7, characterized by, that the PII detection module includes a post-processing pipeline with a defined processing order, in which Unicode NFKC normalization against homoglyph attacks, NER false positive filtering is performed before overlap resolution, and context-based type conflict resolution is performed after the overlap resolution. [9] System according to one of the protection claims 1 to 8, characterized by , that the multi-provider proxy module includes a registry-based provider abstraction with at least three supported API formats and has a separate circuit breaker for each provider with three states (closed, open, half-open) and time-window-based fault accumulation. [10] System according to one of the protection claims 1 to 9, characterized by, that the de-pseudonymization module for streaming responses (server sent events) implements chunk-spanning de-pseudonymization with final overall verification at the stream end to correctly resolve pseudonyms that have been shared across chunk boundaries.