CyberStrikeAI: a governed execution workspace for AI-assisted penetration testing

What CyberStrikeAI is for, and who should not use it

Most AI security tools stop at the prompt. You describe a target, the model emits commands, and you copy them into a terminal by hand. CyberStrikeAI takes the opposite position: the model's intent is executed inside a workspace that records who approved what, which tool ran, and what came back. The README frames this as one auditable workspace that connects planning, execution, human oversight, evidence and replay.

The intended user is a security team running authorized engagements, not a hobbyist probing random hosts. The README carries an explicit warning to use the project only on systems you own or are explicitly authorized to test, and it directs shared or production environments to docs/en-US/security-model.md and docs/en-US/security-hardening.md before high-risk tools, WebShell or C2 capabilities are enabled. That warning is part of the product design, not boilerplate: the same agent that reads your notes can also drive a WebShell.

If your work is a one-shot port scan, this is the wrong shape. The platform expects persistent state (SQLite), a running web console, configured model endpoints and MCP servers. The overhead only pays off when you need the trail afterward.

How the Eino agents, MCP tools and approval gates fit together

The architecture visible in the repository splits into four layers. At the top, Eino orchestration runs agents in single-agent mode or in Deep, Plan-Execute and Supervisor multi-agent modes. Below that, tools are defined as YAML recipes (the README says 100+ curated recipes) and exposed through MCP, with HTTP, stdio, SSE, external federation and dynamic discovery supported.

Between the agent and the tool sits the governance layer. Human in the loop provides approval modes, tool allowlists and audit-agent review. Tool call blocking adds configurable regex checks before MCP execution, with reminder templates and dry runs, and government-domain protection enabled by default. Tool calls run in workers with bounded agent waits, so a blocking MCP call does not hang the conversation; results are polled by execution_id and can be cancelled. Per-server circuit breakers and concurrency limits cap the blast radius of a misbehaving server.

State lives in SQLite. Projects and attack chains connect cross-session facts, add risk scoring and graph views, and support step-by-step replay. The knowledge base adds query rewriting, vector retrieval, reranking and post-processing, and vision analysis routes screenshots and captchas to a separate vision model while keeping only text summaries. The Go module list confirms the dependency shape: cloudwego/eino, eino-ext model and document components, modelcontextprotocol/go-sdk, gin, mattn/go-sqlite3 and OpenTelemetry tracing.

Installing CyberStrikeAI and running a first governed task

The repository ships run.sh at the top level, and the README's "Start here" link points to a section titled Quick start (one-command deployment). The Go module declares go 1.25.0, so the build expects a matching toolchain. If module downloads time out, go.mod itself carries the workaround comment: set the proxy with go env -w GOPROXY=https://goproxy.cn,direct, or use scripts/bootstrap-go.sh.

Start the platform with the bundled script:

./run.sh

After it comes up, open the web console in a browser and sign in. The README describes authenticated access and audit logs, so the first screen you should expect is a login, not an anonymous dashboard.

The Python helpers are separate from the Go binary. Tool recipes such as api-fuzzer, dnslog, http-intruder and http-framework-test reference packages listed in requirements.txt, so install them into the environment the tools will run in:

pip install -r requirements.txt

That file pins requests>=2.32.3, httpx[http2]>=0.27.0, arjun>=2.2.0, uro>=1.0.2, bloodhound>=1.6.1, impacket>=0.11.0 and mcp>=1.0.0. Note that angr and pwntools are present but commented out, so recipes depending on them need manual installation.

Before pointing agents at anything, copy config.example.yaml to your working config and review it. The README and docs list the settings that matter most: the model endpoints used by the Eino components, the MCP servers and their transports, and the tool call blocking rules. Government-domain protection is enabled by default, which means a first dry run against a .gov host will be blocked until you change that policy deliberately.

Upgrades use the script at the repository root:

./upgrade.sh

The README does not document rollback for that script, so treat the SQLite database and config as the things to back up before running it.

