docs: add vulnerability harness positioning

This commit is contained in:
artale 2026-06-22 00:28:25 +02:00
parent 619288e517
commit ebf1c7eddd
1 changed files with 62 additions and 0 deletions

View File

@ -0,0 +1,62 @@
# Vulnerability Harness Positioning
## Signal
Cloudflare published a vulnerability-harness architecture on 2026-06-18: a multi-stage vulnerability discovery harness with automated triage, state controls, adversarial review to reduce false positives, and routing around LLM context limits.
Source: [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/)
Related signal: Cloudflare Temporary Accounts let agents deploy Workers quickly with `wrangler deploy --temporary`.
Source: [Temporary Cloudflare Accounts for AI agents](https://blog.cloudflare.com/temporary-accounts/)
## Why it matters
Cloudflare is validating both sides of the same market:
```text
agents can deploy faster
agents can also search for vulnerabilities faster
therefore agent work needs verifiable evidence, triage, and fail-closed gates
```
## Mapping to fable-agent
| Cloudflare pattern | fable-agent primitive |
|---|---|
| Multi-stage vulnerability discovery | safety gate → AST/glyph scan → build/test/docs → attestation |
| Automated triage loop | risk findings + human review reasons |
| Adversarial review to squash false positives | `goal-audit`, verifier receipts, explicit residual risk |
| State controls | typed receipts, memory-vs-live drift receipts |
| Context-limit routing | harness-agnostic proof boundary after Pi/Codex/Claude/OpenClaw work |
| Temporary deploy account | deploy substrate that still needs fable-agent attestation |
## Quality boundary
Do not position fable-agent as a Cloudflare clone or vulnerability scanner platform.
Position it as the trust layer around agentic engineering and security work:
```text
Cloudflare shows agents can deploy and hunt bugs.
fable-agent proves what those agents did, what verified it, and whether deploy should remain blocked.
```
## Required controls for agentic vulnerability work
- read-only/default-safe discovery unless explicitly authorized
- receipt for every scan or triage decision
- adversarial review before claiming a vulnerability
- no deploy from stale memory
- no “fixed” claim without build/test/docs or target-specific verification
- current fable-agent deploy decision route remains `8099/deploy via git-proxy`
## Memory-vs-live rule
The current memory summary says factory has 25 containers and cron-based RSI. Live checks in this repo observed factory status `stale`, 14 containers, and cron absent. For deploy and vulnerability-harness decisions:
```text
live receipt > committed receipt > memory summary
```
Memory is context. Live receipts are proof.