diff --git a/src/AI/Web-Black-Box-AI-Pentester-Bots.md b/src/AI/Web-Black-Box-AI-Pentester-Bots.md
index 3449658702d..7c1f287efd8 100644
--- a/src/AI/Web-Black-Box-AI-Pentester-Bots.md
+++ b/src/AI/Web-Black-Box-AI-Pentester-Bots.md
@@ -81,7 +81,91 @@ When you turn the workflow into reusable skills/prompts, explicitly bias the age
- **Source-map mining**: grep `sourcesContent` for mock paths, hidden assets, API route names, service filenames, feature flags, and committed tokens; use the findings to drive the next fuzzing/validation loop.
- **dApp signing hooks**: if XSS lands on a wallet-connected origin, immediately inspect whether the page can tamper with `signTransaction`, `signAndSendTransaction`, or similar signing methods to change the transaction after the UI intent is established.
-## 8. Good agent outputs
+## 8. Exploitability-first target pruning
+
+A good autonomous agent should rank **exploitable population**, not just **vulnerable versions**. For internet-wide hunting, first compare:[[2]](#references)
+
+- deployment count / reachable population
+- public PoC maturity
+- affected-version overlap when chaining multiple bugs
+- **target-side prerequisites** such as public endpoints, auth state, upload fields, feature flags, or insecure defaults
+
+Practical workflow:
+
+1. enumerate a large candidate set from FOFA/Shodan/Censys/MCP-backed search
+2. fingerprint versions with **lightweight** requests first (`curl`, headers, HTML titles, exposed metadata)
+3. read the PoC and extract the **real preconditions**
+4. discard hosts that only match the version but not the configuration
+5. only then spend tokens/time on exploitation
+
+This matters for chained exploits:
+
+- **Langflow-style cases**: a vulnerable version may still need `auto_login` or a public flow/workflow identifier before the exploit reaches code execution.
+- **n8n-style cases**: if the chain needs both an arbitrary file read and a sandbox bypass, compare both patch boundaries and then confirm the required **unauthenticated file-upload form** exists. If the form requires auth, the unauthenticated chain is dead even when the version is old enough.
+
+A useful pattern is to persist a `prerequisites` object per target, for example:
+
+```json
+{
+ "product": "n8n",
+ "version": "1.117.3",
+ "vuln_chain": ["file-read", "sandbox-bypass"],
+ "public_form": true,
+ "file_upload": true,
+ "auth_required": false,
+ "exploitable": true
+}
+```
+
+## 9. Autonomous recon-to-exploitation loops
+
+A practical offensive loop is:
+
+1. receive a goal
+2. translate it into asset-search queries
+3. fingerprint products/versions
+4. search public PoCs / advisories
+5. download or generate scanners
+6. validate exploit prerequisites
+7. attempt exploitation
+8. classify failure and **pivot automatically**
+
+MCP-connected tooling makes this cheaper because the agent can call internet-search backends, scanner generators, and custom scripts in one loop. The important engineering detail is not the LLM alone, but the **closed loop** between search, versioning, exploit acquisition, validation, and retargeting.
+
+For thin targets, sample aggressively before full scanning. If a search engine returns tens of thousands of candidates, probe a small subset, measure reachable/vulnerable/prereq-satisfied ratios, and expand only when the hit rate stays high.
+
+## 10. Permission profiles are part of the exploit chain
+
+Autonomy depends heavily on the client-side execution policy. Settings such as `dangerously-skip-permissions: true`, `approvalMode: "yolo"`, `network_access = "enabled"`, or trusted writable workspaces remove the human from the loop and let the agent:
+
+- run shell commands
+- modify PoCs and scanners
+- fetch exploits and advisories
+- spawn subagents
+- exfiltrate collected data
+
+From an offensive perspective this enables fast iteration. From a defensive perspective these settings are part of the **attack surface**: prompt injection, repo-local config poisoning, or malicious MCP metadata become much more dangerous when the client no longer asks for approval before file, shell, or network actions.
+
+## 11. Agent opsec failures leak the whole workspace
+
+Do not forget that autonomous tooling also makes attacker mistakes cheaper. A classic example is:
+
+```bash
+cd /home/worker
+python3 -m http.server 8888
+```
+
+`python3 -m http.server` serves the **current directory and descendants**. If the agent starts it from a home directory, repository root, or shared workspace, it can publish:
+
+- API keys and config files
+- shell history
+- target lists
+- downloaded PoCs
+- agent logs and transcripts
+
+For operators, use an empty staging directory and low-privilege account before exposing any file server. For defenders, hunt for unexpected `python3 -m http.server` processes, port `8888` listeners, and public directory indexes exposing dotfiles or agent artifacts.
+
+## 12. Good agent outputs
The best output of an autonomous hacking agent is usually **not** a polished report. It is a queue of:[[1]](#references)
@@ -93,5 +177,6 @@ The best output of an autonomous hacking agent is usually **not** a polished rep
## References
- [1] [Joseph Thacker & xssdoctor - The Bug Bounty Singularity: Our Hackbot](https://josephthacker.com/hacking/2026/07/01/we-built-a-hackbot.html)
+- [2] [Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/)
{{#include ../banners/hacktricks-training.md}}