# 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.