REDCELL review: a LangGraph pentest agent that runs tools in a Kali container

The gap REDCELL is trying to close between scanning and reporting

Most security tooling stops at output. A scanner produces findings, and a person turns those findings into a narrative, a severity ordering and a remediation section. REDCELL's premise is that an LLM agent can hold the objective, choose the tool, read the output and write the report in one continuous run. The README describes an orchestrator that plans the engagement and hands objectives to executor agents, which run real tools inside a Kali container and report back.

The audience is narrow and worth stating plainly. This is for authorized penetration testers, red teams and security engineers who already know what nmap, nuclei and Metasploit do, and who want the repetitive middle of an engagement handled by agents while they watch and steer. It is not a scanner you point at a host and forget, and it is not a compliance checkbox. The README carries a warning that REDCELL is for education, research and legal, authorized security testing only, and that unauthorized access is a crime in Azerbaijan under Criminal Code articles 271 to 273 and under the laws of most other countries.

That warning is not boilerplate. REDCELL runs real tools by default. The .env.example sets REDCELL_RUN_MODE=live, and the comment next to it explains the alternative: "sim replays canned output and runs nothing." If you want to see the interface without touching a target, that variable is the switch.

How the LangGraph engine, the worker and the Kali container fit together

The architecture diagram in the README is the clearest statement of the design. The React operator console talks to FastAPI over REST and WebSocket. FastAPI writes to PostgreSQL, Redis and MinIO. Redis carries both pub/sub and the job queue. An arq worker picks up the run and drives the engine, which is LangGraph plus LiteLLM. The engine reaches the Kali container through docker exec, and the container reaches the targets.

The README states the consequence of that split directly: "The API does not run agents. It queues a run, the worker executes it, and the worker publishes output onto Redis channels that the API relays to the browser over WebSockets." This is a sensible separation. A long-running agent loop does not block HTTP handlers, and a worker restart does not lose the run, because checkpoints are written as the run proceeds.

Execution location is per session. The README says tools run in a Kali container over docker exec, and that you pick localhost or a saved server per session, with a remote server running the same container over SSH with host networking. That host networking detail matters: a remote executor is not sandboxed from the host's network namespace, which is exactly what you want for a pentest and exactly what you do not want on a shared build machine.

Models are pluggable through LiteLLM. The README lists OpenAI, Anthropic, Google, GLM, DeepSeek, Kimi and a local Ollama among the options. Nothing in the repository ties the engine to one vendor, so the model is a runtime choice rather than an architectural one.

Installing REDCELL and running your first session

The README's quickstart assumes Docker, uv and bun are already installed. Infrastructure comes first: Postgres, Redis and MinIO are declared in docker-compose.dev.yml. The documentation gives this command.

docker compose -f docker-compose.dev.yml up -d

Next, install the Python dependencies, apply the database migrations and seed the admin user, provider catalog and buckets. The README gives three commands in sequence.

uv sync --group live
uv run rc db upgrade
uv run rc seed

Copy the environment template before starting anything, because the backend reads it from the repository root. The .env.example notes that the JWT and secret key can be left blank in development, where they are generated once and persisted to .redcell-dev-secrets/, while production should set real values or point the *_FILE variables at mounted secret files.

cp .env.example .env

The README then runs three processes in separate terminals: the API on 127.0.0.1:8080, the arq worker, and the Vite dev server. The honcho alternative starts all three from the Procfile in one command.

cd apps/api    && uv run uvicorn app.main:app --host 127.0.0.1 --port 8080
cd apps/worker && uv run arq worker.settings.WorkerSettings
cd apps/web    && bun install && bun run dev

Open http://localhost:5183 and sign in with admin / admin. The README's next step is the one people skip: add a provider API key in Settings. Without a key the engine has no model, and the run will not plan anything. The README does not document what the console shows in that state, so treat the key as a precondition rather than a debugging step.

The operator console is the actual safety mechanism

The feature list reads like a normal agent platform until you reach the parts that hand control back to a human. The screenshot caption in the README describes the console mid-run: the multi-agent graph, verified critical findings, live terminals with sqlmap, a caught reverse shell, and the agent asking the operator before it dumps a user table.

That last clause is the design decision worth paying attention to. An autonomous pentest agent that can run sqlmap and catch a reverse shell is one configuration mistake away from exfiltrating data you did not ask it to touch. REDCELL's answer is not a permission system with fine-grained rules; it is a live console where a person watches and can intervene. The README says you can take control of the agent's browser to click through a login flow yourself and then hand it back, and that you can open your own terminals on a caught shell and run commands yourself.

