Reversible Anonymization Proxy Relaying Data To LLM Inference
This detects a specific pattern: someone runs a tool that pseudonymizes data in a way that can be reversed, then shortly afterward the same machine sends data to an AI inference service. The concern is that 'anonymized' data sent this way isn't really anonymous — the mapping to re-identify it stays on the local machine, so the data can be un-masked later even though it just left the organization.
How the attack works
An operator installs or runs a reversible anonymization/pseudonymization proxy (tools named things like anonproxy, anon-proxy, or a generic anonymizer combined with reversal flags like --reverse, --restore, --deanon, or artefacts like token_map.json). Within a short window of that tool running, the same host sends outbound HTTP traffic shaped like a call to an LLM inference API. The rule treats the proxy launch as the trigger and only then looks at the outbound traffic — normal AI agent traffic on its own is not flagged. Because the pseudonymization is reversible and the mapping key stays local, the data that leaves is not truly de-identified.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 6f1c9a52-3d84-4b7e-9c02-71ae5d4f8b13
- Severity
- High
Why it matters
Sensitive or client data can leave the organization in a form that looks anonymized but is actually re-identifiable, since the reversal key never leaves the local machine. This is a data-governance exposure — a compliance and confidentiality risk — even when no policy is technically broken.
What you can do
- →Treat any detection as a data-handling decision, not an automatic incident: confirm whether the activity was an approved engagement and track it with a ticket or accepted-risk reference.
- →Inventory where reversible pseudonymization/mapping keys are stored, and restrict who can run anonymization proxies against production or client data.
- →Require that data sent to external LLM services either use non-reversible anonymization or go through an approved, logged pathway.
- →Review CI and test environments for anonproxy usage to reduce false positives, but do not blanket-suppress the rule, since sanctioned and unsanctioned use look identical to it.
Known benign look-alikes
- Sanctioned use. A security engineer running anonproxy exactly as intended to pseudonymize engagement data before an approved LLM review. The rule reports this deliberately - reversible pseudonymization still moves re-identifiable client data to a third party and the mapping is retained locally - and it should be closed as accepted risk with a ticket reference, not silently suppressed.
- CI or unit-test runs of the anonproxy package itself (pipx run anonproxy --help, pytest driving the CLI) on a workstation where a coding agent independently calls an inference API inside the same 15-minute window.
- Unrelated GDPR/DSAR anonymization utilities (anonymize.py --restore, pseudonymizer --mapping=map.json). These only reach the report path if inference-shaped egress also occurs in the window; the generic-anonymizer branch additionally requires an explicit reversal or token-mapping artefact.
- pip install anonproxy pulled in during dependency resolution. An install with no subsequent proxy run and no inference egress never reports - it is only cached as a Supply Chain stage for a later chain.
- Documentation demos, conference reproductions and blog write-ups executed against synthetic scan output.
- Busy multi-user or CI hosts, where the egress stage can be contributed by a process unrelated to the proxy. The reason string names the relaying process and the endpoint so triage can dismiss it in seconds.