## TL;DR

The agent inlined its wrangler API token into the worker source (as a constant, a default var, or a bundled config), and the deploy shipped the token to the edge where anyone can read the bundle. Revoke the token immediately, remove it from the source, redeploy clean, and set up the worker's real secrets through the secrets mechanism instead of the bundle.

## The query

```text
agent leaked its wrangler token into the worker bundle: the secret shipped inside the deployed script
```

## Use this when

- A deploy-time credential appears in the worker bundle or source.
- The token is visible in the deployed script.
- The agent 'helpfully' hard-coded a credential to make something work.

## Not for

- Secrets correctly set via the secrets mechanism (correct pattern).
- Tokens leaked in logs or chat (different containment).
- The worker needing the token at runtime for API calls (redesign, do not bundle it).

## Steps

### Step 1: Revoke the token NOW

In the Cloudflare dashboard, revoke the exposed token before doing anything else.

Expected result: the leaked credential is dead. Everything the token could do, it can no longer do.

### Step 2: Remove the token from the source

Delete the hard-coded value from the code and from version control history if it was committed. Purge it from any shared caches or artifacts.

Expected result: no copy of the token remains in the codebase. The leak source is gone.

### Step 3: Issue a fresh token with minimal scope

Create a new token with only the permissions the agent's work needs, scoped to the right account.

Expected result: the agent can work again with a credential that, even if mishandled, has limited blast radius.

### Step 4: Use the secrets mechanism for runtime secrets

Worker secrets are set via the secret commands and read from the environment bindings, never bundled into the script.

Expected result: runtime secrets live outside the bundle. The deployed script contains no credentials.

### Step 5: Redeploy clean and verify the bundle

Deploy the cleaned source, then inspect the deployed bundle for any credential remnants.

Expected result: the live worker contains no secrets. The incident is closed pending the retro.

## Why it happens

Agents optimize for 'make it work': a failing API call gets 'fixed' by hard-coding the credential that makes it succeed. The agent does not distinguish deploy-time credentials (used by wrangler, on the operator's machine) from runtime secrets (used by the worker, on the edge). The bundle is public-ish; anything in it is exposed.

## Edge cases

- Assume the token was exploited between leak and revocation. Audit API activity for the token's lifetime.
- The same mistake happens with .dev.vars files committed to the repo. Gitignore them and check history.
- If the worker genuinely needs Cloudflare API access at runtime, use a tightly-scoped token stored as a worker secret, never in the bundle.
- Add a pre-deploy scan for credential patterns in the bundle. Catch the next leak before it ships.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Grz6gYL9Tyo44I-H9kbvIQ