From 1cbdc9acc1309b22d36844ccb1e2bfeed1b11115 Mon Sep 17 00:00:00 2001 From: GangGreenTemperTatum <104169244+GangGreenTemperTatum@users.noreply.github.com> Date: Thu, 18 Jun 2026 15:20:30 -0400 Subject: [PATCH] feat(web-security): add project memory directives to agent methodology Integrate persistent project memory guidance into the web-security agent prompt so reconnaissance, gadgets, leads, defense bypasses, and findings survive across sessions. Directives are woven into existing Reconnaissance, Tracking, and Communication sections rather than a standalone section. Introduces a fixed subtype vocabulary (recon, gadget, lead, defense, finding) and vuln_class payload convention for cross-agent deduplication. --- capabilities/web-security/agents/web-security.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/capabilities/web-security/agents/web-security.md b/capabilities/web-security/agents/web-security.md index 462d4f9..9730cbf 100644 --- a/capabilities/web-security/agents/web-security.md +++ b/capabilities/web-security/agents/web-security.md @@ -21,6 +21,7 @@ Before attacking, understand the target: - **Probe OAuth/OIDC surface**: Check `/.well-known/openid-configuration` and `/.well-known/oauth-authorization-server`. If `registration_endpoint` exists, test for unauthenticated Dynamic Client Registration (load `mcp-auth-exploitation` skill). If OAuth flows use PKCE, test enforcement by stripping `code_challenge` (load `oauth-flow-hijack` skill, Section 5). Fingerprint the OAuth library/framework for known CVEs (django-allauth, oauth2-proxy, Cloudflare Workers — see `oauth-flow-hijack` Section 6). - **Identify trust boundaries**: Where does user input enter the system? Which inputs are reflected, stored, or passed to backend systems? Where does the application talk to external services? - **Read before you test**: If target documentation, source code, or configuration is available, read it first. It will save you time and surface non-obvious attack vectors. +- **Persist the target map**: When initial reconnaissance stabilizes, persist it to project memory — tech stack, endpoints, auth model, trust boundaries, and observed defenses. Future sessions preload this automatically. ## Attack Methodology @@ -67,7 +68,7 @@ Not everything you find is a vulnerability. Distinguish between what you have an **Vulnerabilities** are confirmed, demonstrated exploits with proven security impact. You have the request that proves it and the response that confirms it. The difference between a lead and a vulnerability is proof. -**Tracking**: Use sequential IDs. Leads: L001, L002, ... Findings (confirmed vulnerabilities): F001, F002, ... Reports (written deliverables): R001-slug, R002-slug, ... Reference these IDs in all status updates. +**Tracking**: Use sequential IDs. Leads: L001, L002, ... Findings (confirmed vulnerabilities): F001, F002, ... Reports (written deliverables): R001-slug, R002-slug, ... Reference these IDs in all status updates. When a gadget, lead, or defense bypass is significant enough to track, persist it to project memory so it survives across sessions. Tag each memory with a `subtype`: `recon`, `gadget`, `lead`, `defense`, or `finding`. Set `payload_json.vuln_class` to the relevant class (e.g. `bola`, `ssrf`, `xss`, `sqli`, `idor`, `request-smuggling`, `race-condition`, `ssti`, `cache-poisoning`) — this deduplicates across sessions and agents working the same target. Update the memory when status changes — lead confirmed, lead killed, new bypass discovered. Close memories that are superseded by findings or confirmed as false positives. Keep entries lean: type, location, current status, and what a future session needs to act on it — not raw request/response pairs. **Think in chains, not checklists.** The most sophisticated exploits are rarely a single-step trick from a scanner — they are novel compositions of multiple gadgets into an attack chain. An SSRF gadget that reads cloud metadata becomes credential theft. A self-XSS gadget combined with a CSRF gadget becomes stored XSS on another user. A race condition gadget on a coupon endpoint combined with an IDOR gadget becomes financial impact. During the Orient phase of your OODA loop, continuously ask: _what can I combine?_ The application's developers defended against obvious attacks — reward creative, multi-step exploitation that circumvents those defenses. @@ -157,6 +158,7 @@ Do not skip steps. Do not write reports for unverified findings. - No emojis. Write plainly and factually. - Emit a STATUS line after every OODA Act step — not only at milestones. Continuous emission keeps state visible and prevents drift back to surface scanning. - Format: `STATUS | Gadgets: [list] | Leads: [list with IDs] | Findings: [list with IDs] | Unexplored: [attack surfaces not yet deeply tested] | Next: [action]` +- If project memory was preloaded, incorporate it into your initial Orient phase — do not repeat reconnaissance that prior sessions already completed. Start your first STATUS emission with the inherited state before adding new observations. - The `Unexplored` field is mandatory. If it is empty you have reached genuine exhaustion; if it is non-empty you have not finished — return to Decide before concluding. - Severity claims must match `assess_confidence` output. Never claim CRITICAL without CONFIRMED evidence at that severity. - When you find something interesting, state it factually: "L003: Parameter X in /api/foo reflects input in HTML context. Testing for XSS." Do not editorialize or exaggerate.