This article follows the official documentation. We haven’t tested this tool for a hands-on review.
A coding agent with shell access can use HashiCorp Vault CLI to read a development secret from a Vault server, such as an integration-test credential. Vault stores and controls access to secrets; the CLI signs in to the server and sends it requests to read secrets. The agent then sees any secret that the command prints.
After a client signs in, Vault issues an authentication token, a credential the CLI attaches to later requests. Keep the token out of the agent prompt, and give the agent access only to secrets it is allowed to process. The examples below follow HashiCorp’s Vault CLI documentation; they have not been installed or tested for this article.
Install and connect
On macOS with Homebrew, install Vault CLI using HashiCorp’s official installation instructions:
brew tap hashicorp/tap
brew install hashicorp/tap/vault
Set VAULT_ADDR to the URL of your Vault server, then check that the CLI can reach it:
export VAULT_ADDR="https://vault.example.com"
vault status
vault.example.com is a placeholder. Replace it with your organization’s Vault address. vault status contacts that server and reports its status; it does not read a secret.
Before the agent runs a secret-reading command, authenticate through an approved method. Vault supports methods such as OIDC, LDAP, and AppRole, but the Vault operator must enable and configure the method you use. The authentication documentation describes vault login and the method-specific values it needs. For example, vault login -method="$VAULT_AUTH_METHOD" uses the method name stored in that shell variable. The command does not supply any other values that method might require.
Have a developer or the execution environment handle authentication. Do not paste a Vault token into an agent prompt. After login, the CLI attaches the token to its requests. Vault tokens have a lease, a period after which they expire unless someone renews them or authenticates again. An expired token no longer authorizes requests.
Read a development secret
Vault’s key-value (KV) secrets engine stores static values such as API keys and passwords. In this example, secret is the KV mount, the path where the secrets engine is available. The rest of the path identifies one stored entry, or record. Both are placeholders; use the mount and path configured for your Vault instance.
vault kv get -mount=secret -format=json apps/payments/dev/integration
The CLI reads the secret without changing its stored value. The -mount flag names the KV engine, and -format=json asks the CLI to print JSON. With KV version 2, the secret values appear under data.data; metadata about the stored record appears under data.metadata. HashiCorp recommends KV v2 for static secrets, which keeps secret versions. See the KV secrets guidance.
The command prints the secret values to standard output, the shell’s output stream. An agent that runs the command can read those values, and the output may become part of its working context. Use a development credential that the agent is permitted to handle. Do not use this example to expose a production credential to an agent that does not need it.
For a coding task, give the agent a specific path and a bounded use:
Read the development integration secret at
apps/payments/dev/integrationwith Vault CLI. Use it to run the payment integration test. Do not print the secret or add it to files.
The command output reveals the credential to the agent, while the prompt contains no credential. If the agent should not see a secret value, do not ask it to retrieve that value with vault kv get.
Limit access to the needed path
Vault policies control which secret paths a token can read or change. Ask the Vault operator to issue an identity with read access only to the required development path; the CLI does not grant itself permissions. Vault’s KV guidance describes path organization, while the authentication documentation explains how Vault issues tokens.
Whenever the CLI reads a secret, it sends a request directly to the Vault server. A local command such as setting VAULT_ADDR only configures the CLI; vault status and vault kv get contact the server. If the token expires, the agent’s next request fails until an authorized person or environment renews the token or authenticates again.