Running an AI coding agent on your own infrastructure does not, by itself, keep credentials out of model context. The relevant questions are what the agent process can read, what its tools return, and what an authorized command can do with a credential.
Does environment injection expose secrets to the agent?
It depends on which process receives the environment.
If you launch the agent with credentials already set, the agent and its children can inherit them. A tool that prints those variables can return them to the model. If a separate broker launches only an authorized child process with those credentials, the parent agent does not inherit them back.
This distinction applies when evaluating CLI wrappers as well as OpaqueVault. A command such as a secrets-manager CLI wrapping a test process does not automatically inject credentials into the agent that requested the command.
| Arrangement | Where plaintext is available | Boundary to examine |
|---|---|---|
| Agent launched with credentials | Agent and inheriting children | Shell access and tool output |
| Credentials injected into a separate child | That child and its descendants | Command permissions, logs, files and network |
| Authenticated request made by a broker | Broker and destination service | Broker policy, permitted operations and returned data |
| Secret value returned by a tool | Tool caller and potentially model context | Transcript and downstream retention |
Must a credential broker run locally?
No. A local broker can inject credentials into a local subprocess. A network broker can authenticate an upstream request without returning the credential to the agent. Fetching a raw value from a remote API and forwarding it to the agent is a different design.
For example, Infisical Agent Vault documents a forward-proxy model that attaches credentials to outbound requests. Its public page currently labels the product a preview. OpaqueVault is not the only product addressing agent credential isolation.
Choose the boundary that matches the workload. A local subprocess needs different permissions and controls from a remote HTTP request.
How does OpaqueVault handle local commands?
The local ov agent daemon performs secret operations, and ov mcp serve exposes the MCP interface. The agent requests a command and names the credentials it needs. The daemon injects those credentials into the launched process.
vault_run returns an exit code and run metadata. It does not return stdout or stderr through MCP; those go to the daemon terminal or agent log. The model can reason from the result without a value-returning secret tool.
This does not make arbitrary commands safe. A subprocess with a credential can use it, write it, or send it over the network. Local log access and other tools also matter. The interceptor is an additional detection layer, not a sandbox.
What does zero-knowledge storage add?
OpaqueVault encrypts secret data locally. The remote API does not receive the keys needed to decrypt secret values. It still handles operational metadata, including app and environment slugs and audit records.
Encryption of stored secrets protects a different boundary from credential brokering. A broker may hold plaintext while performing an operation even when the storage service lacks the decryption keys. Evaluate both parts of the design.
What should a self-hosted team check?
- Start the agent without unnecessary credentials in its inherited environment.
- Limit the credentials and permissions available to each operation.
- Inspect tool response schemas, logs, and files the agent can read.
- Restrict the actions and destinations a secret-bearing workload can reach.
- Verify runtime, authentication, and network requirements before planning an offline deployment.
A local daemon is not evidence that an entire service is air-gap compatible. See OpaqueVault’s agent documentation and security model when evaluating deployment requirements.
Updated October 23, 2026: corrected environment inheritance, removed unsupported market-wide claims, and distinguished local injection from network credential brokering.