2.5 KiB
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
Related signal: Cloudflare Temporary Accounts let agents deploy Workers quickly with wrangler deploy --temporary.
Source: Temporary Cloudflare Accounts for AI agents
Why it matters
Cloudflare is validating both sides of the same market:
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:
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:
live receipt > committed receipt > memory summary
Memory is context. Live receipts are proof.