CyberStrikeAI gives agents access to real security tools
CyberStrikeAI combines an agent chat, reusable workflows, asset and vulnerability records, a knowledge base, and connections to external tools. Its catalog names scanners, web testers, cloud checks, binary-analysis utilities, exploitation frameworks, password tools, and forensics programs. MCP servers can add more capabilities. The result is closer to an operations console than a chat assistant because the model can choose actions that touch hosts, files, accounts, and networks. That power is useful only inside a clearly authorized assessment.
The scope is large. Our checkout contained 982 files, roughly 221,305 source lines, and measured 24.4 MB. Beyond ordinary findings management, it includes WebShell sessions, file operations, an optional C2 subsystem, batch tasks, graph-based attack chains, chat integrations, and multiple agent modes. Each connection adds permissions and data paths. A team evaluating it should begin with read-only inventory on disposable targets, then enable one tool category at a time after checking command templates and audit output.
The project's own threat model assumes privileged operators
The security model says anyone who can sign in to the web interface should be treated as an operator of the instance. It lists password theft, prompt injection, malicious MCP servers, edited YAML tool definitions, C2 misuse, WebShell commands, and database leakage as threats. Human approval is a control, though the document warns that an approval screen may not reveal the effect of an encoded shell command or misleading external tool description. That is the correct mental model for this product.
The recommended baseline keeps access on an internal network, VPN, or trusted proxy; enables audit logging; assigns a strong password; authenticates HTTP MCP; and leaves C2 disabled unless required. The hardening guide also recommends a dedicated OS user, mode 600 for configuration, mode 700 for data, and a minimal global allowlist limited to read-oriented tools. Those controls matter more than the 101 MB Python environment we measured because a successful model prompt can still invoke a powerful local binary.
What happened when we ran it
Our fresh unprivileged Debian sandbox installed 86 Python packages in 34 seconds and used 101 MB on disk. The available build target completed in 6 seconds. Pip-audit reported 0 known vulnerabilities in the installed Python dependencies. Those results cover commit bf761e9 on 3 CPUs with 8 GB of RAM. They show that the measured dependency layer and build can complete cleanly without credentials in a restricted container.
No test script or target was available, so our harness skipped tests. The measured checkout also had no tests directory, no Dockerfile, and 0 CI workflow files. For a project with about 221,305 source lines and high-risk execution paths, that is a serious confidence gap. We did not run a port scanner, WebShell, C2 beacon, MCP server, or model-driven workflow, and the build result cannot substitute for those checks. A production reviewer needs executable coverage of authentication, authorization, approvals, audit records, and command boundaries.
One-command startup still needs Go, Python, and model credentials
The documented launcher checks Go 1.25 or newer and Python 3.10 or newer, creates a virtual environment, installs dependencies, downloads Go modules, builds the server, and starts it. The default uses HTTPS with a local self-signed certificate and prints a one-time admin password. A user then configures an OpenAI-compatible channel with its base URL, API key, model, and token limits. Production needs a trusted certificate or reverse proxy rather than training operators to accept warnings.
Security binaries are separate. The README tells users to install tools such as nmap, sqlmap, nuclei, subfinder, and hashcat as needed, and says missing tools may be skipped or substituted. Our 34-second package install did not provide that catalog. Every added tool has its own operating-system packages, privileges, output format, update cycle, and target-safety concerns. Pin versions and test the exact recipe instead of assuming a YAML name guarantees that a command exists or behaves as the agent expects.
Approval routing and external MCP need verification
CyberStrikeAI has human approval modes, allowlists, and an audit-agent reviewer. Issue 256 reports that in v1.7.14 the audit agent used the system-default AI channel even when the conversation selected another channel. The reporter says that could change the model, provider URL, credential, cost, and review behavior without matching what the interface displayed. The issue includes a proposed explanation, which the reporter labels as preliminary. Teams using multiple providers should verify actual routing in logs before trusting that separation.
External MCP servers widen the trust boundary. The project's guide asks whether each server can run commands, change files, send data elsewhere, authenticate clients, or return untrusted web content. It recommends isolation and keeping dangerous tools out of global allowlists. That advice is especially relevant when agents consume target-controlled pages: prompt injection can arrive through scan output, documentation, or a browser capture. Store only necessary customer data and remove stale sessions, uploads, payloads, and logs after an engagement.
Active releases do not replace acceptance testing
GitHub showed 5,991 stars and 55 combined open issues and pull requests when fetched. The last push was August 26, 2026, and v1.7.17 was released two days earlier. That release disabled automatic recovery of stale chat checkpoints that could repeat old responses and added per-turn token accounting. Current issue and pull-request activity covers Windows paths, WebShell connections, provider behavior, database concurrency, tool-name compatibility, and deployment requests. Maintenance is plainly active.
The decision still turns on control, not feature count. Our run produced a clean 6-second build and 0 Python audit findings, yet offered no tests for the dangerous paths. A mature internal security team can isolate the service, inspect its tool recipes, restrict targets, require human approval, and compare stored evidence with actual commands. Without those operators, CyberStrikeAI creates more authority than the organization can safely supervise. Start with the C2 subsystem off and keep it off unless a named engagement requires it.