DontFeedTheAI: a regex and Ollama anonymization proxy for AI-assisted pentesting
Transparent anonymization proxy for AI-assisted pentesting. Strips IPs, credentials, hostnames and PII before they reach any LLM (Claude, OpenAI, OpenRouter). Local Ollama + regex detection. Per-engagement vault.
At a glance
- What is it?
- DontFeedTheAI sits between your shell and a cloud LLM, replacing IPs, hostnames, credentials and tokens with surrogates and restoring them on the way back. The detection runs locally, the reasoning stays in the cloud, and the whole thing is driven by one wizard script.
- Who is it for?
- Adopt it if you already route pentest output through Claude Code or an OpenAI-compatible client and you want the substitution to happen on your own machine rather than at a third-party anonymization API. Do not adopt it if you need a guarantee of complete detection: the pipeline is a regex layer plus a local Ollama model, and the README itself points to the threat model for what it does not cover.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 70 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The specific leak this proxy is built to close
Pentest tooling produces exactly the material you are least allowed to paste into a cloud model: internal hostnames like dc01.acmecorp.local, private ranges like 10.20.0.10, credentials in the form Admin@Acme2024!, and tokens and hashes that identify a client's infrastructure. The README's own framing is that you are paying for context processing, and the AI does not need the real values to do that processing. The audience it names is narrow and honest: pentesters pushing nmap, mimikatz and bloodhound output through Claude, plus developers and SREs debugging with production configs, and legal or compliance people reviewing client documents. The author states plainly that he is a pentester rather than a software architect, and that the project exists because cloud anonymization APIs mean handing the data to yet another third party before it reaches the model. That is the design constraint driving everything else: detection stays on the machine, only the reasoning step is remote.
Two detection layers and a surrogate round trip
The pipeline is described as two layers running locally. An Ollama model handles the fuzzy cases: hostnames, organisation names and credentials embedded in prose, where a pattern match will not help. A regex layer handles the mechanical ones: IP addresses, hashes, tokens and API keys. The request flow in the README diagram is four steps. Your shell sends real data to the proxy, the proxy substitutes surrogates and forwards only those upstream, the LLM response comes back still containing surrogates, and the proxy restores the originals before the answer reaches your shell. So the model sees srv-0042.pentest.local where you typed dc01.acmecorp.local, and 203.0.113.47 where you typed 10.20.0.10. Mappings are held per engagement, which is what the ENGAGEMENT_ID environment variable selects. The important architectural consequence is that the cloud provider never receives a reversible mapping, and neither does any anonymization vendor, because there is no anonymization vendor in the path.
Running it: wizard.py, Docker, and two environment variables
Everything is driven through a single script. The README gives two paths. With a VPS, you clone the repository, run python3 wizard.py, and the wizard asks for engagement name, VPS address and model, then deploys, opens the SSH tunnel and launches Claude with the proxy active. Locally, without a VPS, the sequence is python3 wizard.py setup to create the virtualenv and install dependencies, then python3 wizard.py docker up to start the proxy and Ollama in containers, then export ANTHROPIC_BASE_URL=http://localhost:8080 and export ENGAGEMENT_ID=my-engagement before starting claude. The proxy is a FastAPI service on port 8080 by default, and the README states it works with Claude Code, the OpenAI SDK, OpenRouter, Requesty, or any OpenAI-compatible client. python3 wizard.py --help lists the remaining subcommands. Windows, macOS and Linux are all listed as supported platforms, and Python 3.11 or newer is the stated requirement.
The audit page is a debug tool with a real exposure
python3 wizard.py tunnel --audit opens a browser view of every ORIGINAL to SURROGATE mapping logged during the session, filterable by entity type such as DOMAIN, CREDENTIAL, TOKEN or HASH, with per-request timing. It is genuinely useful for spotting a leak without grepping logs. It is also, by the README's own admission, a debug tool that exposes the full surrogate to original lookup table, which is why it only runs behind the SSH tunnel. The README flags making this write-only, with no reverse lookup over HTTP, as roadmap work and points to the threat model document. Treat that as the honest state of the project: the audit surface is a convenience that currently hands out the mapping you spent the whole pipeline trying to keep out of third-party hands. If you run it, run it on the tunnel.
Coverage is fixture-driven, and the fixtures are the boundary
Two commands define how much you can trust the thing. python3 wizard.py test --integration pushes all 53 fixtures through the complete pipeline, LLM plus regex, and asserts zero leaks; it requires Ollama running. Without the flag the LLM is mocked and only the regex layer is exercised, which the README calls useful for fast iteration but not a substitute for the full run. The second command, python3 wizard.py improve --cycles 3, runs fixtures through the regex layer alone, reports leaks and false positives, and names the strings that slipped through. The contribution loop is explicit: add a fixture for a real tool you use, run the loop, add a regex pattern per leak, repeat. The limitation follows directly from that design. Detection quality is bounded by the fixtures someone wrote and the patterns someone added, so a hostname format or credential shape that no fixture covers is a candidate for passing through untouched. The Ollama layer is the fuzzy backstop, but the README gives no accuracy figure for it, and no release has been retrieved, so there is no versioned changelog to check coverage against.
Where this is the wrong tool, and what to use instead
If your data cannot leave the machine at all, this is the wrong layer. It is a proxy in front of a cloud API, so the cloud API is still in the path; the README's own comparison of running Ollama alone makes the point that local inference means the data never leaves, at the cost of Ollama having no awareness of what is sensitive. A local-only setup with a capable model is the alternative when the constraint is absolute rather than about specific identifiers. The other alternative is the cloud anonymization API the author explicitly rejects: it can be more accurate on prose because a hosted model does the detection, but it adds a second third party and a second bill, and your raw data still leaves the machine, just through more hands. The difference in approach is where the detection model lives, not whether one is used. Choose DontFeedTheAI when you want cloud reasoning quality and are willing to accept regex-plus-local-model recall as the price; choose the hosted anonymizer when you would rather pay for detection accuracy than run Ollama; choose local inference when nothing may cross the boundary at all.
Licence, maintenance and the upgrade question
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That matters for consultancies that want to fork the regex patterns for their own tooling. Nothing here is legal advice, and if you redistribute a modified version inside a client deliverable, read the licence text itself rather than this summary. On maintenance, the material supports only a limited read. The default branch is main, the repository is not archived, and the last push is dated 2026-07-08, so there is recent activity. No releases were retrieved, which means there is no tagged version to pin and no changelog to diff between upgrades. In practice that makes the fixtures the upgrade surface: if you extend the regex layer for your own engagements, expect to rebase those patterns on each pull rather than resolving a version bump, and re-run python3 wizard.py test --integration after every pull because the 53-fixture assertion is the only regression gate the README describes. The wizard's docker subcommand is the other moving part, since it pulls the proxy and Ollama images.
Editorial conclusion
Adopt it if you already route pentest output through Claude Code or an OpenAI-compatible client and you want the substitution to happen on your own machine rather than at a third-party anonymization API. Do not adopt it if you need a guarantee of complete detection: the pipeline is a regex layer plus a local Ollama model, and the README itself points to the threat model for what it does not cover. Before trusting it on a client engagement, run python3 wizard.py test --integration against the 53 shipped fixtures with Ollama up, then add a fixture for the actual tool output you plan to paste and rerun python3 wizard.py improve until the regex layer stops leaking your own strings.
Community notes