Where the governance model costs you

The approval layer is the feature and the friction. Every tool call that policy flags has to be approved, and the README describes approval modes, allowlists and audit-agent review as separate mechanisms. On a long engagement with hundreds of tool invocations, that is real operator time. Teams that expect an autonomous agent to sweep a network unattended will find the defaults working against them, especially with government-domain protection on.

The result governance documentation points at a second constraint: the platform stores the same capped tool result the agent saw, protects resume paths from oversized historical output, and adds UI safeguards for large detail views. In other words, output is truncated by design. If your workflow depends on the full raw output of a noisy scanner, the capped copy is what the agent reasons over, and the governance doc is the place to understand what was cut.

Tool recipes are YAML, and the README says custom extensions are supported with role-scoped access. That is a maintenance surface. Each recipe you add is another thing to review when a tool changes its flags, and nothing in the repository suggests recipes are versioned against upstream tool releases.

Finally, the platform is not a scanner. It orchestrates scanners. If no MCP server or recipe covers your target class, the agent has nothing to call, and you are back to writing the integration yourself.

CyberStrikeAI compared with PentAGI

PentAGI is the comparison people search for, and the two projects sit on different sides of the same problem. PentAGI is built around autonomous agent execution in a containerized environment: you give it a goal, and the agent works through it with its own tooling. CyberStrikeAI keeps the agent but inserts a governance layer between intent and execution, with approval modes, tool allowlists, regex call blocking and dry runs before MCP execution.

The practical difference shows up in the audit trail. CyberStrikeAI stores projects and attack chains that connect cross-session facts with risk scoring, graph views and step-by-step replay, and it persists everything in SQLite alongside audit logs. That is a workspace for teams that have to explain their actions later. PentAGI's emphasis, as its own documentation describes it, is autonomous execution rather than per-call review.

Neither choice is free. CyberStrikeAI asks you to configure models, MCP servers, roles and policies before the first useful run, and to keep a Go 1.25.0 build plus a Python environment in working order. A team that just wants an agent to try things will find that setup heavy.

Licence, maintenance and the cost of staying current

CyberStrikeAI is Apache-2.0, which permits commercial use and modification provided you keep the licence and notices, and it includes an explicit patent grant. The repository also carries a SECURITY.md, so vulnerability reports have a documented route rather than an issue tracker free-for-all. For a tool that ships WebShell and C2 capabilities, that file is worth reading before deployment. Nothing here is legal advice; if you redistribute a modified build, have counsel review the notice requirements.

Maintenance looks current: the last push was on 2026-09-08, the same day as release v1.7.18, with v1.7.17 on 2026-08-24 and v1.7.16 on 2026-08-19. The repository is not archived. Those dates tell you the project is moving, not that it is stable; three releases in three weeks is a fast cadence, and fast cadences mean your config and recipes can drift.

The upgrade cost is concentrated in three places. The Go toolchain tracks go 1.25.0 and the Eino dependencies carry pseudo-versions dated 2026-04-27, so a Go version bump can ripple through the build. The Python side is pinned loosely (>= constraints in requirements.txt), so a fresh pip install can pull newer versions than the last tested set. And your own YAML tool recipes and MCP server definitions are not covered by the project's release notes at all.

Editorial conclusion

Adopt CyberStrikeAI if you run authorized engagements and need approvals, audit logs and replayable attack chains around AI-driven tool calls; the README points to docs/en-US/security-model.md and docs/en-US/security-hardening.md before you turn on high-risk tools, WebShell or C2. Skip it if you want a single-binary scanner with no human-in-the-loop overhead, or if you cannot keep a Go 1.25.0 toolchain and the Python requirements.txt packages available. Verify first that your model endpoints satisfy the Eino model components in go.mod, that your MCP servers match the HTTP, stdio or SSE transports the platform supports, and that your authorization paperwork covers every target the agents can reach.

Frequently asked questions

Official sources

1. AIPentest/CyberStrikeAI on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases