# Reconstructing Red Team Engagements — Developing Your Own Red Agent

- URL: https://bryancowan.com/reconstructing-red-team-engagements-developing-your-own-red-agent/
- Published: August 12, 2026
- Series: Conference notes
- Tags: defcon34
- Part of: [DEF CON 34 Notes: 15 Talks on AI Security, Agentic Systems, and Red Teaming](https://bryancowan.com/def-con-34-notes-15-talks-on-ai-security-agentic-systems-and-red-teaming/)

**Source:** [Adversary Village talk page](https://adversaryvillage.org/adversary-events/DEFCON-34/Jun-Miura/) · **GitHub:** [Red_Agent_Workshop](https://github.com/jyadon/Red_Agent_Workshop)

📄 [Download this note as Markdown](https://raw.githubusercontent.com/bryancowan/defcon34-notes/main/Reconstructing%20Red%20Team%20Engagements%20-%20Developing%20Your%20Own%20Red%20Agent.md)

## Overview

With recent advances in AI, LLMs are increasingly applied to red team engagements — but mostly just to automate operations during the engagement itself. This talk introduces "Red Agent," a system designed to enhance the *entire* lifecycle. After a red team engagement, blue team members implementing remediation need to evaluate their effectiveness — a bottleneck requiring substantial manual effort to interpret findings, reproduce attack paths, and verify mitigations. Red Agent automates this follow-up process, and in doing so also optimized the engagement artifacts (logs, report structures) that feed it — reconstructing the red team lifecycle so practitioners can focus on higher-value work.

## Notes

### Red Team Engagement
Red Agent does adversary emulation, targeting specifically the post-engagement validation process. It's a multi-agent system with an orchestrator managing sub-agents that understand the report, plan re-test procedures, execute tasks, and interpret/summarize results — making the validation process repeatable and scalable.

### Architecture

![Talk slide showing Red Agent's implementation architecture. One application server runs a SOCKS server, a web frontend, a backend API, and Red Agent. A user accesses the web frontend, and Red Agent sends inference requests to a separate LLM server and gets results back. Re-test traffic goes through the SOCKS server and a SOCKS tunnel into the target environment's workstations and servers.](https://raw.githubusercontent.com/bryancowan/defcon34-notes/main/images/red-agent-architecture.jpg)

- **Deep Agent** — agents for long-running tasks with memory, planning, and delegation tools
- **Custom Kali MCP Server** — lets the agent execute commands on Kali Linux; existing MCP servers were too limited for re-testing workflows
- **Human-in-the-Loop** — validates actions before the agent takes them; can approve, edit, or reject (rejecting skips the action)

### Capabilities
Creates documents and artifacts that are LLM/agent-friendly, accumulating data and knowledge over time to extend the agent's capabilities — freeing the human to focus on more advanced, value-add work.

### From the Repo
Three-tier architecture: a Vite + React frontend (port 5173) for reviewing findings with human approval gates, a FastAPI backend (port 8000) orchestrating the verification workflow and persisting to SQLite, and an execution layer running commands through the Kali MCP server over stdio. DC auto-discovery pulls AD domain controller info via DNS/SMB; Entra support integrates with `roadrecon`. Audit logging retains operations for 180 days by default. Quick setup: `make install` → set `LLM_BASE_URL` in `.env` → `make dev` → UI at `localhost:5173`.

### A Bug I Found and Fixed
Setting up the repo locally ahead of the workshop (macOS, Python 3.11), I hit a missing `greenlet` dependency — not pinned in `requirements.txt`. Without it, SQLAlchemy's async engine throws on every DB operation, breaking the periodic audit-log prune job and retest history persistence. Fixed it locally, then forked the repo, pushed a fix branch, and [opened a PR upstream](https://github.com/jyadon/Red_Agent_Workshop/pull/1) adding `greenlet==3.5.4` to `requirements.txt`.

_Filed Under:_ #defcon34