CyberStrike: an AI offensive security harness you drive from the terminal
Open-source AI-powered offensive security harness for automated penetration testing.
At a glance
- What is it?
- CyberStrike wraps frontier LLMs in an offensive security layer with 13+ agents, 7,600+ skills and 120+ OWASP test cases. Here is what the repository actually documents, how to get it running, and where it stops being the right tool.
- Who is it for?
- Adopt CyberStrike if you already hold an LLM subscription and want an agent that sequences recon, exploitation and reporting against targets you are authorised to test; the npm install is one line and the first-run prompt walks you through provider setup. Do not adopt it if you need a signed, audited commercial platform, if your engagement rules forbid sending target data to a third-party model, or if you expect the agent to decide scope for you.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, 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
What CyberStrike is and which pentester it fits
CyberStrike is a TypeScript project that turns a general-purpose LLM into a red team agent. The README describes it as an open-source AI agent built for offensive security, and the workflow it targets is the one a human pentester already runs: reconnaissance, vulnerability discovery, exploitation, reporting. What the project adds is orchestration. Instead of prompting a model by hand and pasting tool output back into the chat, you give CyberStrike a target and it chains the tools itself.
The audience is narrower than the topic list suggests. The README assumes you have an LLM subscription or API key, a terminal, and a target you are allowed to test. It is aimed at penetration testers, bug bounty hunters and CTF players who want to script the repetitive parts of an engagement. It is not a scanner you point at a hostname and forget, and it is not a substitute for a human deciding what is in scope. The project ships 56+ built-in tools and 176+ MCP tools according to the README, which is a lot of capability to hand to an autonomous loop; the operator still owns the authorisation.
The intelligence layer: how a generic model becomes a security agent
The mechanism the README describes is context injection rather than fine-tuning. When you connect a provider, CyberStrike injects domain-specific context into every interaction: OWASP testing methodology, vulnerability patterns, attack chain reasoning, and tool orchestration logic. The model does not need prior security knowledge because the harness supplies it per request. That is the central design choice, and it explains why the project advertises 150+ providers and 5,300+ models: none of them are modified.
Four named components sit in that layer. Schema normalization forces structured output from providers that format responses differently. A context guard is described as preventing prompt leakage and keeping the agent on the current test phase. Provider auto-detection identifies the endpoint and picks a transport. Tool orchestration chains security tools based on findings rather than a fixed script.
The trade-off is worth stating plainly. Because the security knowledge lives in injected context, the quality of a run depends on the model's instruction-following and on how much of that context fits in the window. A cheaper or smaller model will still receive the methodology, but the README's own provider table marks Anthropic Claude as best performance with extended thinking, which suggests the harness is tuned for frontier models. The provider list is wide; the tuning is not equally deep across it.
Installing CyberStrike and running a first engagement
The README gives a single global install command. It pulls the package from npm and starts the binary in one line:
npm i -g @cyberstrike-io/cyberstrike@latest && cyberstrikeOn first run the README states that CyberStrike launches a TUI, asks for your LLM provider and API key, and stores that configuration. You should see the provider prompt before any target is touched. If you already pay for Claude Code or an OpenAI subscription, the README says the intelligence layer sits on top of that existing plan rather than requiring separate API billing, so the subscription is the credential you supply at the prompt.
The repository is a Bun workspace, so contributors work from source rather than the published package. The root package.json defines the development entry point and pins the package manager:
{
"packageManager": "bun@1.3.9",
"scripts": {
"dev": "bun run --cwd packages/cyberstrike --conditions=browser src/index.ts",
"dev:web": "bun --cwd packages/app dev",
"typecheck": "bun turbo typecheck"
}
}Note the test script: it prints "do not run tests from root" and exits with status 1. Tests are expected to run per package, not from the repository root, and anyone setting up CI should read that before wiring a pipeline. The workspace list includes packages/app, packages/sdk/js, packages/slack and packages/hackbrowser, so the terminal TUI is one front end among several rather than the whole product. There is also a flake.nix and a nix/ directory for Nix users, and an install script at the repository root. The README does not document a Windows-specific path, so treat the npm route as the documented one and check docs.cyberstrike.io for anything platform-specific.
Agents, skills and OWASP coverage: what the numbers mean in practice
The README advertises 13+ specialized agents, 7,600+ security skills and 120+ OWASP test cases. Those are catalogue sizes, not guarantees. A skill in this context is a packaged instruction set the agent can invoke; the value depends on whether the relevant skill fires for the target in front of you, which is a property of the orchestration logic and the model's tool selection rather than of the count.
The OWASP test cases are the part with an external reference point. 120+ cases mapped to OWASP testing categories means the harness has a checklist to work against, which is useful for coverage reporting on a web application assessment. It is less useful on targets that do not resemble a web app. The README also describes a post-exploitation section and a Bolt feature for remote tool execution, both of which extend the agent beyond the initial scan phase. Bolt in particular is a design decision worth pausing on: remote tool execution means the agent can act on hosts other than the one you launched it from, and the README's own framing of the intelligence layer as preventing prompt leakage suggests the authors treat prompt injection as a live risk in that path.
Where CyberStrike is the wrong tool
The clearest limitation is that CyberStrike sends target-derived data to an LLM provider. The README's own pitch is that you plug in a Claude, GPT or other subscription and let the harness reason over findings. For an engagement where client data cannot leave your infrastructure, that is disqualifying unless you run a self-hosted model endpoint that the provider list accepts. The README does not document a data-residency guarantee, and the presence of Google Vertex AI regional endpoints and Mistral's European data residency in the provider table is a property of those providers, not of CyberStrike.
Second, autonomy is a liability on scoped engagements. An agent that chains tools based on findings will follow the chain wherever it leads, and the README does not describe a scope-enforcement mechanism that stops it at a hostname boundary. The context guard is described as keeping the agent focused on the current test phase, which is about task drift, not authorisation.
Third, the repository is a monorepo with a Bun toolchain and a deliberately blocked root test command. If your team standardises on npm and a single test entry point, the contribution path is steeper than the one-line install suggests. The README does not document rollback or uninstall steps, so treat cleanup as something you handle at the npm and config level yourself.
How it compares with scripted scanners and plain LLM chat
The obvious alternative for a web application assessment is an established scanner such as OWASP ZAP or Burp Suite, and the difference is not capability but control flow. A scanner executes a fixed rule set and produces deterministic output you can diff between runs. CyberStrike decides what to run next based on what it just found. That makes it better at following an unusual lead and worse at reproducibility: two runs against the same target can take different paths, which complicates regression testing and client reporting.
The other alternative is using an LLM chat window directly. That is effectively what CyberStrike automates. The difference is that a chat window has no tool orchestration, no schema normalization across providers, and no skill catalogue; you paste output manually and hope the model remembers the earlier phase. CyberStrike's value is the plumbing around the model, and the README is explicit that it is an intelligence layer rather than a wrapper. If you already have a disciplined manual workflow with a chat model, the gain from adopting CyberStrike is the orchestration and the OWASP checklist, not the model itself.
Licence, maintenance and upgrade cost
CyberStrike is licensed AGPL-3.0. The practical consequence for a pentest team is the network clause: if you modify the software and let users interact with it over a network, the AGPL's source-availability obligation is generally understood to apply to your modified version. Running the published npm package against a client target is not the same as modifying and hosting it, but the boundary matters if you plan to run the web UI as an internal service. This is a description of the licence text, not legal advice; get your own counsel for a commercial deployment.
On maintenance, the last push to the repository was on 2026-09-14, and the most recent release listed is v1.1.16 from 2026-08-13, following v1.1.15 on 2026-06-30 and v1.1.14 on 2026-06-18. That cadence suggests a project still being changed, but the upgrade cost is real: the root package.json pins bun@1.3.9 and a large dependency catalog including drizzle-orm 1.0.0-beta.20, ai 5.0.124 and zod 4.1.8. Beta and major-version pins in a security tool mean a routine dependency bump can require code changes. If you deploy from source rather than from npm, budget for that.
Editorial conclusion
Adopt CyberStrike if you already hold an LLM subscription and want an agent that sequences recon, exploitation and reporting against targets you are authorised to test; the npm install is one line and the first-run prompt walks you through provider setup. Do not adopt it if you need a signed, audited commercial platform, if your engagement rules forbid sending target data to a third-party model, or if you expect the agent to decide scope for you. Before you run anything, verify three things: that your provider account is acceptable under the engagement contract, that the AGPL-3.0 network clause fits how you intend to deploy the web UI, and that the agents and skills you enable match the rules of engagement you signed.
Frequently asked questions
What is CyberStrike?
CyberStrike is an open-source AI agent built for offensive security, distributed on npm as @cyberstrike-io/cyberstrike and written in TypeScript. The README describes it as automating reconnaissance, vulnerability discovery, exploitation and reporting from the terminal.
What is CyberStrike AI?
The README calls it an intelligence layer that transforms any AI model into an offensive security specialist by injecting OWASP methodology, vulnerability patterns and tool orchestration logic into each interaction. It supports 150+ AI providers and 5,300+ models according to the project.
How do I install CyberStrike?
The README gives one command: npm i -g @cyberstrike-io/cyberstrike@latest && cyberstrike. It launches a TUI that asks for your LLM provider and API key on first run.
Which LLM providers does CyberStrike support?
The README lists 150+ providers and 5,300+ models, including Anthropic, OpenAI, Google, Amazon Bedrock, Azure OpenAI, Google Vertex AI, GitHub Copilot, xAI, Groq, Mistral, DeepSeek, Cerebras, Cohere, OpenRouter, Together AI and DeepInfra, with 23 bundled SDK providers plus the models.dev catalog.
What licence does CyberStrike use?
The repository is licensed AGPL-3.0, as shown by the licence badge in the README and the LICENSE file at the repository root. The network clause is the part to examine if you plan to modify and host the web UI.
Community notes