Deployed Worker secrets and local development credentials have different exposure paths. A hosted secret binding does not automatically protect a local file from an AI coding agent.
What do Worker secrets protect?
Cloudflare’s documentation describes encrypted secret bindings for Workers. After a secret is set, the dashboard and Wrangler do not expose its value for retrieval. The Worker itself can read and use that binding.
That last point matters: a value hidden from the management interface is still available to authorized runtime code. A Worker that logs or returns a credential can still expose it.
How does local development differ?
Cloudflare supports local secret configuration through files such as .dev.vars or .env. If an AI agent can read a file containing credentials, those values can enter its tool responses and model context. Keeping the file out of Git does not prevent local reads.
Follow the current local development guidance for the Wrangler version and workflow you use. Verify which environment variables your configuration exposes as Worker bindings.
Does a CLI wrapper expose secrets to the parent agent?
Not automatically. Environment inheritance goes from parent to child.
If a secrets CLI wraps wrangler dev, it injects credentials into that child process. It does not modify the environment of the parent agent that launched it. If the CLI instead launches the AI agent itself, that agent receives the injected environment.
This process distinction applies to Doppler, Infisical, 1Password CLI, and OpaqueVault. The remaining exposure depends on the command, its output, local files, and the agent’s other permissions.
Where does OpaqueVault fit?
OpaqueVault provides encrypted secret storage and local command execution through MCP. The agent requests a command using secret names; the local daemon injects the selected values into the child process.
vault_run returns the exit code and run metadata without stdout or stderr. Output is directed to the daemon terminal or agent log. This keeps that output out of the MCP response, while the authorized process still holds plaintext and must be trusted.
OpaqueVault is not a replacement for Cloudflare’s deployed secret bindings, and subprocess injection alone does not establish that a particular Wrangler configuration consumes the variables as bindings.
What should I check in an AI-assisted Worker project?
- Keep plaintext credential files outside the agent’s readable project where possible.
- Start the agent without unnecessary credentials in its inherited environment.
- Inject only the secrets required by an authorized command.
- Verify how the local runtime reads its bindings.
- Review command output, logs, and network behavior before exposing them to the agent.
- Configure production secrets separately through the deployment workflow.
See the OpaqueVault quickstart for the local daemon and MCP setup, and Cloudflare’s secret documentation for deployed bindings.
Updated October 23, 2026: corrected parent/child environment inheritance, removed exclusivity claims, and distinguished write-only management interfaces from runtime access.