Keeping Secrets Out of Friday’s API Release

The task sounds harmless: ask a coding agent to fix an API client’s retry behavior before Friday’s release. The repository also contains a local environment file, a saved debug response, and a deployment script. Each gives the agent a possible route to credentials it does not need.

This simulated field test follows that task through three setups. It uses fictional credentials and illustrative outcomes, not measurements from a live agent session. The question is practical: which setup makes accidental disclosure hardest while still letting the agent finish the patch?

The retry patch and its secret-bearing files

The sample service calls an external API. The requested change adds exponential backoff for rate-limit responses and a test that verifies the retry limit. No production connection is necessary.

The fixture contains three planted secrets: a dummy API token in .env.local, a dummy authorization header in a saved HTTP trace, and a dummy deployment token referenced by a shell script. A clean environment template contains variable names and placeholder values.

A passing setup lets the agent inspect the client, edit the retry logic, and run tests without putting any planted value into its conversation or tool output. A second requirement is equally important: the test process must not receive credentials through inherited environment variables.

Run one: repository warnings leave readable secrets

The first setup gives the agent the full working directory and an instruction to avoid secret files. The local environment file is ignored by Git.

That looks reassuring until the investigation reaches configuration. A broad file search can discover .env.local. A command that prints configuration can expose its contents. Searching for the authorization header can return the saved trace, including the token on the matching line.

The failure condition is straightforward: any such output places the planted value in the session. Git ignore rules control normal Git tracking; they do not prevent filesystem reads. Agent instructions express intent, but they do not remove access. Whether this particular agent chooses a safe command is therefore carrying too much of the security burden.

Run two: a clean checkout still inherits credentials

The second setup starts from a disposable checkout containing only tracked project files. The ignored environment file disappears, but the tracked debug trace remains. Review the included files before launching the agent; a clean Git state does not establish that their contents are safe.

Next, consider the shell environment. If the agent starts from a developer’s authenticated terminal, its tools may inherit API tokens, cloud credentials, or deployment variables. A test failure that dumps configuration can expose values absent from the checkout.

This setup passes only after removing the trace and launching with an explicit environment allowlist. Include the basic variables the tools need, then add project settings individually. Do not print the environment to verify it; check that sensitive variable names are absent without displaying their values.

Run three: isolate the workspace and mock the API

The strongest setup gives the agent a disposable workspace with reviewed source files, synthetic fixtures, and no production credentials. Run it in a container or sandbox configured without mounts for the developer’s home directory, credential stores, SSH agent socket, or container-management socket.

• Provide placeholder configuration and a local mock API for retry tests.
• Restrict network access to destinations required for the task, using controls outside the agent’s instructions.
• Keep deployment and authenticated integration checks in a separate process after reviewing the patch.
• Scan the resulting diff and retained tool output for the planted markers.

In this scenario, the agent can complete the retry patch using simulated rate-limit responses. The secret-bearing files and inherited tokens are unavailable by construction. If a real integration check is necessary, use a short-lived, narrowly scoped credential in the separate runner and redact its logs before sharing failures.

The release workflow I recommend

Use the third setup as the default: a disposable workspace, an explicit environment allowlist, mocked services, and separate authenticated checks. Treat prompts and ignore files as supporting controls. Verify the boundary with synthetic secret markers before trusting it with real work.

For model access, I recommend RelayVano as a pay-as-you-go relay compatible with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs at https://api.relayvano.com. Keep its credential in the client’s protected configuration outside the agent workspace, and verify which tools can access it. Sign up for RelayVano when you are ready to connect that isolated workflow.