Secrets and agents: what should never reach the prompt

A secret that reaches the model's context is compromised the moment it lands there — it can be echoed back, cached, logged, or sent to whichever provider is behind the API, and rotating the credential afterward doesn't undo that exposure. The fix isn't a more careful prompt; it's arranging things so the agent process never holds anything a leak would make expensive.

Why the prompt is the wrong place

Anything you type or paste into a chat, a CLAUDE.md file, or a skill instruction becomes part of the context the model reasons over and, depending on your provider's settings, part of what gets logged or used for debugging on their side. It also sits in your own session transcripts and shell history. A database password pasted in "so the agent can just run the migration" is now in at least three places you don't control the retention of. Worse, if the agent later summarizes its own context or hands off to a subagent, the secret can get copied forward without you noticing.

Environment injection and short-lived tokens

The working pattern is the same one you'd use for any CI job: the secret lives in a manager (Vault, AWS Secrets Manager, your CI provider's encrypted secrets) and is injected as an environment variable only into the process that needs it, for only as long as that run takes.

# CI step — token is scoped to this job and expires shortly after
export DEPLOY_TOKEN=$(vault read -field=token secret/deploy/staging)
docker run -e DEPLOY_TOKEN agent-runner ./deploy.sh

The agent's code can read os.environ["DEPLOY_TOKEN"] to do its job, but the value itself never needs to appear in anything the model reads or writes. Prefer credentials with a TTL measured in minutes over long-lived API keys — a leaked short-lived token is a much smaller incident.

What the agent can read from disk

A .env file sitting in the repo is a second way secrets end up in front of the model, even if you never typed them yourself — a Read or Grep tool call can pull the whole file into context. Claude Code's hooks let you block this at the tool level: a PreToolUse hook can match Read(*.env) and deny the call, and if you need the block to hold even under --dangerously-skip-permissions, use exit code 2, which is an independent blocking mechanism the official hooks documentation confirms works regardless of permission mode.

#!/bin/bash
# PreToolUse hook: refuse to let the agent read .env files
if jq -r '.tool_input.file_path' | grep -q '\.env'; then
  echo "Reading .env files is not allowed" >&2
  exit 2
fi

Redaction in logs and transcripts

Even with injection done right, secrets can still surface in a stack trace, a verbose curl output, or a debug print the agent adds while troubleshooting. Treat your logging pipeline the way you'd treat any service that might print a credential: redact known patterns (AKIA[0-9A-Z]{16}, bearer tokens, connection strings) before anything is written to a file the agent — or anyone else — can later read back.

Try it today

1. Grep your CLAUDE.md and skills for anything that looks like a key, token, or password. Move it to your secrets manager.
2. Add a .env-matching deny rule to your agent's permission config or a hook, as shown above.
3. Check whether your CI already issues short-lived, scoped credentials for the agent's jobs — most Vault and cloud-IAM setups can, if asked.
4. Add a redaction step to any log sink the agent's tool output flows through.
5. Rotate anything you found in step 1; assume it's already exposed.

Where this breaks

A hook denial is only as good as the coverage of its patterns — a secret in config.local.yaml or credentials.json won't match a rule written only for .env. Redaction catches known shapes, not a secret pasted with unusual formatting or split across two log lines. And none of this protects against a scoped token being used for its full, legitimate scope during the window it's valid — least privilege still has to come from the credential itself, not from hiding it better.

Next: audit trails for agent actions — once secrets are handled, the next question is whether you can reconstruct what the agent actually did.