In brief: CyberStrikeAI is an open-source, Go-based platform that combines AI agents, security tools, MCP servers, human approvals, and audit trails in one web application. As of this review on 2026-08-20, it is best suited to teams doing authorized security testing who want a governed workspace with evidence and replay, not to buyers expecting a finished product. Treat it as a capable but young platform: review the maintainers’ security model and hardening guide, replace the default self-signed certificate and one-time admin password, configure AI channels and tool permissions, and plan for regular upgrades that require backups and release-note review.

Key facts at a glance

What CyberStrikeAI is

The maintainers describe CyberStrikeAI in the README as a system that connects planning, execution, human oversight, evidence, and replay in one auditable workspace. Built in Go, it combines Eino-powered agents, MCP-native tools, RAG knowledge, visual workflows, and attack-chain modeling and analysis for authorized security operations.

The repository documents four layers that matter for an operator:

• Agent orchestration. Eino-based single-agent execution plus Deep, Plan-Execute, and Supervisor multi-agent modes; graph workflows that chain agents, tools, conditions, and approvals; and role-based configurations for common security scenarios.
• Tools and knowledge. More than 100 curated YAML tool recipes spanning network scanning, web testing, API security, cloud and container checks, forensics, exploitation, and post-exploitation, plus MCP integration over HTTP, stdio, SSE, and external federation. A knowledge base adds query rewriting, vector retrieval, reranking, and post-processing, and vision analysis runs through a separate model.
• Governance and audit. Human-in-the-loop approvals, tool allowlists, audit-agent review, platform RBAC with custom roles, audit logs, SQLite persistence, and capped tool results so the agent and operator see the same output.
• Security operations. Projects and attack chains with risk scoring and step-by-step replay, asset and vulnerability management, batch tasks, and chatbot connectors for WeChat, WeCom, DingTalk, Lark, Telegram, Slack, Discord, and QQ Bot. WebShell management and a built-in C2 are included but explicitly marked high-risk and authorized-use-only.

Who should consider it

Teams that run authorized penetration tests, red-team exercises, or CTFs and want an AI-assisted layer with approvals and evidence are the natural fit. The web console, project and attack-chain views, RBAC, and audit logging give operators something closer to a managed engagement workspace than a raw script runner.