Findings triage is the other human checkpoint. You verify or dismiss findings and merge duplicates the agent recorded twice, and the report leaves out the dismissed ones while marking the verified ones. This means the report is a product of your review, not the agent's raw output. If your workflow assumes the PDF is generated and shipped without a pass through triage, REDCELL does not match that workflow.

Notifications support the same model. In-app toasts plus browser notifications when the tab is in the background exist so that a question from the agent or a caught shell does not sit unseen. The design assumes someone is near the screen.

Where REDCELL will disappoint you

The honest limitation is that this is a young project with a fast release cadence. Three versions shipped on 2026-09-16 alone: v0.9.0, v0.10.0 and v0.11.0. The last push to the repository was on 2026-09-16. That is not a criticism of the maintainer's effort, but it does mean the surface is moving, and anything you build on top of the API or the database schema should expect churn. The README does not document a compatibility policy or a deprecation window.

The second limitation is environmental. REDCELL needs a Kali container reachable by the worker, and for remote execution that container runs with host networking over SSH. On a laptop this is a docker compose command. In a corporate environment where the security team's own tooling runs inside a restricted VPC, the network path from worker to Kali to target is a real piece of work, and the README does not walk through it.

The third is model cost and reliability. Every step of a plan/act loop is a model call, and a pentest has many steps. The README does not publish token budgets, per-run cost estimates or guidance on which model tier is appropriate. You will find out by running it. A local Ollama keeps the cost predictable but puts the planning quality on whatever hardware you have.

Finally, there is a mode mismatch to watch for. REDCELL_RUN_MODE defaults to live, and the .env.example is explicit that live runs real tools in the Kali container. Anyone who clones the repository, follows the quickstart and points a session at something they do not own has already crossed the line the README warns about. The sim mode exists, but the default is not it.

REDCELL against a conventional scanner

The obvious comparison is a traditional vulnerability scanner such as OpenVAS or Nessus. The difference is not detection quality; it is the unit of work. A scanner takes a target list and returns a finding list, with no notion of an objective, no adaptation when a service turns out to be a decoy, and no narrative. REDCELL takes an objective, chooses tools step by step, and produces a report with an executive summary, methodology, findings and remediation in priority order.

That adaptation is also the risk. Deterministic scanners are reproducible: the same input gives the same output, and you can diff two runs. An LLM plan/act loop is not reproducible in that sense, even with checkpoints. The README says every run checkpoints as it goes so a crash or restart picks up where it left off, which helps with recovery but does not make the planning deterministic.

A second comparison is the agent-browser capability. Tools like Playwright and Selenium automate a browser deterministically with a script. REDCELL's agent drives a real Chromium in the Kali container and decides what to click, which is the only way to get through a login flow you did not script in advance, and also the reason the human takeover feature exists. If your target is a well-understood web app with a stable login page, a scripted browser test is cheaper and repeatable. REDCELL is for the case where you do not yet know what the app will do.

Licence, deployment and the cost of keeping it current

REDCELL is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository also ships a SECURITY.md and a CODE_OF_CONDUCT.md, which suggests the maintainer expects outside contributions and reports. Nothing in the licence or the repository restricts the tool to non-commercial security work, so the legal boundary is not the licence; it is the authorization you have for the systems you point it at. The README places that responsibility on the user in explicit terms.

Upgrade cost is the thing to budget for. The release history shows three versions in a single day, and the repository has a deploy.sh, a docker-compose.yml with an in-app updater driven by REDCELL_COMPOSE_DIR and REDCELL_UPDATER_IMAGE, and a Procfile for local process management. That is a deployment story aimed at self-hosting, not at managed upgrades. The .env.example warns that REDCELL_COOKIE_SECURE must be false over plain HTTP on an IP and true over HTTPS, including behind a proxy that terminates TLS. Getting that flag wrong on a public deployment is a session-security problem, and it is the kind of detail that changes between versions.

The database schema is managed by Alembic, and the quickstart runs rc db upgrade before seeding. That gives you a migration path, but it also means an upgrade is a migration plus a container rebuild plus a worker restart, in that order, with the run queue drained or paused.

Editorial conclusion

Adopt REDCELL if you run authorized engagements and want the plan, the tool output and the write-up in one place, with a human able to take the browser or a shell mid-run. Do not adopt it if you need unattended execution against production, if you cannot give the worker a Kali container with host networking, or if you expect the report to be final without review. Verify first that your model provider is reachable from the worker and that your engagement scope is written down, since the README places legal responsibility on you and the container runs real tools by default.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. martian56/redcell on GitHub
4. README
5. Releases