Avoid it where you can. Anything stored as an environment variable in a sandbox can be read by any command the agent runs, and by anyone who can use that environment. If a secret is unavoidable, make it narrow, short-lived, and specific to the task, and prefer mechanisms that keep it out of the agent's reach.
What the documentation says
One hosted agent's documentation states that a session reads the environment's values into ordinary environment variables that any command the agent runs can read. It adds that anyone who uses the environment can read those values and that shared environments should not carry secrets in variables, because every member's sessions read them.
OWASP's secrets management guidance is blunt about the general case: environment variables are generally accessible to all processes and may be included in logs or system dumps, so they are not recommended unless other methods are not possible. For an agent, "all processes" includes whatever a prompt injection persuades it to run.
Decide by secret type
| Secret | Can the agent run without it? | Suggested handling |
|---|---|---|
| Source host token | Needed to push a branch | Let the platform proxy it, scope to one repository |
| Package registry token | Needed to install private packages | Setup phase only, read-only |
| Production credentials | Almost never | Do not provision |
| Third-party API keys for tests | Sometimes | Use a sandbox or test key |
| Model provider key | Platform handles it | Do not copy into the repo |
Safer patterns, in order
- Do not provide it. Mock the dependency, or use a test account.
- Use a proxy that adds the credential outside the sandbox. One platform describes a proxy that attaches a stored key to requests for hosts you list, after the request leaves the VM, so the key never appears in environment variables or files. The same page lists requests that never get the key, so read the exceptions.
- Issue a short-lived token. OWASP recommends dynamic secrets with short leases and revocation when no longer needed, plus rotation so stolen credentials work only briefly.
- Scope it. Least privilege, one repository, read-only if possible.
- Record it. Auditing should show who requested each secret and when it was used.
What a proxy does not solve
A proxy keeps the key out of the sandbox, but the agent can still make requests that the key authorizes. If a prompt injection tells the agent to call an allowed API with the attached credential, the credential works. So the permission scope is still the main control. Hiding the value protects against theft, not against misuse.
Clean up
Rotate any secret the agent could read once a task involving untrusted input ends, if the credential was broader than you meant. And check logs, since pipeline and session output can leak secrets. OWASP's CI/CD guidance says to make sure output does not.
Worked example: three ways to give an agent a package token
An illustrative case: the agent must install private packages from an internal feed during setup.
Option 1: environment variable. You add FEED_TOKEN to the environment. Setup uses it. The variable remains set for the agent phase, so any command can print it. A single line in a test script or an injected instruction is enough to read it. Anyone who can use the environment can also read it in its configuration.
Option 2: setup only token. You provide the token to the setup step as a build secret, and the setup step does not persist it. The agent phase starts without it. If the platform does not support that separation, you lose this advantage, so check.
Option 3: proxy that adds the credential. The agent's requests to the feed host go through a proxy outside the sandbox, which attaches the token. The agent never holds the value. If it is manipulated into calling the feed, the request still works, but the token cannot be copied out.
Option 3 is the strongest here, option 2 is a solid compromise, and option 1 is the weakest. Even with option 3, issue the token read only and for the one feed.
A scoring grid for any secret
| Question | If yes | If no |
|---|---|---|
| Does the task fail without it? | Provide it, narrowly | Do not provide it |
| Can a proxy attach it outside the sandbox? | Use the proxy | Next row |
| Can it be limited to the setup phase? | Do that | Next row |
| Is it short-lived? | Good | Issue a shorter lease |
| Is it scoped to one resource and read only? | Good | Narrow it |
| Is its use logged somewhere the agent cannot edit? | Good | Add logging |
Rotation and response
OWASP's guidance says rotation should be regular so stolen credentials work only briefly, and that restarting an application does not revoke stolen credentials. For agent sandboxes that suggests two habits.
- Rotate on a schedule for any long lived credential that an agent environment can use.
- Rotate after suspicious sessions. If a session processed untrusted content and had a credential in reach, assume it could have been read.
Detecting exposure
Look for the credential in session logs, command output, and pull request text. Use whatever secret detection you already trust for repositories and logs. Also watch the credential's own audit trail: unexpected source addresses, unusual hours, or calls outside the task scope all matter.
What to document
For each credential an agent environment can use, record the owner, scope, lifetime, how it is delivered, and how to revoke it. That record is what a security reviewer or customer questionnaire will ask for.
Where Safeguard fits
Safeguard gives AI agents their own identities, and policies and gates can control what they do. Keep using your existing secret management and detection tools for that. You can run a free dependency scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and note how an assistant gets its access, and ask what it would see if that access were an environment variable.
Quick check
Is a private repository setting enough to protect an environment variable?
No. The agent inside the sandbox can read it. Protect it with scope and lifetime.
Is a placeholder token safer than a real one?
If a proxy swaps the real value in outside the sandbox, the agent only sees the placeholder. Its requests can still use the real credential, so scope it.
What if a test really needs a live third party key?
Prefer a sandbox or test key from the provider. If only a live key works, scope it as tightly as the provider allows, keep it out of the agent's reach with a proxy, and rotate it after the task.
Sources
- Configure cloud environments (Anthropic documentation)
- OWASP Secrets Management Cheat Sheet
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
