How to Keep Secrets Away From an AI Coding Agent

Quick answer
The agent reads what is in its workspace and its environment, so a .env file is a secret the agent can copy into a message or a commit.
Run the agent with a scoped, short-lived token instead of your personal credentials.
Keep production secrets on the other side of a proxy or a secrets manager, not in the process environment.
Scan the diff and the logs for secret patterns before anything leaves the machine.
Assume anything the agent can read can end up in a prompt, a commit, or a log line.

Why is an agent different from a normal process?

A normal process reads a configuration value and uses it. An agent reads a file to understand context, then writes that content into messages, diffs, and summaries. A secret in a file it reads can be reproduced verbatim in a commit message or a tool call.

It can also be instructed to read it. A skill or a web page can tell the agent to inspect the environment, and the agent will comply because it is following instructions in its context.

What should be out of reach?

Production credentials, personal access tokens with broad scopes, private keys, and any .env file that holds values the agent does not need for this task. Also out of reach: the developer’s shell history, cloud credential files, and a browser session it could reuse.

The realistic setup is a development workspace with only the values needed to run the local stack: a local database URL, a test API key, a sandbox token. Production lives elsewhere.

# Keep secrets out of the workspace the agent can read
printf '.env
.env.*
secrets/
*.pem
' >> .gitignore
grep -RInE 'AKIA[0-9A-Z]{16}|sk-[A-Za-z0-9]|BEGIN (RSA|OPENSSH) PRIVATE KEY' . --exclude-dir=node_modules --exclude-dir=.git
# Give the agent a scoped token for the run, not your login
export GH_TOKEN="$(cat /run/secrets/gh_readonly)"

How do you give it what it needs without giving it secrets?

Use a proxy or a gateway that holds the credential and exposes a narrow operation. The agent calls create-ticket on the gateway; the gateway holds the token. The agent never sees the secret.

For infrastructure tasks, use short-lived credentials issued to the run, with an expiry measured in minutes or hours. If the agent needs to deploy, let the deployment pipeline hold the credential and the agent trigger the pipeline, rather than holding the deploy key itself.

How do you catch a leak after the fact?

Scan before commit and before push, and scan the session transcript if your harness stores one. A secret read into context has left the machine in a model request even if it was never committed, so treat the exposure as real and rotate.

Then remove it from history and invalidate it. Deleting the commit is not enough; a token that was used in a request should be rotated, because you cannot know where the transcript went.

Where this bites vibecoders
An agent asked to “make the API call work” will read .env, find the key, and paste it into a test file to debug. The key is now in the diff. Keep production values out of the workspace and use sandbox keys that are worthless outside it.

Where AI coding assistants get this wrong

Leaving a production .env in the working directory.
Letting the agent debug by hardcoding a key into a test.
Giving the agent a personal token with organisation-wide scope.
Putting secrets in AGENTS.md or a skill “for convenience”.
Assuming .gitignore prevents the secret from entering a prompt.
Rotating the token but not checking where it was used.

Checklist

Remove production values from the workspace.
Issue a scoped token per run with an expiry.
Put third-party credentials behind a proxy.
Scan the diff for secret patterns before commit.
Treat a secret read into context as exposed.
Rotate and remove from history if a leak occurs.

FAQ

If the file is gitignored, is it safe?

No. Gitignore stops a commit, not a read. The agent can read the file, include it in a message, and a model provider may retain the request. The only safe assumption is that anything readable can be transmitted.

Should I disable shell access for the agent?

That removes a lot of usefulness. A better trade is a sandbox with a restricted environment: a shell that cannot reach production credentials, with network egress limited to what the task needs and a token that expires.

What about test API keys?

Use keys issued for a sandbox account that cannot touch real data, and rotate them on a schedule. A test key in a test file is still a leak if the account behind it has any privilege.

How do I handle a secret that was already exposed?

Rotate first, then clean history, then check the logs for use. The order matters because removing a commit does not un-send a request. If the key was in a transcript, treat it as compromised regardless of the repository state.