ADR-003: AppSec Scanner — 59-Agent Parallel Model
Status: ✅ Accepted Date: 2026-03-25 Decision Makers: Tilak Kumar
Context
ThreatWeaver's AppSec module needs to automatically discover and exploit vulnerabilities in web applications — BOLA, BFLA, SQLi, XSS, SSRF, IDOR, JWT attacks, race conditions, and more. The architecture had to decide how to structure the detection logic:
- A monolithic scanner with a single execution flow
- A modular plugin system with sequential plugins
- A parallel agent model where each vulnerability class runs as an independent agent
The scanner must handle 868+ endpoints per target, with each endpoint potentially requiring multiple test payloads, authenticated requests, and cross-user comparison. Sequential processing would take hours.
Decision
Build a 59-agent parallel scanning model where each agent is responsible for one vulnerability class.
Each agent:
- Is a TypeScript class registered in
backend/src/appsec/agents/ - Receives a shared
ScanContext(endpoints, auth tokens, test data hints) - Writes findings to a shared
Blackboardservice - Runs concurrently with all other agents via
Promise.allSettled() - Has its own AI validation step (Claude-powered) to reduce false positives
Key agents in the fleet:
| Agent | Detects |
|---|---|
idorFinder.agent.ts | BOLA/IDOR (path param + query param substitution) |
bflaChecker.agent.ts | BFLA (horizontal privilege escalation) |
sqlInjectionTester.agent.ts | SQLi (error-based, boolean-based, time-based) |
xssTester.agent.ts | Reflected, stored, DOM-based XSS |
ssrfTester.agent.ts | SSRF (internal network probing) |
jwtAttacker.agent.ts | JWT alg:none, key confusion |
raceConditionTester.agent.ts | Race conditions (concurrent request flooding) |
authBypassTester.agent.ts | Authentication bypass heuristics |
| ... | 51 more specialized agents |
Consequences
Positive:
- Scan time reduced from hours to minutes (all 59 agents run in parallel)
- Each agent can be developed, tested, and tuned independently
- New vulnerability classes can be added without touching existing agents
- Agent failures are isolated — one agent crashing doesn't abort the entire scan
- AI validation is per-agent, allowing calibrated confidence thresholds
Negative / Trade-offs:
- 59 concurrent agents hitting the same target can trigger rate limiting or WAF blocks (mitigated by jitter and configurable concurrency limits)
- Shared Blackboard requires careful locking for deduplication (APP_WIDE vs ENDPOINT dedup scopes)
- Agent orchestration overhead in
aggregation.service.ts(~2,936 lines — most complex file in the codebase) - Memory footprint per scan is higher than sequential scanning
- Debugging requires correlating logs across 59 parallel execution streams
Alternatives Considered
| Option | Why Rejected |
|---|---|
| Monolithic sequential scanner | Too slow. 868 endpoints × multiple test cases = hours per scan. Unacceptable for interactive use. |
| Sequential plugin model | Better than monolithic but still bottlenecked by slowest plugin. No isolation. |
| External scanner integration (Burp, OWASP ZAP) | Black-box only, no access to ThreatWeaver auth context, no AI validation, no direct integration with finding storage |
| Cloud-distributed scanning (separate workers per agent) | Over-engineered for current scale; adds infrastructure complexity without benefit at under 100 concurrent scans |