Skip to main content
Connect your HashiCorp Vault cluster to enable Oliver (Security Professional) to read KV secrets, retrieve dynamic database and cloud credentials, and inspect policies, tokens, audit devices, and cluster health — all through the vault CLI running in CloudThinker’s secure sandbox.
Requires a Vault instance reachable from CloudThinker over HTTPS — self-hosted (open-source or Enterprise), or HCP Vault Dedicated. Authenticate with a Vault token or an AppRole (Role ID + Secret ID).

​
Supported Platforms

PlatformSupport
Vault open-sourceSelf-hosted, recent releases
Vault EnterpriseNamespaces supported
HCP Vault DedicatedSet namespace (default admin)

​
Prerequisites

  1. A reachable Vault address — the sandbox connects to VAULT_ADDR over the network, not your laptop. Use a public DNS name or HCP endpoint, not localhost or a private address the sandbox cannot route to.
  2. Credentials — a Vault token, or an AppRole (role_id + secret_id), backed by a policy that grants read access to the paths you want agents to query.
  3. (Enterprise / HCP only) the namespace the secrets live in.

​
Setup

Choose the authentication method that fits your deployment. AppRole is recommended for production because the secret_id can be rotated without replacing a long-lived token.
1

Write a Read Policy

Grant read access to only the paths CloudThinker should reach:
vault policy write cloudthinker-read - <<EOF
path "kv/data/*" {
  capabilities = ["read", "list"]
}
path "kv/metadata/*" {
  capabilities = ["list"]
}
EOF
2

Create a Token

Bind a token to that policy:
vault token create \
  -policy=cloudthinker-read \
  -ttl=720h \
  -display-name=cloudthinker
Copy the token value from the output.
3

Add Connection in CloudThinker

Navigate to Connections → HashiCorp Vault and enter:
  • VAULT_ADDR: your Vault URL including scheme and port, e.g. https://vault.example.com:8200
  • VAULT_NAMESPACE: leave blank for open-source Vault; set it for HCP (admin) or Enterprise namespaces
  • VAULT_AUTH_METHOD: Token
  • VAULT_TOKEN: the token from the previous step
CloudThinker runs a health check the moment you save: a token connection verifies the token with vault token lookup, and an AppRole connection performs an auth/approle/login and confirms a client token is returned. A green Connected badge means the check passed. Tokens and secret IDs are redacted from any error message.

​
Connection Fields

FieldRequiredNotes
VAULT_ADDRYesFull URL including scheme, e.g. https://vault.example.com:8200
VAULT_NAMESPACENoHCP Vault Dedicated (admin) and Vault Enterprise namespace deployments only
VAULT_AUTH_METHODYestoken or approle
VAULT_TOKENToken authShown when the auth method is Token
VAULT_ROLE_IDAppRoleShown when the auth method is AppRole
VAULT_SECRET_IDAppRoleShown when the auth method is AppRole

​
Agent Capabilities

What an agent can do is bounded by the policy attached to your token or AppRole — Vault’s default-deny always applies, so an agent can never exceed those permissions. On top of that, CloudThinker splits operations into two scopes: read-only actions run automatically, while any action that mutates Vault or issues a lease requires your approval. Read — auto-approved:
  • Read KV secrets — get and list KV v1 / v2 secret paths and values
  • Inspect health & topology — check sys/health, mounted secret engines, and auth methods
  • Audit tokens & policies — look up the current token’s policies and TTL, list and read policies, list audit devices
Write — requires approval:
  • Issue dynamic credentials — generate short-lived database (database/creds/*) and cloud (aws/creds/*) credentials; these create a lease, so they are write-gated even though they read
  • Manage KV secrets — put, delete, and destroy secret versions
  • Manage leases — revoke or renew leases
  • Administer Vault — write policies, enable or disable secret engines, auth methods, and audit devices

​
Example Prompts

@oliver list the secrets under the kv mount
@oliver read the database config secret at kv/myapp/config
@oliver show Vault health, seal status, and version
@oliver audit the current token — what policies and TTL does it have
@oliver list all mounted auth methods and audit devices
@oliver issue a short-lived readonly database credential and give me the lease id

​
Troubleshooting

The vault CLI runs inside CloudThinker’s sandbox, not on your machine. localhost, 127.0.0.1, and host.docker.internal resolve to the sandbox itself and fail with dial tcp ... no such host or connection refused. Point VAULT_ADDR at an address the sandbox can route to — a public DNS name or HCP Vault Dedicated. A Vault behind a firewall or VPN must be exposed through a public endpoint, an allowlisted egress, or a network bridge first.
vault needs the full URL including scheme. vault.example.com:8200 (no scheme) causes a connection error. Use https://vault.example.com:8200, or http://... for a dev-mode server.
The token or AppRole policy does not grant access to the requested path — not that the secret is missing. Check the policy with vault token lookup and ensure it covers the paths the agent queries. For example, to read kv/data/production/* the policy needs capabilities = ["read", "list"] on that path.
HCP Vault Dedicated and Enterprise multi-namespace deployments require VAULT_NAMESPACE. For HCP the default is admin. If you see no handler for route or permission denied on HCP or Enterprise, confirm the namespace is set.
A secret_id has a TTL (secret_id_ttl). Once it expires, auth fails with invalid secret_id. Generate a new one, update VAULT_SECRET_ID, and reconnect:
vault write -f auth/approle/role/cloudthinker/secret-id
vault status shows Sealed: true and no operation will succeed. A Vault operator must unseal the cluster (vault operator unseal) before agents can read or write.

​
Security Best Practices

  • Least privilege — scope the policy to the minimum paths the agent needs; add create/update only if you want write flows.
  • Prefer AppRole in production — rotate the secret_id without replacing a long-lived token.
  • Short TTLs — keep token and secret_id lifetimes tight and refresh them on a schedule.
  • Approval on writes — leave write operations gated so credential issuance and mutations always require a human.

Oliver Agent

Security and compliance agent

Approval Controls

Gate write operations behind approval