Be honest about fit before adopting it. If you need a stable tool for Windows-first workflows, this is a risk: a user reported that tool execution fails on Windows because the platform looks for /bin/sh (issue #240), and another reported a run.sh virtual-environment failure under WSL Kali (issue #234). If you need predictable long-running conversations today, the open issues include memory and interruption problems in single conversations (#121) and page freezes with two concurrent conversations on an 8-core, 16 GB Docker host (#228). Those are signals to test your own workloads before committing, not proof that every deployment fails.

Release and maintenance signals

The project is young and active. The repository was created in November 2025, and releases were frequent in the week of this review: v1.7.12 on 2026-08-06, v1.7.13 and v1.7.14 on 2026-08-14, v1.7.15 on 2026-08-18, and v1.7.16 on 2026-08-19. At review time the repository showed 5,826 stars, 930 forks, and 51 open issues.

Two releases matter for operators. v1.7.14 moved the Eino runtime onto the 0.9.x Agentic Runtime path, with single- and multi-agent flows rebuilt around typed agents, checkpoints, summarization, retry/failover, and observability. v1.7.16 fixed a bug where long conversations in Eino single-agent mode could trigger a 400 error after summarization truncated history and broke the tool_call/tool_result pairing; maintainers added reconciler and pruner middleware as defense in depth.

That cadence is double-edged. It means bugs get patched quickly, but it also means each upgrade is a change to review rather than a routine patch. The README’s own upgrade instructions say to review target release notes for configuration, database, and API changes and that backups are required even for patch upgrades. A version number alone is not a compatibility guarantee.

Deployment concerns

The README’s quick start assumes Go 1.25+ and Python 3.10+, then a run.sh script that checks the environment, creates a Python virtual environment, installs dependencies, builds, and starts the server. Out of the box, the server uses HTTPS with a locally generated self-signed certificate and prints a one-time admin password; the README tells you to change it immediately. Before first real use you must configure an AI channel with provider, base URL, API key, model, and token limits.

For anything beyond localhost, the maintainers point to a security hardening guide and production TLS settings in config.yaml. The default host binding is 127.0.0.1, credentials are expected from environment variables rather than committed config, and the README explicitly warns against exposing the service without hardening. The platform also orchestrates external security tools installed on the host; the README notes that missing tools are skipped or substituted at runtime, which means scan coverage depends on your environment, not just the code.

Upgrades have a purpose-built path: upgrade.sh backs up config.yaml and data, preserves local tools, roles, and skills, pulls the release, and restarts, with a .upgrade-backup restore point. The README recommends curl or wget and rsync, and suggests a GitHub token if the API rate-limits the download. That is more upgrade tooling than most projects this age ship, but it does not remove the need for your own backup and rollback test.

What to check before production

If you take this beyond a lab, verify at least the following against your own environment:

• Authorization and scope. The project is for educational and authorized testing only. Confirm written authorization for every target and legal review before any real engagement.
• Security model and hardening. Read the maintainers’ security model and hardening guide before enabling high-risk tools, WebShell, or C2; those capabilities should be off or contained unless an engagement genuinely needs them.
• TLS and host binding. Replace the self-signed certificate, set production certificate paths, and confirm who can reach the service.
• Credentials and RBAC. Change the initial admin password, create least-privilege users, and keep AI API keys in environment variables rather than git-tracked config.
• Approvals and output caps. Test approval modes, tool allowlists, and the capped tool-result behavior before letting agents run autonomously.
• Data and backups. SQLite persistence means you should plan retention, backups, and a tested restore path, including for evidence records.
• Toolchain. Verify Go and Python versions, install the external tools you actually need, and account for tools that are skipped when missing.
• Platform and load. Test Windows or WSL only if you must support them (issues #240 and #234 suggest problems), and stress concurrent conversations before relying on them (issue #228 reports freezes at two active sessions on modest hardware).
• Upgrade rehearsal. Run upgrade.sh in a staging clone first, review release notes for config or database changes, and practice restoring from .upgrade-backup.

Limitations and honest caveats

Use CyberStrikeAI only on systems you own or are explicitly authorized to test. That warning comes from the maintainers’ README.

This is a source and documentation review, not a runtime evaluation; no local installation or benchmark evidence was attached to this review. Statements about features come from the README and release notes, and the stability signals come from open issues reported by users in specific environments and versions.

The platform is also dual-use. The same capabilities that make it useful for authorized testing, including WebShell management and a built-in C2, make it dangerous in the wrong hands, and the maintainers’ disclaimer is explicit about authorization and responsibility. Treat deployment as an infrastructure decision with security and compliance consequences.

Integration maturity varies. One open question asks whether the asset search API is hardcoded to a specific FOFA endpoint (#249), which is a reminder to validate provider integrations against your own accounts and contracts. Feature requests such as OpenAI Response API support (#37) and Kimi model compatibility (#167) show that model and provider coverage is still catching up with the ecosystem.

Evaluation questions before adopting it

Rather than comparing stars, compare the platform against your actual workflow:

• Do you need the web console, attack-chain views, RBAC, and audit trail, or would scripts plus MCP be enough?
• Can you host Linux, Go, and Python, or is Windows a hard requirement?
• Which AI providers does your organization allow, and do you have budget and keys for the token limits the platform asks you to configure?
• Can your team absorb a release cadence measured in days and review every upgrade, or do you need a pinned, maintained deployment?
• Will your targets and scope stay clearly authorized, and can your process survive evidence collected by an agent?

Verdict

CyberStrikeAI is a credible, actively maintained open-source option for teams that want AI agents in their authorized security testing workflow with human oversight and evidence. The project’s documentation, release discipline, and upgrade tooling stand out for a project created in late 2025. The honest caveat is maturity: 51 open issues, Windows gaps, concurrency reports, and fast-moving releases mean this is not a zero-maintenance platform. Plan for a staged evaluation on your own targets, hardening before exposure, and an ongoing upgrade and maintenance commitment.

If that evaluation sounds like work your team should not absorb alone, I can help with the concrete parts: standing up and hardening an instance, wiring AI channels and MCP integrations to your providers and tooling, defining approval and RBAC policies that match how your team works, and running upgrades with backup and rollback so the release cadence does not become downtime.

Sources

• CyberStrikeAI repository (README, configuration, and upgrade documentation)
• Release v1.7.16 (published 2026-08-19)
• Release v1.7.14 (Eino 0.9.x Agentic Runtime migration)
• Security hardening guide (documented in README)
• Issue #240: Windows exec tool failure (/bin/sh not found)
• Issue #228: multi-task page freeze with concurrent conversations
• Issue #178: duplicate vulnerabilities across sessions
• Issue #121: memory and interruption in a single conversation