Your first lap: understand what agent context includes
A coding agent can explain a project, edit files, and run commands. To do that, it collects context: your messages, file contents, search results, and command output. If a secret appears in any of those places, it can become part of a model request and may also appear in conversation history or logs, depending on the tool.
A .env file commonly holds API keys, database passwords, and service tokens. Your application may need those values at runtime. Your coding agent usually needs only the variable names and their purpose. The goal is simple: let the agent understand the configuration without handing it the credentials.
Keep .env out of Git and out of agent reads
Start by adding local secret files to .gitignore. Typical entries include .env and .env.*, with an exception for a deliberately sanitized .env.example. Check your project’s naming conventions before copying those patterns.
Git ignore rules are not an agent security boundary. They help prevent untracked files from being committed, but they do not automatically stop an agent from reading files through a terminal or another tool. They also do not remove secrets already tracked by Git.
- Check whether your agent supports file exclusions, read restrictions, command approvals, or sandbox controls.
- Configure those controls to protect your actual secret locations, including files outside the repository.
- Confirm whether exclusions cover direct reads, searches, terminal commands, and connected tools. Coverage varies.
- Test the setup with a harmless dummy value, never a live key.
A repository instruction saying “do not read .env” is useful guidance, but it is not enforcement. For stronger protection, run the agent in a workspace or container where real secrets are unavailable.
Give the agent a safe configuration example
Create a .env.example containing variable names and unmistakable placeholders. For instance, DATABASE_URL can contain YOUR_DATABASE_URL, and API_KEY can contain YOUR_API_KEY. Add a short explanation of each variable in your setup documentation.
Ask the agent to update this example whenever it introduces a new setting. Keep real values in an approved secret store or a local file the agent cannot access. Do not paste production credentials into chat to help it troubleshoot.
For SwiftRelay integrations, the agent can work with a placeholder key and the public API host, https://api.fastapirelay.com. Claude Code and Gemini CLI use the bare host; OpenAI-compatible SDKs use the host with /v1. The endpoint is configuration, not a credential.
Check terminal output before it becomes context
Blocking file reads is only part of the job. Commands such as printenv, broad file searches, and debugging scripts can expose credentials through their output. An application can also print connection strings or request headers when it fails.
- Use targeted searches rather than dumping entire directories.
- Review commands that inspect environment variables or configuration.
- Disable verbose logging that prints authorization headers or sensitive settings.
- Run agent-driven tests with dummy credentials, mocks, or a dedicated test account.
An agent can inherit secrets without opening .env. If you launch it from a shell containing exported credentials, its subprocesses may receive those values. Use a clean environment and pass only what the task requires. A test process using a credential does not mean the model needs to see it.
Rotate exposed keys before restarting the lap
If a real key enters a prompt, tool result, commit, or log, treat it as exposed. Revoke or rotate it first. Then remove accessible copies, inspect relevant usage records, and follow your team’s incident process. Deleting a message does not make the old credential safe again.
When connecting your tools, SwiftRelay is a pay-as-you-go option for Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for SwiftRelay when you are ready, and keep its key behind the same protections as every other credential.
Before giving the agent a task, check three things: real secrets are inaccessible, safe configuration examples are available, and test output stays clean. That is your green-light checklist.