.env vs Vaults: Should an AI Agent Ever See Your API Keys?

Secret managers get keys off disk. Credential brokers keep them away from the agent. How Agent Vault, Aembit, AgentCore, HashiCorp Vault, Doppler and 1Password compare.

env

Moving your keys out of .env is not the same as keeping them away from your agent.

"Replace .env" gets used for two different problems: where secrets are stored, and who holds them at runtime. Tools solve one, the other, or both. Pick by the problem you actually have.

Two patterns, not one

Secret manager. Stores and supplies secrets. Most still hand them to the process as environment variables or files. Doppler, 1Password and HashiCorp Vault fit here.
Credential broker. Sits between the agent and the service and attaches the credential to an approved request. The agent can make the call but never receives the key. Infisical Agent Vault, Aembit's MCP Identity Gateway and AWS AgentCore Identity take this approach, in different forms.

If your goal is "the agent must not be able to read our API keys," you need a broker. If your goal is "no plaintext keys on disk or in git," a secret manager is enough.

How brokering works

The details differ by product, but the shape is the same:

The real credentials live in the broker, not with the agent.
The agent gets a scoped, time-limited session or token.
Requests go through the broker, either as an HTTP proxy or an MCP gateway.
The broker checks the policy (host, method, path, or MCP tool), adds the credential, and forwards the request.

Caveats that apply to any broker

The agent's token is a capability. It is not the downstream key, but it grants whatever the policy allows. Treat it as sensitive.
Only brokered traffic is protected. A client that bypasses the proxy or gateway, or speaks a protocol it doesn't cover, is not.
Proxy-style brokers need setup. HTTPS interception requires a trusted CA, and the proxy belongs on a trusted network.
Authorized actions are still authorized. A broker limits what the agent can reach, not what it does with that access.

How the options compare

Option	Pattern	Does the agent get the real secret?	Best fit
Infisical Agent Vault	Broker: HTTP proxy with access bundles and time-bound sessions	No, for brokered requests. It gets a session token.	Agents calling HTTP APIs
Aembit MCP Identity Gateway	Broker: identity-aware gateway for MCP servers	Not the downstream credential. It holds a gateway token.	MCP-centric orgs wanting user-aware policy
Amazon Bedrock AgentCore Identity	Broker and token vault	Built to keep long-term secrets and refresh tokens away, but flows can return access tokens	Agents built on AWS AgentCore
HashiCorp Vault	Secret manager with dynamic credentials, leases and revocation	Depends on the integration. Vault Agent can inject into a child process's environment.	Policy-heavy teams with broad infrastructure
Doppler	Secret manager with runtime injection via `doppler run` or an ephemeral file	Usually yes. The process receives the values.	Replacing plaintext `.env` files
1Password CLI / Environments	Secret manager, loaded with `op run` or secret references	Yes with `op run`. The subprocess gets environment variables.	Teams already on 1Password

Doppler, 1Password and Vault can get plaintext off your disk. If the value is then injected into the agent's environment, the agent can still read it.

Is brokering the new standard?

No. It is an emerging pattern, and the products are young. .env is a file format for passing configuration, not an access-control system, and many applications will keep consuming environment variables while the source of those variables moves out of local plaintext files.

The shift that matters is from "give the agent a key" to "give the agent narrowly scoped, time-limited access through a broker."

A pilot for GitHub, Slack and other APIs

Pick a broker that fits your access path: an HTTP proxy for plain API calls, an MCP gateway if everything goes through MCP, or your cloud's agent identity service. Then:

Dedicated identity. Give the agent its own short-lived session, not a developer's personal token.
Narrow scope. Restrict by host, method and path, or by tool. Use read-only credentials when the task allows.
Control egress. Block direct outbound traffic so the agent cannot route around the broker.
Hide the broker's secrets. Keep its enrollment credentials and stored API keys out of the agent's reach.
Test your real toolchain. Confirm each client actually goes through the broker.
Clean up. Keep .env.example for variable names and non-secret defaults. Remove real keys from committed files, shell profiles and agent configuration.

This is the "leases, not keys" item from the Preflight Checklist made concrete.

The takeaway

Use a secret manager to get secrets off disk. Use a broker if you want the agent unable to read them. Agent Vault is one good example of the second kind, not the only one.