A client engaged us to red team their internal network. It was fully black box: zero input, no starting credentials, and no guidance on where to begin. The only thing we were given was presence on the internal network. Everything else we would have to find.
We have been using a three-part setup for our external engagements: a large language model driving the testing, RedactProxy protecting client data, and Red Clippy keeping the record of everything the agent did. It has worked well against internet facing targets, so the obvious next question was whether the same stack could carry an internal engagement too. This article is about the first time we took it inside a client's network.
Before doing any of it, we asked the client for explicit permission to run an AI agent as part of the engagement, and we got approval to use it. That authorization mattered, because the tooling only enforces scope as a guardrail. The responsibility for what the agent does stays with the operator.
A quick note on the three tools
The LLM: We used GLM5.3 from z.ai as the reasoning engine, driven through an agentic coding CLI. The model reads the current state of the engagement, decides what to test next, runs tooling from its own shell, and writes up what it finds. We also evaluated Claude for the same role. We had already applied for its Cyber Use Case approval and been granted it, but in practice it repeatedly tripped its own safety guardrails mid-engagement and refused to continue, which left it effectively unusable for hands-on red team work.
RedactProxy: This is a local, two way redaction proxy from the Cyber Security and Privacy Foundation. It helps to keep a client's real data from ever reaching a third-party LLM provider. It sits between the agent and the LLM provider. On the way out it replaces real client values (domains, internal IPs, emails, credentials, hostnames) with stable fake placeholders. On the way back it swaps the placeholders for the real values before the agent sees them. The model only ever sees fakes, but the agent's own tool calls still run against real infrastructure. The same real value always maps to the same placeholder for the life of an engagement, so the model can still reason that two hosts belong to the same organization without ever learning their real names.
Red Clippy: This is a pentest management tool built to be operated by an AI agent, also from the Cyber Security and Privacy Foundation. It helps to solve a simple problem: agents forget. When the context window fills up, the engagement is gone, and the next session rescans hosts and retests things you already ruled out. Red Clippy persists assets, observations, methodology coverage and findings to a local database, and it hands the agent a red team instructions document at the start of every session. So the next run picks up exactly where the last one stopped.
The challenge: a network with no way out
We set out to deploy the stack and immediately hit a wall. The client's internal network is heavily restricted. From inside it we could not reach z.ai, or any other LLM provider, or really anything on the public internet. That is good security on their part, but it broke the obvious plan of running the agent from a machine on their network and letting it call the model directly.
This is where RedactProxy turned out to be useful in a way we had never planned for.
The setup
We built the environment so that the machine touching the client network never touches the internet, and the machine touching the internet never touches the client network. Concretely:
We set up a Linux virtual machine and put it in host only network mode, so it had no route into the internal network at all. For its internet access we used a mobile phone with USB tethering, and we tethered it to the virtual machine specifically, not to the host laptop. We deployed RedactProxy inside that virtual machine and configured it to use z.ai with GLM5.3 as the upstream provider.
On the main machine, the one with presence on the client network, we pointed the red team project's LLM provider setting at the virtual machine's IP and the RedactProxy port. From the point of view of the agent CLI on the main machine, it is simply talking to an LLM provider. In reality every request is going to RedactProxy in the VM, getting redacted, being forwarded out over the phone tether to z.ai, and coming back the same way.
So the two worlds stay separate. The client network side has no path to the internet. The internet side has no path to the client network. The only thing crossing between them is redacted API traffic.
Honestly, the tethering and network separation part could have been done with any proxy. The original point of RedactProxy for us was never connectivity, it was to avoid leaking the client's internal IP addresses and names to the LLM provider. We just had not thought about this second benefit until the restricted network forced the design, and the same tool solved both problems at once.
Running the
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: