Executioner: Local Agentic Pentesting Environment Explained

Executioner is an open-source desktop app, published on GitHub by the account dbx0 under the MIT licence, that describes itself as "the agentic pentesting environment that lives on your machine." The version we read is 0.0.6, tagged on 1 November 2026. It is a workbench, not an autonomous hacker: you bring the AI agent command-line tools, it gives them a shared engagement workspace, 33 bundled security tool wrappers and an embedded browser. It has no cloud service and no account.

What it is not: it is not a model (it ships none), not a hosted service, not a vulnerability scanner of its own (it wraps tools you install separately), and not a hard scope firewall. It is also very new software at version 0.0.x.

Who this is for: pentesters and bug bounty hunters weighing it up, and CISOs and security leads who need to know what happens when their testers (or contractors) run agents on a laptop.

Based on the project's README, SECURITY.md, CONTRIBUTING.md, install scripts and source at tag v0.0.6, read on 2 November 2026. PlayCISO is not affiliated with the project. We did not run the app, and this post gives no exploitation steps.

What Executioner does

The README's pitch is that most of a pentest is recon and note-taking, and that agents are good at running tools but bad at remembering what happened last session. So every engagement is a workspace, and every agent launched inside it can read and write the same scope, targets, findings and workflows. Here is what the project documents, checked against the code where we could:

• Agent teams that share notes. You launch Claude Code, Codex, Gemini, Cursor, OpenCode or Hermes into an engagement; each arrives briefed and connected to the engagement over a local MCP (Model Context Protocol) endpoint. One click starts a built-in team: Recon & Strike (recon, scanner, exploit and reporter sub-agents), Web AppSec (crawler, injection, authz, reporter) or Code Audit (mapper, auditor, reporter). The team feature is built on Claude Code's custom sub-agents. The team prompts include rules of engagement: touch only assets the operator has confirmed in scope, never run destructive or denial-of-service actions against a live target, and keep verbatim evidence.
• A browser agents can drive. An embedded browser opens beside the agent's terminal, isolated per engagement. The agent can read network traffic, rewrite requests, emulate a location, language or user agent, upload files and save screenshots as evidence. When it meets a CAPTCHA or an MFA prompt it can ask the operator and wait (the source has a browser_ask_operator tool for this).
• Scope from the programme page. You paste the scope text from a HackerOne or Bugcrowd page or a policy, and an AI pass turns it into include and exclude rules. Targets are judged against the rules, and the tree shows the verdict. Adding or editing a rule re-judges the whole tree.
• Visual workflows. A canvas of triggers (manual, schedule, on new target), logic (if, loop, merge, stop), tool nodes, AI agent nodes, HTTP requests, screenshots, GeoIP, Shodan, Censys, notifications and Python scripts. You can run them by hand, on a schedule or whenever a new target appears, and step through node by node. An assistant drafts a workflow from a plain-language request for you to review before it reaches the canvas.
• Findings and evidence. Agents, workflows and people write to one findings list. The source models severities from critical to info and statuses open, confirmed, false positive, discarded and fixed. Export writes a Markdown report into the engagement's reports folder. The code comments call it "a working document, not a submission", so expect to edit it before sending anything to a client or programme.
• 33 tools with forms. We counted 33 TOML manifests in the repository, matching the README. Each tool gets a form and a preview of the exact command, then runs locally, over SSH or in a Docker container, and the output is parsed into targets. Users can add tools by contributing a manifest, and custom nodes in Settings.
• Everything else. A command palette (the README shows the Command and K shortcut), a floating scratchpad, a built-in source-control panel for the engagement folder, and a notice and one-click updater that checks GitHub for a newer release.

Where it runs, and who it works with

Executioner is an Electron desktop app. The README lists macOS (Apple silicon and Intel), Windows and Linux, and the installers build for Linux x64, macOS arm64 and x64, and Windows x64. Source builds need Node 24 and pnpm 12. The README gives the project a "100% local" badge and says it has "no backend, so client data, credentials and exploit drafts stay on your disk." For integrations such as Shodan and Censys, API keys are stored locally and referenced by name in workflows.

It does not bundle a model or the security tools themselves. You install at least one agent CLI and the tools you plan to run, and Settings probes each tool and shows an install hint when one is missing.

How it compares with systems we already cover

Our own classification, using the sourced rows in the pentest tools comparison (checked 28 October 2026) plus the Executioner facts above. The key difference: Strix, Shannon, PentAGI, PentestGPT, XBOW and CAI are built around an agent that tests; HexStrike gives an assistant a toolbox; Executioner supplies the workspace and leaves the agent to a CLI you choose.

Caveats carried over from our table: Strix has no published benchmark and open-ended LLM cost; Shannon's own README says never to run it against production; PentestGPT has opt-out telemetry; CAI is unmaintained with known prompt-injection issues that will not be fixed; HexStrike's headline metrics have no stated method. Executioner publishes no benchmark either, and the "Needs its own LLM key" cell for it is our reading of the design, not a project statement.

Why this matters for leaders: Executioner sits in the same family of tools that Google's threat intelligence team found criminals abusing at machine speed (see what GTIG found about ARTEX and PentAGI). GTIG does not mention Executioner. The point is that the legitimate and the abused versions of this software look alike on a network, which makes written authorisation and logging the real difference. Our primer on how these frameworks work and what to ask vendors covers the wider category.

What security leaders and testers should consider

1. "Local" does not mean "nothing leaves the machine"

Executioner has no backend of its own, which is a real privacy gain over a hosted pentest platform. But the README states that each agent CLI talks to its model provider under your account. Prompts, tool output, page text and screenshots an agent reads can travel to that provider. If your contract limits where client data may go, decide which agent and which provider are allowed, and whether a self-hosted model is required.

2. Scope is a signal, not a lock

In the code we read, a target gets an in, out or unknown verdict. Unknown, meaning no rule mentions the asset, is explicitly not refused, because the authors note that scope pastes are routinely incomplete. The browser tool descriptions say out-of-scope pages are "reported, not blocked". The HTTP request workflow node refuses an explicit exclusion. We did not find a scope check on the run_command tool that agents use to run shell commands, or on manual tool runs. The built-in team prompts tell agents to stay in scope, but a prompt is a request to a model, not a control. Keep your rules current, treat "unknown" as stop-and-check, and add network-level controls where the contract demands a hard boundary.

3. Agents drive real tools

The project's own MCP tool list classes run_command as dangerous. It runs a shell command on the local machine or a chosen SSH or Docker backend, with a default hard timeout of 120 seconds. The built-in rules say not to run destructive or denial-of-service actions, but that is again prompt-level. The README is clear that this is for authorised testing only, and CONTRIBUTING.md says contributions that exist to attack systems without permission will be closed. Require written authorisation, a defined rate limit and a named operator before anyone points it at a client or a programme.

4. Hostile input is a stated threat

SECURITY.md lists prompt injection that makes agents act outside their scope rules, running commands from imported workflows, crafted tool output and hostile web pages as in-scope threats. The source treats workflow-agent prompts as injectable: headless Claude, OpenCode, Codex and Gemini nodes launch in restricted modes, while Cursor and Hermes cannot be fully restricted and a node refuses them unless it opts in with an allow_unrestricted_cli setting. Do not import workflows or custom nodes from sources you do not trust, and remember that a target's own responses are untrusted text your agent will read.

5. The install path and the agents run under your identity

The documented install is curl ... | bash (PowerShell irm ... | iex on Windows). Both scripts download a release asset and check its SHA-256 against SHA256SUMS.txt from the same release. That guards against corruption but not against a compromised release or repository, as the checksum file sits beside the asset. The release workflow makes macOS and Windows signing optional, and we could not confirm whether the published v0.0.6 is signed. On macOS the script removes the quarantine flag so Gatekeeper will not block an unsigned build. The in-app updater re-runs the install script pinned to the new tag. Each agent CLI also runs under your account with your logins. For managed environments: inspect the script, pin a version with EXECUTIONER_VERSION, and test on a non-production machine first. Our how-to guide shows the safer sequence.

6. Secrets and evidence on disk

API keys for Shodan, Censys and similar are kept in a user-level SQLite file (~/.executioner/global.sqlite). The route's own comment says it returns the stored values to the UI, and we saw no encryption in the code we read, so treat that file like any other credential store: full-disk encryption, a locked screen, and no copying of the folder to a client without checking what is inside. Engagement folders hold client data and exploit drafts, so apply your normal data-handling rules to them.

7. It is version 0.0.x

SECURITY.md says only the latest release gets security fixes and promises a first response within 7 days via GitHub private vulnerability reporting. That is a sensible policy for a young project, but nothing we found shows an independent audit. Pilot it, do not standardise on it yet, and read the release notes on every update.

If you are writing an internal policy for agent-assisted testing, the Agent Tool-Scope and Least-Privilege Lab is a good way to practise deciding which tool grants an agent should and should not get. It is Pro, free to try with a free account.

