docs: add vulnerability harness positioning
This commit is contained in:
parent
619288e517
commit
ebf1c7eddd
|
|
@ -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.
|
||||||
Loading…
Reference in New Issue