AIDA: an LLM agent that runs pentest engagements inside a Docker container

The gap AIDA targets: enumeration drudgery, not exploit discovery

AIDA is aimed at the part of a penetration test that is mechanical. The README frames the split explicitly: the agent reasons about application logic, runs commands in an isolated container, and documents findings with the commands used, while the human reproduces, triages, prioritises and reports. The stated audience is a working tester who already knows how to confirm a finding and just does not want to spend the day running ffuf against subdomains. The project claims results that reached CVE records, including an unauthenticated RCE in kestra-io/kestra scored CVSS 10.0 and two Appsmith issues. Those entries are the author's own disclosure list and cannot be independently checked from the repository material alone; treat them as a claim about the tool's ceiling rather than a baseline you should expect on your own targets. What is concrete is the division of labour: the agent produces a notebook of observations, attack paths and confirmed vulnerabilities with raw output, and the tester stays in the review seat.

How the agent executes: MCP tools over a disposable container

The architecture is a tool-calling loop. AIDA exposes a fixed set of functions to whichever model client you attach, and the model decides when to call them. The tool list is short and specific: execute() for arbitrary shell commands, scan() wrapping nmap, gobuster, ffuf, nikto and dirb, subdomain_enum(), ssl_analysis(), tech_detection(), python_exec() for scripts generated on the fly, http_request() for direct header, cookie, body and token manipulation, add_card() to log a finding with CVSS 4.0 auto-scoring, and credentials_add() to store secrets. Command execution happens inside a bundled container the README calls aida-pentest, roughly 2 GB, started automatically. If a required tool is absent, the documentation states the agent installs it. Exegol can be plugged in for a larger toolset of 400+ tools, switchable from the dashboard. The HTTP tool substitutes stored credentials through {{PLACEHOLDER}} syntax, which is the mechanism that lets an authenticated engagement continue without the model handling raw secrets in its context on every call. The notebook is the persistence layer: it survives across sessions, so an engagement can be stopped and resumed days later for retest or handoff.

Getting it running: start.sh, aida.py and the scope prompt

The quick start is three commands. Clone the repository, change into it, run ./start.sh. The dashboard then answers on http://localhost:31337. Two flags change the deployment shape: ./start.sh --dev enables hot reload for contributors, and ./start.sh --lan shares the dashboard across a local network over HTTPS with a self-signed certificate. A third flag, ./start.sh --domain x.com, is documented for public deployment with Let's Encrypt. The agent is launched separately with python3 aida.py --assessment "target-corp". Model selection is a flag: --cli auto detects Claude, Codex, Kimi or Qwen, --cli codex forces OpenAI Codex, and --base-url points at any OpenAI-compatible endpoint. --yes suppresses confirmation prompts. Scope is not a config file; the README shows it typed as a natural-language instruction after the assessment loads, naming in-scope subdomains, authentication flows and API endpoints, plus an exclusion such as brute-force on /login. Prerequisites are Docker Desktop and an AI client. Claude Code, Kimi Code CLI and Codex CLI are described as automatic, while Claude Desktop, ChatGPT Desktop and Gemini CLI connect through MCP configuration.

The scope statement is prose, and that is the weak seam

The most consequential design choice in AIDA is that scope lives in a sentence you write to the agent. The README example reads: load the assessment, start the pentest on a URL, scope all subdomains and authentication flows and API endpoints, exclude brute-force on /login. Nothing in the supplied material describes a machine-enforced allowlist, a hostname filter on the scan tools, or a hard refusal when the model proposes an action outside the stated boundary. A model with execute() in its tool list is a model that can run whatever command it composes, and the only thing standing between that and an out-of-scope host is the agent's reading of your instruction. For an authorised test with a signed statement of work this may be acceptable, because the tester is watching. For anything unattended, or for targets where a single stray request has contractual or legal weight, the free-text scope is the failure mode to design around. The same applies to credential storage: credentials_add() and {{PLACEHOLDER}} substitution are convenient, and they also mean live secrets sit in the assessment state that the notebook persists across sessions.

When AIDA is the wrong tool

AIDA is an agent, not a scanner, and those are different products with different guarantees. A scanner such as Nuclei running its template set against a target produces the same output on the same input, can be diffed between runs, and can be wired into CI as a pass or fail gate. An LLM-driven loop does not offer that. Two runs over the same target with the same model can take different paths, and the README itself notes that the smarter the model, the deeper the engagement, which is a statement about variance rather than about coverage. If your requirement is a reproducible regression check after each deploy, or evidence that a defined checklist was executed in full, AIDA is the wrong layer. It is also wrong for anyone who cannot accept AGPL-3.0. The licence is strong copyleft, and the practical question for a commercial security team is whether the assessment tooling is distributed to clients or only used internally; that distinction has real consequences and is a question for your own counsel, not something the README answers. Finally, the project is young. The first public release was v1.0.0-alpha in January 2026 and v1.1.0 landed in April 2026, with the repository still receiving commits as of August 2026. Expect the tool surface to move.

Alternatives and the actual difference in approach

The closest comparison named in the material is Exegol, which AIDA treats as a drop-in upgrade rather than a rival: the dashboard can switch the execution environment to Exegol to get 400+ tools instead of the bundled aida-pentest image. That is the container layer only. Exegol gives you a curated offensive environment you drive yourself; AIDA adds the model that decides which command to run next and the notebook that records why. The other comparison is the scanner class, represented here by the tools AIDA wraps: nmap, sqlmap, ffuf, nuclei, nikto, dirb. Those are deterministic and scriptable. AIDA calls them, but the sequencing is model-driven, so the value it adds is judgement about what to try after the first result, not raw detection capability. If you want repeatable coverage, run the scanners directly. If you want a second pair of hands that keeps working through an application's logic while you read the output, that is the specific thing AIDA is built to provide.

Maintenance cost and what v1.1.0 changed

The upgrade story is a single moving part on the AIDA side and a heavier one underneath. AIDA ships as a start.sh script plus a Python launcher and a container image; updating means pulling the new repository state and restarting, and the --dev flag exists precisely so contributors can iterate without that cycle. The persistent notebook is the asset that makes upgrades cheap, because assessment state is not tied to the container's lifetime. The heavier dependency is the model client. AIDA is model-agnostic by design and the README states any LLM with tool-calling support works, which means a client that changes its tool-calling format or its CLI flags is a breakage you absorb. v1.1.0 is described as a stable release and the changelog excerpt mentions authentication work, JWT and admin functionality, but the supplied material cuts off mid-sentence, so the full scope of that release cannot be confirmed here. Before upgrading a running engagement, check the release notes for the version you are moving to rather than the README, which tracks main.

Editorial conclusion

Adopt AIDA if you already run authorised engagements and want command execution, credential injection and finding capture handled by an agent you can interrupt. Do not adopt it if you need deterministic, repeatable scans or cannot accept AGPL-3.0 terms. Before the first run, verify the aida-pentest container is reachable at localhost:31337, confirm which CLI aida.py selects with --cli auto, and check that your scope statement names the excluded paths, since the README shows exclusion rules written as free text rather than as an enforced allowlist.

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. Vasco0x4/AIDA on GitHub