Run a real penetration-test workflow from your AI coding agent: a hands-on guide to Blitz Strike

Every AI coding agent you run is only as safe as the code it touches. MCP servers are the fastest-growing attack surface in this stack — each new server is new code your agent will execute with your permissions. Blitz Strike (shinthink/blitzstrike) is a free, MIT-licensed MCP server that packages a real penetration-testing methodology — reconnaissance, source analysis, and live validation — as callable tools. One server, every agent: the whole engagement runs server-side, so a single run_engagement call works from Claude Code, Cursor, OpenCode, Claude Desktop, Gemini, or any MCP client.

Its core discipline is what separates it from scanners: "A scan hit is a hypothesis. A live test is the verdict." A three-tier pipeline — BLITZ maps the attack surface, EAGLE-EYE traces source-to-sink reachability, STRIKE verifies each finding live — exists to kill the two most common failure modes of automated assessment: false positives from surface-level pattern matching, and unverified findings reported without confirmation. The project landed its v1.0.0 on September 12, 2026 and has picked up 489 stars in just over two weeks.

What you'll need

• Bun 1.4+ (or Node 20+) — for running from source and building.
• One MCP client — anything that speaks MCP over stdio: Claude Code, Cursor, OpenCode, Claude Desktop, Gemini CLI, Codex, Copilot, Cline, Windsurf, or Hermes.
• A target you are authorized to test — a local codebase or a URL in scope. This matters: scope_check runs before active testing in every mode, and the project's security policy is explicit about authorized use.
• Optional: FOFA_EMAIL + FOFA_KEY environment credentials to enable fofa_search asset-index lookups. All other tools need no credentials.

1. Install Bun

Blitz Strike is TypeScript on Bun, so you need Bun 1.4+ (or Node 20+) to run it from source. Install it with the official one-line installer from bun.sh — it is the first command in the project's install docs — then confirm with bun --version.

2. Install Blitz Strike

The reliable path is from source:

git clone https://github.com/shinthink/blitzstrike.git
cd blitzstrike
bun install

The docs also describe a pre-built binary from the releases page (chmod +x blitzstrike, then ./blitzstrike serve --mcp). At the time of writing, the v1.0.0 release page listed no downloadable assets, so from-source is the path we verified.

3. Register it with your agent CLI

The binary wires itself into your tools. First preview, then write:

blitzstrike install --dry-run   # preview without writing
blitzstrike install             # detect every agent CLI + write native config

install auto-detects which agent CLIs you have and writes the correct MCP config to each one, in its native format. Every write merges — it never overwrites your existing MCP servers or other config keys:

Agent	Config written
Claude Code	~/.claude.json
Claude Desktop	~/.config/Claude/claude_desktop_config.json
Cursor	~/.cursor/mcp.json
OpenCode	~/.config/opencode/opencode.json (type: local + command array)
Codex	~/.codex/config.toml ([mcp_servers.blitzstrike])
Hermes	~/.hermes/config.yaml
Gemini CLI	~/.gemini/settings.json
Windsurf	~/.codeium/windsurf/mcp_config.json
Copilot	~/.copilot/mcp.json
Cline	~/.cline/mcp_settings.json

Prefer to do it by hand? Any MCP client takes this directly:

{
  "mcpServers": {
    "blitzstrike": {
      "command": "blitzstrike",
      "args": ["serve", "--mcp"]
    }
  }
}

For Hermes specifically, add to ~/.hermes/config.yaml:

mcp_servers:
  blitzstrike:
    command: "blitzstrike"
    args: ["serve", "--mcp"]

4. Verify the installation

blitzstrike doctor

doctor checks the runtime, the 130-tool catalog, credentials, and data layers — each reported with a severity and a fix: line. Treat a failing check here as the setup being incomplete, not the tool being broken.

5. Run your first engagement

The entire audit runs server-side in a single tool call from your agent:

run_engagement(target="/path/to/source", scope="", mode="bug-bounty")

For a URL target, pass the scope:

run_engagement(target="https://target.com", scope="*.target.com", mode="bug-bounty")

What comes back: the scope-enforcement result, BLITZ triage (files, hits, matched chains), EAGLE-EYE traced chains with the relevant exploit-tool manual attached to each, findings — all marked HYPOTHESIS until verified — and a memory capture summary.

Three engagement modes control how aggressive it gets:

Mode	Behavior
bug-bounty	Strict scope: no-DoS, exclusion-aware, authorized-research guardrails.
red-team	Full active testing (scope enforcement still applied).
ctf	Per-challenge targets.

Start in bug-bounty mode. It is the only sensible default when the target belongs to someone else's organization and you are the one who would explain the traffic.

6. Go granular when you want control

The one-call path trades control for speed. The granular path runs the same tiers by hand:

1. blitz_scan(path) — enumerate unauthenticated entry points and dangerous sinks.
2. eagle_eye(path, symbol) — confirm a sink sits in scope of a handler and is unguarded.
3. read_tool_manual(name) — pull the exploit tool's full manual.
4. strike_verify(...) — live verification with a marker plus a negative control.

The verdict rule is the whole point of the project: only after strike_verify reflects your marker AND the chain's negative_control stays inert do you have a finding. Until then, everything you have is a hypothesis — well-traced, well-documented, but a hypothesis.

7. Make the audit reproducible

Blitz Strike ships a full supporting layer around the three tiers. The ones you'll reach for first:

• Knowledge base: tool_lookup / ensure_tool (find and auto-install a security tool), skill_lookup / read_skill (search 32 universal playbooks), read_tool_manual / read_playbook (317 manuals + 17 playbooks), payload_lookup / template_lookup (exploit payloads + nuclei templates).
• Intelligence: detect_waf, tech_correlation, cve_correlation, port_correlation.
• Reporting: cvss_score (self-computed CVSS), dedup_findings (root-cause dedup), generate_report (reproducible reports), plus run_enterprise_benchmark and coverage_matrix to measure detection quality.
• Memory: remember / memory_lookup / memory_forget persist verified knowledge at ~/.blitzstrike/memory.jsonl (override with BLITZSTRIKE_HOME). run_engagement auto-captures matched escalation chains as deduplicated pattern entries — but only verified=true entries are authoritative.

What you built

A reusable security-audit harness wired into the agent you already use — install once, registered natively in every agent CLI on your machine, runnable from any MCP client without rebuilding anything. One run_engagement call now produces scope-checked triage, data-flow-traced escalation chains with exploit manuals attached, and findings disciplined by live verification rather than pattern hits. It's the closest thing to a repeatable pentest workflow that fits inside a tool call.

Honest limitations

• Methodology is not magic. A scan hit is still a hypothesis until STRIKE verifies it live — and live verification can only confirm what it can safely test inside the scope you gave it. Silent targets return thin findings.
• Authorized targets only. The STRIKE tier does live, active verification; scope_check runs before active testing in every mode, and the project's security policy expects authorized research. Do not point this at infrastructure you don't own or have permission to test.
• Young project. v1.0.0 is barely two weeks old at the time of writing. The docs describe a pre-built binary path, but the release page currently lists no downloadable assets — expect the docs and the binaries to converge as the project matures.
• One-call mode is opaque by design. The engagement runs server-side; when you need to understand why a chain was dismissed, use the granular path instead of re-running the black box.
• Optional pieces stay optional. FOFA asset-index lookups need FOFA credentials; everything else works without any keys — which is convenient, but it also means the recon layer is only as deep as the free data layers.

>