2.0 KiB
Temporary Agent Deploy Accounts
Signal
Cloudflare announced Temporary Accounts for AI agents on 2026-06-19: agents can run wrangler deploy --temporary and get a live Worker without a normal human account setup.
Source: Temporary Cloudflare Accounts for AI agents
Why it matters
This validates the market direction:
agents increasingly get direct deploy rails
therefore deploy proof and revocation matter more, not less
Temporary deploy accounts reduce friction, but they do not answer the core fable-agent questions:
- What changed?
- What scanned it?
- What commands passed?
- What residual risk remains?
- Was deploy allowed through the current guarded route?
- Is the deploy route live evidence or stale memory?
fable-agent stance
Temporary accounts are a deploy substrate. fable-agent remains the attestation substrate.
Cloudflare temporary account: lets an agent deploy faster.
fable-agent receipt: proves whether that deploy should be trusted.
Required receipt boundary
Any temporary-agent deployment should attach an attestation before it is treated as done:
fable-agent verify . --out .fable/attestations/latest.json
For factory deploys, fable-agent still gates on the current verified route:
8099/deploy via git-proxy
Historical 8098 deploy-webhook memory remains context, not the deploy decision primitive.
Policy
Temporary deploy accounts must be treated as high-speed, low-persistence execution identities:
| Risk | Required fable-agent control |
|---|---|
| Ephemeral identity hides provenance | typed attestation receipt |
| Agent deploys faster than review | fail-closed deploy gate |
| Memory claims route health | live route check wins |
| Repeated known pattern | memory B cell cache can accelerate scan |
| New/unknown pattern | full scan slow path |
Quality rule
More deploy access requires stricter proof, not more trust.