Praetor — agentic DAST orchestrator for Burp Suite. MCP server with persistent target memory, KB-driven probes, save-finding pipeline, and 11-agent team.
Praetor defines 19 tools with generally clear names and detailed descriptions (avg 180 chars, well above baseline 72 chars for params). Most tools have structured input schemas with type declarations. However, critical gaps exist: output schemas are entirely undocumented (no return type specs visible), error handling is absent from descriptions, and several tools lack parameter-level type constraints. Naming is strong (verb-first, domain-specific), but composition issues emerge: checklist_update, checklist_autotest, and checklist_record_batch form a tightly coupled workflow that could be simplified. Security concerns: no evidence of secret injection patterns for Burp API credentials. OAST tools (build_encrypted_oast_payload, decrypt_oast_capture) are well-described but lack error recovery guidance.
Report proxy-history composition (in-scope / static / duplicates / noisy hosts) and recommendations. Burp cannot delete history — this guides capture-time scope + off-proxy routing to keep the .burp project lean.
Inject Collaborator payload into a parameter, send request, and poll for OOB interactions. Requires Burp Professional.
Build a blind-exfil OAST payload that encrypts the leaked DATA with a local key before it hits the wire, so the OOB provider (Collaborator / interact.sh) only ever logs ciphertext. The real callback domain MUST come from generate_collaborator_payload (Burp Pro) or an operator-provided callback (interact.sh / webhook.site). This tool never fabricates one — pass the subdomain you obtained. Threat model: the symmetric key rides inside the injection payload (the target needs it to encrypt) but never reaches the OOB provider, which sees only the callback traffic. The operator decrypts captures locally with decrypt_oast_capture. Use in contexts where the target can run the encrypt step (RCE / command injection / SSTI).
Check which Burp features are available on this edition (Pro vs Community).
Detailed per-test-case checklist for an OWASP standard. Walks every individual test in the guide (id, name, and the Praetor tool that runs it), grouped by category. With `domain`, marks each item's category as touched/open from coverage.json so the operator sees exactly which test cases remain. Standards with a detailed catalog: ai_testing (32 tests); others fall back to their category list.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., what does checklist_autotest return? What fields does each item contain?). This violates pattern:tool and pattern:response-shaper.
Error handling absent from all tool descriptions. No guidance on retryability, user-fixable vs fatal errors, or recovery steps. E.g., websocket_connect fails silently; auto_collaborator_test may timeout without guidance. Violates pattern:recovery-guide and pattern:error-classification.
Checklist workflow (checklist_autotest → run tools → checklist_record_batch) is tightly coupled. Three separate tools could be unified into a single orchestration tool that accepts a batch of test results, reducing cognitive load and call overhead. Violates pattern:tool (single responsibility).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Drive the checklist: the ordered run-plan of OPEN test cases to execute. Walks the catalog and returns the next OPEN items (skipping confirmed / finding / not_applicable), each with the Praetor tool to run — so the orchestrator executes each, then records the result via `checklist_update`. This is the "test every case" loop. Ordering follows the Phase-0 engagement mode: `high_impact` puts the Rule-29 high-value categories first (and drops pure-manual items); `full_coverage` / `checklist` walk in catalog order.
Record many auto-test results at once — closes the run loop efficiently. After `checklist_autotest` gives the plan and you run each item's tool, pass the outcomes here in ONE call. Each result is a dict with `item_id` plus EITHER `verdict` (a VerdictResult verdict — CONFIRMED/FAILED/SUSPECTED/INCONCLUSIVE/ERROR, mapped automatically) OR an explicit `status` (confirmed/finding/not_applicable). Optional `note` (evidence index). Non-decisive verdicts (SUSPECTED/INCONCLUSIVE/ERROR) leave the item OPEN — they are not a completed test (Rule 13b/19a).
Confirm/complete one checklist test case (operator-owned status). Walk the checklist item by item: run each item's mapped tool, then record the operator-confirmed result here so it sticks (auto coverage marks a category touched; this marks the SPECIFIC test case done). Use this in the confirm loop — present the item + evidence, ask the operator, then set it.
Curate one evidence request in a single call: annotate it in Burp, send it to the Organizer, and record it as the finding's canonical evidence index (Rule 18). Use after a finding is confirmed.
Decrypt an OAST capture (ciphertext observed at the Collaborator / callback) using the local OAST key. Operator-side counterpart to build_encrypted_oast_payload. Accepts either a raw Fernet token (HTTP exfil) or concatenated base32 DNS labels (DNS exfil) — dots/whitespace are stripped automatically.
Send multiple proxy history items to Burp's Organizer at once.
Send request to Burp's Intruder with custom positions. Modes: simple, auto, or manual byte offsets.
Send a proxy history item to Burp's Organizer tab.
Preserve the Burp-side signal to `.burp-intel/<domain>/snapshots/<ts>/` so the bloated Burp project can be safely discarded / rotated. Findings, coverage, endpoints and target intel already live on disk under `.burp-intel/<domain>/` and survive a new Burp project automatically. What is LOST when you start a fresh project is the Burp-held state: the sitemap and the scanner issues. This snapshots those (plus a proxy-history size reading) and writes a manifest, then tells you it is safe to rotate. Montoya has no "new project" API, so the rotation itself is a one-click operator action (Burp: File → New project). This tool makes it lossless.
Measure whether set_capture_hygiene is actually working — the noise rate of NEW capture, not assumed. Burp cannot delete old history, so total-history noise never drops; the fix only affects newly-recorded traffic. This reads the cumulative static / out-of-scope counts, and when given a prior `baseline` computes the DELTA — the composition of just the traffic captured since — so you see whether new entries are clean.
Close a WebSocket connection.
Open a WebSocket connection through Burp's proxy.
List all open WebSocket connections.
Send a text message on an open WebSocket connection.
WebSocket tools lack parameter constraints. websocket_connect accepts arbitrary headers but does not validate or document which headers are forbidden (Upgrade, Connection, etc. are auto-set). No enum for injection_point in auto_collaborator_test ('query'|'body'|'header'). Violates pattern:constrained-input.
No evidence of secret injection for Burp API credentials. If the MCP server passes Burp API keys as tool parameters or environment variables, they risk exposure in logs and LLM traces. Violates pattern:secret-injection.