CyberStrikeAI: A Go Platform That Puts Approval Gates Around Agent-Driven Pentests
The system of action for AI-native cybersecurity—where intent becomes governed execution, evidence becomes operational memory, and every operation improves the next.
At a glance
- What is it?
- CyberStrikeAI is an Apache-2.0, Go-based workspace that turns natural-language security intent into auditable tool calls via Eino agents and MCP. Its real distinguishing feature is governance: call blocking, human approval, and capped evidence retention, not just autonomous execution.
- Who is it for?
- Adopt CyberStrikeAI if you run authorized engagements and need every agent action to pass through approval modes, tool allowlists, and a regex call-blocking layer before an MCP tool fires. Do not adopt it as a general-purpose agent framework or on systems you cannot legally test; the README itself restricts use to owned or explicitly authorized targets and points at its security model and hardening guide for shared environments.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap CyberStrikeAI targets: agents that act without a paper trail
Most agent frameworks stop at orchestration. They plan, call a tool, and return text. For security work that is the wrong shape, because the interesting question is not whether the agent can run a scan but who authorized it, what arguments it sent, and what came back. CyberStrikeAI is built around that question. The README describes it as connecting planning, execution, human oversight, evidence, and replay in one auditable workspace, and the feature list backs the claim with concrete parts: approval modes, tool allowlists, audit-agent review, and a call-blocking layer under Security that runs configurable regex checks before MCP execution. The intended user is a security team running authorized engagements who wants agent speed without losing the chain of custody. It is explicitly not a general automation tool. The README carries an important notice that it should be used only on systems you own or are explicitly authorized to test.
Eino orchestration, MCP tools, and the execution_id polling loop
The architecture has three visible layers. At the top, Eino orchestration runs single-agent execution plus Deep, Plan-Execute, and Supervisor multi-agent modes, and graph workflows chain Agents, tools, conditions, approvals, and outputs into reusable flows. In the middle, tools arrive through MCP over HTTP, stdio, SSE, or external federation, with dynamic tool discovery and more than 100 curated YAML recipes that can be extended and scoped per role. At the bottom, execution is deliberately boring: blocking MCP and tool calls run in workers with bounded agent waits, and the agent polls a resumable execution_id instead of holding a connection open. The README also lists per-server circuit breakers, concurrency limits, cancellation, and unified output caps. That combination is the part worth noting. Long-running scans do not stall the agent loop, a dead MCP server trips its breaker instead of hanging every caller, and result governance stores the same capped tool result the agent saw, which keeps resume paths from being poisoned by oversized historical output.
Getting it running and the config surfaces you will actually touch
The README points to a Quick start section titled one-command deployment, but the cleaned text does not include the command itself, so treat any specific invocation as something to confirm in docs/en-US/README.md rather than something quoted here. What the material does name is the configuration surface. Tool call blocking lives under Security and takes configurable regex checks, reminder templates, and a dry-run mode, with government-domain protection enabled by default; the reference is docs/en-US/tool-call-guard.md. Result capping and resume-path protection are described in docs/en-US/tool-execution-governance.md. Asset normalization, deduplication, XLSX and CSV import and export, saved views, and duplicate merging are covered in the asset management guide. Persistence is SQLite, and access is authenticated with platform RBAC across multiple users, system and custom roles, scoped permissions, and explicit assignments. Before enabling high-risk tools, WebShell, or C2 capabilities, the README directs you to the security model and hardening guide. That ordering is not decorative; the dry-run mode on call blocking exists so you can see which regex rules would fire before you let them block live traffic.
Where it will fight you: coupling, defaults, and the wrong-fit cases
The governance layer is also the heaviest part of the system. Approval modes, audit-agent review, allowlists, and regex blocking all sit between intent and execution, which means an agent that would have run a tool in one step may instead wait on a human decision. On a time-boxed CTF or a lab where you are the only operator, that overhead buys you little. The government-domain protection default is another sharp edge: it is on by default, and a rule set you did not write can block a legitimate call during an engagement against a government-adjacent target until you tune it. The breadth of the platform is a cost too. Vulnerability management, asset management, WebShell management, batch tasks, chatbots for WeChat, WeCom, DingTalk, Lark, Telegram, Slack, Discord, and QQ Bot, plus a Burp Suite plugin, all ship in one Go binary backed by SQLite. Teams that only want agent orchestration inherit the rest. And because the README is the only material available here, there is no published guidance on how the SQLite store behaves under concurrent multi-user load, which is a real question for a shared deployment.
How this differs from wiring an agent framework to a scanner
The obvious alternative is assembling the same capability from a general agent framework plus a scanner and a ticketing system. The difference is where the control point sits. In a hand-built stack, the agent calls the scanner directly and you reconstruct what happened from logs afterward. CyberStrikeAI inverts that: the MCP call is the governed boundary, regex checks run before execution, approval modes and allowlists decide whether the call proceeds, and the capped result is stored as the same artifact the agent consumed. That last detail matters for replay. Attack-chain modeling connects cross-session facts with risk scoring, graph views, and step-by-step replay, so the evidence is not a separate export you reconcile later. The trade-off is that you are adopting a platform with opinions about assets, vulnerabilities, and users, not a library you embed. If your workflow already lives in another system of record, that duplication is the cost of the governance model.
Maintenance cost and what Apache-2.0 leaves you to decide
Release cadence is visible in the tags: v1.7.16, v1.7.17, and v1.7.18 landed within roughly three weeks of each other, with the most recent push on 2026-09-08. A cadence that tight on a platform this broad means upgrade work is not a one-time task. The governance docs are versioned files in the repository (tool-call-guard.md, tool-execution-governance.md, security-model.md, security-hardening.md), so a rule change can arrive with a release and alter which calls your regex layer blocks. Pin a version and read the diff on those four files before moving. On licensing, Apache-2.0 permits commercial and closed-source use and includes an explicit patent grant, but it also carries a patent termination clause and requires you to preserve notices and state changes. It does not grant trademark rights. That is a summary of the licence text, not legal advice; route anything unusual through counsel. The README's own restriction, use only on systems you own or are explicitly authorized to test, sits on top of the licence and is a usage condition, not a permission the licence grants.
Editorial conclusion
Adopt CyberStrikeAI if you run authorized engagements and need every agent action to pass through approval modes, tool allowlists, and a regex call-blocking layer before an MCP tool fires. Do not adopt it as a general-purpose agent framework or on systems you cannot legally test; the README itself restricts use to owned or explicitly authorized targets and points at its security model and hardening guide for shared environments. Before enabling WebShell or C2 capabilities, read docs/en-US/security-model.md and docs/en-US/security-hardening.md and confirm which tools the government-domain protection default actually blocks in your deployment.
Community notes