MCP server that lets AI agents autonomously run 150+ security tools
github.com/0x4m4/hexstrike-ai · 2026-10-03 · d689933
Defense-in-depth score
0.9 / 10
The HTTP API server has no authorization, approval step, or sandbox in front of a generic shell-execution endpoint, and its default network exposure and authentication are not locked down. Any client driving the MCP bridge runs commands with the full authority of the server's OS user. Tool argument handling is not strict either, and the only bounds are a 5-minute per-command timeout and a log file. It should only run in a disposable, network-isolated VM.
HexStrike AI ships no authentication, approval step, sandbox or tool selection of its own, and its only built-in bounds are a 5-minute per-command timeout and a log file. The safest setup builds every boundary around it: a disposable, network-isolated VM, a low-privilege account and per-call approval in your MCP host.
| Setup | How | What it gives you |
|---|---|---|
| A dedicated low-privilege account | Run the server as its own OS user that holds no keys, tokens or files beyond what the engagement needs | Every command and subprocess reaches only that account's files and environment, not yours C1 |
| A firewalled API port | Use a host firewall so only the MCP bridge on the same machine can reach the API port | Only your own MCP host can drive the server C1 |
| Per-call approval in the host | Keep the sample MCP config's alwaysAllow list empty so your host asks before each tool call | A person sees each tool call and its arguments before it runs C2 |
| The per-command timeout | Keep the built-in COMMAND_TIMEOUT of 300 seconds | Each command on the main executor ends after five minutes C10 |
| A disposable, isolated VM | Run both processes in a throwaway VM with no host mounts and egress limited to the in-scope targets | An outer boundary around every command, script and package, and a narrow path for data to leave C4 |
| A fresh snapshot per engagement | Revert the VM to a clean snapshot after each engagement | Files, cached results and installed packages from one session never carry into the next C6 |
| A log kept off the VM | Ship hexstrike.log to storage outside the VM as it is written | A record of every command that the tools themselves can't alter or delete C9 |
| A whole-VM stop | Halt runaway work by stopping the VM or the server's whole process tree | Child processes that outlive the timeout end too C10 |
SafetyCard
hexstrike.log and the console keep every command line and its output unredacted, credentials included; store them like the engagement data.--debug off where its output is shared, since it logs complete request bodies.0.00 / 1.00
The API server holds no identity of its own: every command runs as the OS user who started it, with that user's whole environment. There is no per-request authorization anywhere in the code, and the server's default network exposure and authentication are not locked down. A hijacked agent therefore has the operator's full authority. The project's README only suggests adding authentication.
0.00 / 1.00
The bridge exposes 151 tools and none carries a read-only or destructive hint; the most dangerous one is a documented arbitrary-command tool. The server has no confirmation step, no dry-run, and no read-only mode, so every call executes immediately and approval depends wholly on the host. The shipped sample config only has an empty always-allow list, which is a host setting rather than a server control.
0.00 / 1.00
Tool argument handling is not strict, and there are no schema constraints or scope allowlist. Checks are limited to 'field is present'. The generic command endpoint, a Python-script execution endpoint, a package-install endpoint, and a file API are all on by default with no way to select a narrower tool set.
0.00 / 1.00
Every command runs as a same-user child of the API process through a shell, with the full inherited environment and no container, namespace, or user separation. The only boundary is the host itself. The optional headless browser tool is launched with its own sandbox and web-security protections switched off.
0.07 / 1.00
Tool output, including content fetched from scan targets and third-party responses, returns to the model as plain stdout/stderr strings with no provenance flag or untrusted marker. The same session can both read that content and run any command, reach the network, and delete files, with no human step. A hijacked session can therefore leak data and take irreversible actions unattended.
0.15 / 1.00
No agent memory or auto-loaded instruction files exist. The server does keep global state that persists outside any session: an in-memory command-result cache keyed by command string, a shared file store under a temp directory, and persistent Python virtual environments. These stores are not partitioned per caller, and any client can write, delete, and execute their contents. Nothing from them is automatically re-injected into model context, and no workspace file is loaded as configuration.
0.00 / 1.00
The server exposes an endpoint that installs any named Python package into a persistent virtual environment on request, and a companion endpoint that runs caller-supplied Python scripts in it. Installation is unpinned, unverified, and needs no consent, and package install steps run code with the server user's authority and full environment. The roughly 150 external security binaries are installed separately by the operator and are not fetched by the server.
0.00 / 1.00
Tools take credentials such as passwords and API keys as ordinary arguments and splice them into command lines. Every command line and all its output are written at info level to the console and to a log file with no redaction. Every subprocess inherits the server's full environment. The debug mode of the client also logs complete request bodies. No secret handling or masking code exists, and the log file is created in the working directory.
0.20 / 1.00
Commands, their output, and timings are written as free-text lines to the console and to hexstrike.log, which gives a basic trail for the main execution path. Records are unstructured, carry no caller identity, approver, or correlation ID, and some direct subprocess calls in analysis helpers do not log their argument vectors. The log file sits in the working directory, where the same command endpoint can alter or delete it, and if the file cannot be opened the server silently continues with console-only logging.
0.45 / 1.00
Each command run through the main executor has a fixed 5-minute timeout, the file API caps file size, and the async pool is capped at 32 workers. There is no rate limit, no cap on concurrent requests, no output-size cap, and no overall budget. The timeout terminates only the shell process because commands are not started in their own process group, so child processes can outlive both the timeout and the terminate endpoint. A runaway caller can issue unlimited consecutive commands.