Skip to content

guides

Intended Documentation

HashiCorp Vault Connector Setup (Beta)

Connect Intended to HashiCorp Vault (KV v2). Issue a scoped Vault token, paste your Vault address and token, and run Test connection. Self-hosted, so SSRF hardening (HTTPS required, metadata/link-local blocked) replaces a vendor host-pin. Beta until validated against your live Vault.

intermediate3 min readpartial
PartialSource: codeValidated: 2026-07-09

HashiCorp Vault Connector Setup (Beta)#

Connect Intended to HashiCorp Vault so approved intents can read and rotate KV v2 secrets through the real Vault adapter (packages/execution-engine/src/adapters/vault.ts). Every write is Authority-Token-verified and ESCALATEs for approval under the starter policy. Secret reads return metadata only — never plaintext secret material.

This connector is Beta

The adapter is real and covered by hermetic (mocked-HTTP) tests that pass in CI with no live tenant. Live proof against your real Vault is pending — treat Vault as Beta, not GA. See the Capability Truth Matrix.

What the adapter does#

PropertyValue
Actionsvault.secret.read (KV v2 read, metadata only), vault.secret.rotate (write a new version)
AuthVault token — X-Vault-Token: <vaultToken> (+ X-Vault-Namespace when set)
Host pinSelf-hosted — no vendor host-pin. SSRF hardening requires HTTPS, forbids embedded credentials, and blocks 169.254.169.254, metadata.google.internal, and any 169.254.*
Test connectionGET /v1/sys/health

Secret paths are normalized: empty paths, absolute http(s):// paths, and .. traversal are rejected, and each segment is URI-encoded. mount (default secret) and namespace are optional.

Provider-side steps#

1. Vault address (baseUrl, required)#

Your Vault server address, e.g. https://vault.your-org.com:8200. It must be HTTPS. Because Vault is self-hosted there is no fixed vendor domain to pin — but the address may not embed credentials or resolve to a cloud-metadata / link-local host.

2. Vault token (vaultToken, required)#

  1. Create a least-privilege Vault policy (below) and issue a token bound to it, e.g. vault token create -policy=intended-connector.
  2. Copy the token — it typically starts with hvs..
  3. Prefer a short TTL with renewal, or a periodic token, over a root token.

3. Optional fields (adapter-level, not in the console form)#

The adapter's credential schema also accepts two optional keys that the console connect dialog does not expose today:

  • mount — the KV v2 mount point if not secret (defaults to secret).
  • namespace — Vault Enterprise namespace, sent as X-Vault-Namespace.

If your secrets live on a non-default mount or in an Enterprise namespace, that configuration is not yet settable through the console form — plan for the default secret mount and root namespace, or track the field's addition to the manifest.

Least-privilege scope guidance#

Matrix capabilities: read:secret, write:secret. Grant a Vault policy scoped to only the target KV v2 paths:

hcl
# intended-connector policy (KV v2 at mount "secret")
path "secret/data/<app>/*" {
  capabilities = ["read", "create", "update"]
}
path "secret/metadata/<app>/*" {
  capabilities = ["read"]
}
path "sys/health" {
  capabilities = ["read"]
}

Do not issue a root token or a policy with wildcard path "*".

Fields to paste into the connect dialog#

Open Connectors → Connect a system → HashiCorp Vault → Configure auth:

Field labelKeyRequiredValue
Vault AddressbaseUrlYeshttps://vault.your-org.com:8200 (HTTPS)
Vault TokenvaultTokenYeshvs.… scoped token

Credentials are stored per-tenant, AES-256-GCM-encrypted, and never displayed back.

Run Test connection#

  1. Finish the connect wizard to store the credential.
  2. On the connector card, click Test connection.
  3. The adapter calls GET /v1/sys/health. A green result means the address passed SSRF validation and Vault is reachable.

Next steps#

HashiCorp Vault Connector Setup (Beta) | Intended