Secrets management for AI agents: keys, .env files and logs
Stefan-Iulian Tesoi · · 6 min read
Keep long-lived secrets out of the environment the agent runs in. Give it short-lived credentials scoped to the one task, keep real values out of the .env files it can open, and scan everything it writes, transcripts included, because anything a coding agent reads can end up in its output.
Secrets management for AI agents differs from the human version in one respect. A developer who reads a key does not usually paste it into the next thing they write; an agent will, if the key is in its context and the task seems to call for it. GitGuardian's State of Secrets Sprawl 2026 found commits co-authored by Claude Code leaking secrets on public GitHub at about twice the baseline rate.
What does secrets management for AI agents have to cover?
Three things a policy written for people assumes and an agent breaks: what it can read, what it writes, and what gets recorded along the way.
What it can read is wider than the repository. Every environment variable in the agent's process, every file under the working directory, the credential files in a home directory such as ~/.aws/credentials and ~/.npmrc, and the output of every command it runs. An agent that runs env to debug a failing test has read the lot.
What it writes is everything that leaves the session: commits, test fixtures, pull request descriptions, issue comments.
What gets recorded is the part most teams forget. Claude Code keeps each session as a plain-text JSONL file under ~/.claude/projects for 30 days by default, tool output included. CI keeps job logs. The model provider receives the whole context with every request.
GitGuardian counted 28.65 million new secrets in public GitHub commits in 2025, up 34% on the year, and secrets for AI services rose 81% to 1,275,105.
Which credentials does an agent actually need?
Usually none of production's. A coding agent needs what the test suite needs, and a test suite that needs a production key is the first thing to fix.
| Credential | Does the agent need it? | What to give it instead |
|---|---|---|
| Production database URL | No | A local or seeded test database |
| Model or payment provider key | Only for an integration test | A sandbox key in a separate account with its own spending cap |
| Cloud credentials | Only for infrastructure work | A short-lived role session in one account |
| Git token | Yes, for its own branch | A fine-grained token for one repository, with an expiry |
| Backlog token | Yes, to fetch and hand back work | A per-person or per-project grant |
The spending cap row comes from our own repository. The model provider key in a developer's local .env file belonged to the same organisation as production. In October 2026 a local evaluation run hit that organisation's monthly spending cap, and production's calls to that provider started failing with 402 Payment Required. Nothing leaked, and nothing needed to. A long-lived key shared between a test run and production makes the test run part of production.
AI agent API keys follow the same rule as the table: a separate key per environment, scoped to what that environment does, so an agent's mistake can only spend its own budget. What permissions a coding agent should have sets out the same least-privilege line for the backlog connection itself.
Where do secrets leak from an agent session?
From four places, and only one of them is the repository:
- Command output.
printenv,cat .env,docker inspectand a failing test that prints its configuration all put values into the model's context, where they are sent to the provider and can be repeated in anything the agent writes next. - Files it writes. A fixture holding a real token, a debug script with the key inlined, a "temporary" config committed alongside the fix.
- Text it posts. Pull request descriptions, commit messages and issue comments. In one published demonstration, instructions planted in an issue got an agent to write a key and a token into the issue body.
- Transcripts and logs. Session files on the developer's disk, CI job logs, and whatever the provider retains.
Secret scanning has to cover all four, not only commits. gitleaks runs as a pre-commit hook for the second, and gitleaks dir ~/.claude/projects checks the last 30 days of Claude Code transcripts in one command. GitHub's push protection backstops pushes and nothing else.
How do you issue short-lived, scoped credentials per task?
Resolve secrets at the moment a command runs, for that command only, and make every credential expire.
- References, not values. Env file security starts with what is in the file. With 1Password, the .env file holds
op://references, andop run --env-file=.env -- pnpm testresolves them into that one process; secrets the command prints to stdout or stderr are concealed by default. Masking covers what a command prints, not what it writes to a file. - Dynamic secrets. HashiCorp Vault's database secrets engine creates a database user on request with a lease, and revokes the user when the lease ends. A credential that lives for an hour is worth little a week later in a transcript.
- Federation in CI. OIDC lets a pipeline exchange its identity for a cloud session, so no stored cloud key exists to leak.
- A read block, understood for what it covers. A
Read(./.env)deny rule in Claude Code blocks its file tools and commands it recognises, such ascat. The Claude Code permissions documentation is explicit that it does not stop a Python or Node script opening the file itself, and points to the sandbox for OS-level enforcement.
The same applies to the tools an agent connects to. A Laimonade connection can sign in as the person driving the agent instead of using the project API key, which keeps a key out of the agent's configuration altogether and records the work under that person's name.
What do you do once a secret has been exposed?
Rotate it. Deleting the line, squashing the commit or rewriting history does not take the value back from a transcript, a CI log or a provider's request logs.
A secret that entered a model's context has left the machine. Treat "the agent saw it" as an exposure, not a near miss.
Remediation is where most teams stop short: GitGuardian found 64% of valid secrets detected in 2022 still active. The order that works is to revoke and reissue at the issuer, check the issuer's usage log for the exposure window, find every copy, and close the route it took so the next session cannot repeat it. The coding agent security pillar covers what else a credential should be unable to reach, and the provider's retention period is one of the data-handling questions to ask an AI vendor.
Frequently asked questions
Is an .env file listed in .gitignore safe from an agent?
No. A .gitignore entry keeps a file out of commits, not out of reach, and an agent working in that directory can open it with any tool it has. Keep values out of the file by storing references resolved at run time, or keep the file outside the agent's working directory and block reads with a deny rule.
Should several agents share one service token?
No. A shared token makes every action look like one actor, so an incident cannot be traced to the session that caused it, and revoking the token stops every agent at once. Issue one credential per agent, or per person driving it, scoped to the repositories and projects that task needs, with an expiry in hours or days.
Do agent transcripts need secret scanning?
Yes. A transcript records tool output verbatim, so a printed environment or a test that dumped its configuration sits on disk in plain text. Claude Code keeps sessions for 30 days by default, and one gitleaks dir run covers that directory. Anything found there was also sent to the model provider, so rotate it rather than deleting the file.