How to Keep API Keys and Passwords Away From Coding Agents

Before asking a coding agent to debug authentication, establish one rule: it should understand the configuration without seeing the credentials. This walkthrough builds toward that boundary by separating readable project files, executable tools, and authenticated services. OpenAI's security guidance makes the underlying distinction explicit: credentials injected into an execution environment remain accessible to agent-generated code.

Step One: Inventory Secrets Before Starting Your Agent

Start outside the agent session. List credential locations without copying their values: environment files, cloud profiles, package registry settings, private keys, database connection strings, and deployment configuration. Include the credential used to authenticate the coding client itself. OpenAI's Codex security cookbook specifically recommends restricting secret-bearing files and reducing inherited credential variables.

For each location, record whether the task needs configuration structure, authenticated execution, or neither. For an authentication bug, provide variable names, expected permissions, and a sanitized error rather than the live token.

Step Two: Replace Live Configuration With Safe Examples

Create an example configuration containing unmistakable placeholders such as DATABASE_PASSWORD=REPLACE_LOCALLY. Give the agent that file and a short description of required values. Keep live credentials outside the workspace that agent tools can access.

Add local secret files to .gitignore, but treat that as commit hygiene, not access control. Git documents that ignore rules concern intentionally untracked files and do not affect files already tracked. An ignore entry is therefore not evidence that a secret has disappeared from the repository.

Step Three: Enforce File Boundaries Beyond Agent Instructions

Configure explicit read restrictions before opening the session. In Claude Code, use permission rules for sensitive paths, but also enforce filesystem restrictions through sandboxing. Its documentation distinguishes tool permissions from operating-system boundaries; arbitrary subprocesses need stronger enforcement than a request not to read a file.

For a container-based workflow, mount only the required source directories. Do not automatically mount your home directory or credential stores. Gemini CLI supports sandboxing, but review the selected implementation and its configuration rather than assuming every sandbox provides identical isolation.

Step Four: Keep Authentication Outside Agent Execution

When authenticated operations are necessary, use a trusted service that performs narrowly defined actions. Let the agent request an operation, not retrieve a credential. OpenAI recommends keeping third-party credentials outside the execution environment and supplying authentication through a trusted proxy or application-side tool handler.

Restrict that service to approved destinations and operations. Return only the fields the task needs. Avoid an unrestricted forwarding endpoint: keeping the token hidden is insufficient if the agent can still use its authority for arbitrary requests.

Step Five: Separate Model Routing From Secret Protection

Apply the same boundary when configuring a model relay. BestRelay, this article's publisher, describes its quality-first service as forwarding each request to the official model named in it, without substitution. It supports Claude Code, Codex, Gemini CLI, and any OpenAI SDK, with its HTTPS API base hosted at api.bestapirelay.com.

Keep the relay credential in the trusted client or gateway configuration, not project documentation or prompts. Routing fidelity is a separate concern from credential isolation. BestRelay's pay-as-you-go billing uses provider-reported token counts, with cache reads and writes priced separately; members also earn referral commissions when invited users top up. Create a BestRelay account when you are ready to configure your client.

Step Six: Test Context Boundaries With Harmless Canaries

Before using live credentials, test with synthetic values that cannot authenticate anywhere. Try direct file reads, shell-based reads, and subprocess access. Check inherited variables and inspect the resulting transcript. Codex's security cookbook recommends synthetic-variable testing and warns that environment filtering alone is not an enforced credential boundary.

Repeat these checks after changing permissions, extensions, or execution environments. Define success explicitly: the task completes using placeholders or brokered operations, while protected values never appear in tool results or conversation history.

Step Seven: Revoke Exposed Credentials Before Cleaning Artifacts

If a real secret appears, stop the workflow and revoke or rotate it first. GitHub's remediation guidance puts credential revocation ahead of repository-history cleanup. Then investigate transcripts, logs, commits, and shared artifacts under your incident procedure. Deleting visible text does not invalidate the credential.

Make secret absence a tested property, not a prompting convention. Resume only after repairing the access path and repeating the canary checks.