What the project says about responsible use

The README's "Use it responsibly" section says Executioner is built for authorised security testing: bug bounty programmes, pentests with a signed scope, CTFs and your own infrastructure; to point it only at systems you have explicit permission to test; to keep scope rules up to date; and that "you are responsible for what you run." We have no evidence of misuse and nothing in the repository suggests it is designed for it, but, as with every tool in the table above, the same capability is dual-use.

Frequently asked questions

What is Executioner?

Executioner is an open-source desktop app, published on GitHub by the account dbx0 under the MIT licence, that the README calls "the agentic pentesting environment that lives on your machine". Each engagement is a workspace holding scope rules, targets, findings, workflows and evidence. You launch AI agent command-line tools such as Claude Code or Codex into it, run 33 bundled security tool wrappers, and the results land in one place. It has no cloud service and no account.

Is Executioner an autonomous AI hacker?

No. It supplies no model of its own. It launches agent CLIs you already have installed and signed in to (Claude Code, Codex, Gemini, Cursor, OpenCode or Hermes), briefs them on the engagement and gives them tools. You decide what runs. It is closer to a workbench that agents plug into than to a self-directing system such as the autonomous frameworks we compare it with below.

Is Executioner free and open source?

The source is published under the MIT licence (copyright 2026 dbx0) and the README describes no paid tier or hosted service. Running agents costs whatever your own agent CLI accounts and model provider charge. Version 0.0.6 was tagged on 1 November 2026, so treat it as early-stage software.

Does Executioner send my client data to the cloud?

Executioner itself has no backend, per its README, and we found no analytics or telemetry library in its code. But the README is explicit that network traffic comes from two places: your tools and the built-in browser talking to targets, and each agent CLI talking to its own model provider under your account. Anything an agent reads, including tool output and page content, may therefore reach that provider. Check your engagement contract before using it on client work.

Does it stop agents testing out-of-scope targets?

Not as a hard block, in the code we read. Every target gets an in, out or unknown verdict against your scope rules, and the built-in team prompts tell agents to touch only confirmed in-scope assets. But the tool descriptions say the browser reports scope "without blocking", an asset no rule mentions is "unknown" rather than refused, and the one place we found a hard refusal is the HTTP request workflow node, which refuses an explicit exclusion. Treat scope as a decision aid and keep your own authorisation and controls.

Which AI agents does Executioner support?

Claude Code, Codex, Gemini, Cursor, OpenCode and Hermes. You pick a default in onboarding and can switch per session. The built-in agent-team rosters (Recon & Strike, Web AppSec, Code Audit) are built on Claude Code sub-agents, per the engine source and the README's "Claude agent teams".

Which tools does it include?

The repository ships 33 tool manifests: Amass, dig, dnsx, Subfinder, theHarvester, wafw00f and WHOIS for recon; Dalfox, Feroxbuster, ffuf, GAU, Gobuster, Gowitness, httpx, Katana, Nikto, sqlmap, WhatWeb and WPScan for web; Masscan, Naabu, Nmap, Nuclei and RustScan for scanning; and Enum4linux, Hydra, MTR, Nbtscan, NetExec, Searchsploit, SSLScan, testssl.sh and Traceroute for network work. These are wrappers: you install the underlying tools yourself, and Settings shows which are missing.

Where do tools and agents run?

On your machine, on a remote host over SSH, or inside a Docker container such as Kali or Parrot, per the README. Onboarding lets you pick Local, SSH or Docker as the default and tests an SSH or Docker connection before saving it.

Is it safe to install with curl piped to bash?

It is the project's documented install method, and the script checks the download against SHA256SUMS.txt from the same release. That catches a corrupted download, not a compromised release, because the checksums come from the same place as the file. Read install.sh before piping it, or download the release asset yourself. Our guide shows both.

Is Executioner legal to use?

The software is. Using it against systems is legal only with permission. The README says it is built for authorised testing (bug bounty programmes, pentests with a signed scope, CTFs and your own infrastructure) and that you are responsible for what you run. Get written authorisation first.

Sources

• dbx0/executioner on GitHub (repository, tag v0.0.6, 1 November 2026)
• Executioner README
• Executioner SECURITY.md
• Executioner CONTRIBUTING.md
• install.sh (Linux and macOS) and install.ps1 (Windows)
• MIT licence text
• Executioner releases (not checked by us)
• Comparison rows: PlayCISO's pentest tools table, which cites each project's own repository or site.