# 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](https://blog.cloudflare.com/temporary-accounts/)

## Why it matters

This validates the market direction:

```text
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.

```text
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:

```bash
fable-agent verify . --out .fable/attestations/latest.json
```

For factory deploys, fable-agent still gates on the current verified route:

```text
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

```text
More deploy access requires stricter proof, not more trust.
```