Pentest Swarm AI: Stigmergic Blackboard Architecture for Autonomous Pentesting (2026)

Q: What makes Pentest Swarm AI a true swarm rather than a multi-agent pipeline?

Three architectural primitives applied simultaneously: stigmergy (agents coordinate by reading and writing findings to a shared PostgreSQL plus pgvector blackboard with per-finding pheromone weights, not via a central planner), emergence (attack chains form because each agent's trigger predicate fires on board state — recon finding wakes classifier, high-CVSS CVE wakes exploit, exploit success wakes recon — without any agent prescribing the chain), and decentralisation (each agent owns its own trigger predicate, so adding or removing an agent requires no orchestrator rewrite). Drop any one and you regress to a different design point: drop stigmergy and you have a message-passing actor system, drop emergence and you have a workflow engine, drop decentralisation and you have a single-supervisor agent. PentestGPT (single ReAct), PentAGI (4 agents plus planner), and HexStrike (stateless MCP wrapper) all retain a central planner or stateless dispatch and hit the planner-context-window ceiling on any non-trivial campaign. Pentest Swarm AI is the first open-source autonomous pentester to ship all three primitives in one design.

Q: Why is the planner-LLM pipeline pattern wrong for offensive security automation?

Because real attack chains are non-linear, evidence-driven, and bursty in branching factor. A planner LLM has to decide at recon-time what the entire downstream chain will look like, but the most useful exploit paths only become visible after the classifier has matched a CVE against a fingerprint, and the most useful classifier signals only emerge after a tool surfaces an unexpected service. Three failure modes follow: the planner has to re-plan from scratch every time a finding contradicts its prior; the context window blows up holding both plan and findings; parallel exploration of two competing hypotheses is impossible because the planner can only hold one trajectory at a time. The swarm pattern fixes this by putting findings on a shared substrate (PostgreSQL with pgvector embeddings and pheromone weights) and letting agents coordinate through reads and writes against that substrate. The behavioural difference is observable in attack-chain quality — the swarm finds chains the planner could not have prescribed because no agent was told to find them.

Q: How do pheromone weights and decay work, and why do I need them?

Every finding written to the blackboard carries a numeric pheromone_weight column set by the writing agent based on its confidence and the finding's severity. Decay runs on a class-specific half-life — Pentest Swarm AI defaults to 30 minutes for raw recon findings and 6 hours for confirmed-CVE findings, with the orchestrator running a periodic UPDATE that multiplies weights by exp(-elapsed/half_life). Other agents query the blackboard with a hybrid filter — vector similarity over the finding text plus a SQL predicate over pheromone_weight — and only the heaviest-trail findings are followed. Without decay, the blackboard accumulates stale findings indefinitely, vector similarity searches degrade in precision, and the swarm spends its tokens revisiting attack paths the campaign has already proven dead. The architectural lesson generalises beyond pentest: any shared-memory substrate that does not have decay becomes a soup of accumulated state that erodes the system's ability to focus.

Q: Why is dual-layer scope enforcement non-negotiable, and where does each layer live?

Because a single layer is one prompt-injection or one parser bug away from scanning a target the operator did not authorise — and an unauthorised scan against the wrong host is a Computer Misuse Act offence in the UK, an unauthorised access offence under §43 of India's IT Act 2000, and a CFAA violation in the US. Pentest Swarm AI enforces scope at the tool adapter (the adapter refuses to invoke nmap or nuclei against a host outside the --scope flag passed at campaign start) and at the executor layer (the executor refuses to start a process whose argv contains a target outside scope). Both emit audit events on refusal, so a prompt-injection that tricks an LLM into emitting an out-of-scope target is caught even if the adapter's regex has a bug. The pattern generalises to any agent system that issues commands with side effects in the real world — payments, email, deploys, infrastructure changes, data exports — the same dual-layer envelope is the only safe design.

Q: How does the tool adapter contract enable Wave 2 additions like sqlmap, Burp, Metasploit, and ZAP?

An adapter is a 100–300-line piece of code that exposes three functions: invoke(target, options) runs the tool with scope-validated arguments, parse(raw_output) converts the tool's stdout/XML/JSON into a list of typed Finding records, and score(finding) computes a pheromone weight from severity and confidence. The agent's manifest declares the trigger predicate ("wake when a service finding for product=mysql arrives with pheromone greater than 0.7") separately from the adapter implementation. Adding sqlmap means writing the sqlmap adapter (invoke wraps sqlmap CLI, parse reads its JSON report mode, score maps CVSS plus DBMS confidence to pheromone weight) and a manifest with a trigger predicate that fires on classifier findings of type SQL_INJECTION_CANDIDATE. Burp adds an MCP-bridge adapter, Metasploit an RPC adapter, ZAP a daemon adapter — each a self-contained drop-in. The orchestrator picks them up at next reload and the rest of the swarm starts firing them without any other agent knowing they exist. This is the cleanest pattern for plugin extensibility in any agent system.

Q: How is model choice decoupled from agent identity, and why does that matter for air-gapped deployments?

The agent code calls a model gateway, not a specific model — Claude is the default with prompt caching enabled for recon and classifier agents (because their context grows monotonically through a campaign and prefix-caching is worth ~70% off the model bill), Ollama is the local backend for fully air-gapped deployments where no pentest data may leave the operator's network, and any OpenAI-compatible model can be routed for cost or capability tuning. The same swarm runs unchanged under any of these because the model is a tool the agents call, not an architectural constraint. For organisations whose threat model forbids sending pentest data to a frontier provider — defence contractors, government departments, regulated financial services, healthcare with HIPAA-bound systems — the air-gapped Ollama path with Llama 3.3 70B costs zero per campaign once the GPU is amortised, at the cost of roughly 2× wall-clock. The cost-quality-latency trade-off is the operator's, not the architecture's.

Q: What does a representative campaign cost in 2026, and where is the spend concentrated?

On a moderately complex external web target (~50 subdomains, ~200 endpoints, ~30 services), a full Sonnet 4.5 campaign with default prompt-caching consumes roughly 12M input tokens and 1.2M output tokens, achieves a 78% prompt-cache hit rate on the recon and classifier agents, runs for 38 minutes wall-clock, and bills out at about $18.40 in model spend. Switching the exploit agent to Claude Opus 4.5 for higher-stakes reasoning lifts the bill to about $26.80 with 42 minutes wall-clock. A cost-optimised gpt-4o-mini campaign comes in at about $2.30 in model spend at 51 minutes wall-clock. Air-gapped Ollama with Llama 3.3 70B is $0 per campaign once the GPU is amortised at 71 minutes wall-clock. Infrastructure (PostgreSQL, worker compute, object storage) runs at sub-5% of the model bill. For comparison, equivalent Burp Suite Enterprise or Tenable web-app scans bill at $80–$140 per run and find chains the swarm finds because their planner is fixed. The compounding lever for spend is prompt caching on monotonically growing context — the same lever that drives KV-cache engineering in every other agent system.

Q: How does Pentest Swarm AI integrate with CI/CD pipelines via SARIF and GitHub Actions?

A ready-made GitHub Action ships in the repo, accepts target and scope as inputs, runs the full swarm, and emits SARIF (Static Analysis Results Interchange Format, OASIS standard 2.1.0) which GitHub Code Scanning ingests natively to populate the Security tab without any glue code. Self-hosted runners support the air-gapped Ollama backend for organisations that cannot send pentest data to a frontier provider. The architectural lesson is that emitting one industry-standard format unlocks half the security ecosystem — SARIF is consumed by GitHub Code Scanning, GitLab SAST, Azure DevOps, DefectDojo, Sonatype IQ, JFrog Xray, and most enterprise vulnerability aggregators. Writing 50 lines of SARIF emit code is operationally equivalent to writing 20 individual integrations. The pattern generalises: emit OpenLineage for data pipelines, emit OpenTelemetry for observability, emit CycloneDX or SPDX for SBOMs, emit SARIF for security findings — each unlocks the existing ecosystem rather than fighting it.

Q: What is the MCP serve mode and how does it integrate with Claude Desktop, Cursor, and IDE workflows?

The pentestswarm mcp serve command exposes the entire swarm as a Model Context Protocol server, making it natively callable from any MCP client — Claude Desktop, Cursor, Continue, Cline, Windsurf — without any IDE-specific glue code. The agent's tool list now includes pentestswarm.scan, pentestswarm.query_findings, pentestswarm.run_exploit, and so on, with typed schemas the IDE-side agent can validate against. The use case is IDE-level offensive security: a developer debugging a suspected vulnerability asks Claude in Cursor to scan the staging environment, the MCP server runs the swarm scoped to the staging target, the findings stream back into the IDE chat, and the developer iterates on a fix with the swarm re-running on each commit. The pairing with the multi-agent LangGraph plus MCP plus A2A pattern is direct — the swarm is a producer of findings on an MCP surface, and any LangGraph supervisor can consume those findings as tool outputs for higher-level remediation orchestration.

Q: What are the top architectural anti-patterns to avoid when copying this design into a non-pentest agent system?

Eight ranked by failure-mode severity. (1) Single-planner LLM as orchestrator — the planner becomes the bottleneck and the context-window cap; replace with blackboard plus trigger predicates. (2) Blackboard without pheromone decay — stale state accumulates and erodes retrieval precision; add class-specific half-life decay. (3) Single-layer scope guard on dangerous actions — prompt-injection can bypass; enforce at tool layer plus executor layer. (4) Tool adapter without typed Finding records — blackboard becomes a soup of free text; require typed schemas with class, confidence, scope, pheromone fields. (5) Hardcoded tool list in the planner prompt — kills decentralisation; use trigger-predicate manifests. (6) Conversation-context shared memory — every agent re-pays prefill cost and the campaign caps at minutes; use persistent blackboard with prompt-cached prefixes. (7) No campaign-end report agent — operationally inert; dedicate one agent to dedupe, score, scope-filter, and emit standard formats. (8) Coupling model choice to agent identity — locks out air-gapped and cost-optimised paths; route through a gateway. These generalise to any production agent system, not just offensive-security tooling.

Satyam Kumar

Back to Blog

cyber-security-patterns

Pentest Swarm AI — Stigmergic Blackboard Architecture for Autonomous Penetration Testing (2026)

June 1, 202619 min read

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam

AI & Cloud Architect. Helping teams build systems that scale to millions.

Pentest Swarm AI — Stigmergic Blackboard Architecture for Autonomous Penetration Testing (2026)

Frequently Asked Questions

Share this article

Comments

Leave a comment