Hashicorp Vault
HashiCorp Vault secrets management via REST API (KV v1 and v2). Emits OpenTelemetry spans for get, put, and list, with one child span per request in the recursive list walk, so vault reads are visible in traces including reads during model and workflow runs where the host emits nothing. Span attributes carry the vault name, key name, and KV version only — never secret values, tokens, or error messages.
2026.10.21.1
Changed: The README's configuration example no longer shows a literal
token: in the vault config. A new Authentication section leads with
vault login, which stores the token in ~/.vault-token where the provider
reads it, and warns against putting a literal token in the config or relying on
VAULT_TOKEN. The token config field description and the "No Vault token
found" error message now say the same; the error text changed, so update
anything that matches on its old wording.
Fixed: Tracing spans reported a stale instrumentation version
(2026.08.20.1) instead of the published version. The tracer version now
matches manifest.yaml, and a test fails if the two drift apart again (the
test task in deno.json now grants read access to manifest.yaml for it).
Fixed: The model-definition example used {{ vault('hashi', ...) }}, which
is not swamp syntax and never resolved to the secret: swamp rejects a literal
value for an argument marked sensitive, and passes it through as literal text to
one that is not. It now uses ${{ vault.get("hashi", "...") }}. The
swamp vault read-secret --force example now warns that it prints the plaintext
value.
Upgrade note: The token resolution order is unchanged (config token, then
VAULT_TOKEN, then ~/.vault-token), so existing setups keep working.
HashiCorp Vault secrets management via REST API
Config Fields
| Field | Type | Description |
|---|---|---|
| address | string | Vault server address (e.g., https://vault.example.com:8200) |
| token? | string | Vault authentication token. Leave this unset and run `vault login`, which |
| mount? | string | Secrets engine mount path |
| kvVersion? | enum | KV secrets engine version |
| namespace? | string | Vault namespace (Enterprise only) |
2026.10.14.1
Added: The manifest now declares license: Apache-2.0 (SPDX). The registry quality rubric scores a declared license separately from the bundled LICENSE.md.
Upgrade note: Metadata only. No code, schema, or behavioral changes.
2026.09.18.1
Upgrade note: Normalized npm:zod dependency version to 4.6.5 across the
repo. No behavioral changes in this extension.
2026.09.18.1
Upgrade note: Normalized npm:zod dependency version to 4.6.5 across the
repo. No behavioral changes in this extension.
2026.09.15.1
Changed: Bump zod 4.4.3 → 4.6.5
2026.08.28.1
Changed: Normalized the extension license to Apache-2.0 and corrected the copyright holder to "Sean Escriva". Extensions that previously shipped an MIT LICENSE.md are now Apache-2.0, consistent with the repository root and every other extension. No code or behavioral changes.
Upgrade note: License text only. No API, schema, or runtime behavior changed.
2026.08.26.3
Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry
quality scorer can resolve dependencies and score the extension. An earlier
release used a bare "zod" import-map specifier, which published but scored as
unscored.
Changed: Retained explicit compilerOptions.strict in deno.json. No
behavioral or schema changes.
2026.08.28.1
Changed: Normalized the extension license to Apache-2.0 and corrected the copyright holder to "Sean Escriva". Extensions that previously shipped an MIT LICENSE.md are now Apache-2.0, consistent with the repository root and every other extension. No code or behavioral changes.
Upgrade note: License text only. No API, schema, or runtime behavior changed.
2026.08.26.3
Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry
quality scorer can resolve dependencies and score the extension. An earlier
release used a bare "zod" import-map specifier, which published but scored as
unscored.
Changed: Retained explicit compilerOptions.strict in deno.json. No
behavioral or schema changes.
2026.08.26.3
Fixed: Restored inline npm:zod@4.4.3 import specifiers so the registry
quality scorer can resolve dependencies and score the extension. An earlier
release used a bare "zod" import-map specifier, which published but scored as
unscored.
Changed: Retained explicit compilerOptions.strict in deno.json. No
behavioral or schema changes.
2026.08.26.1
Changed: Normalized deno.json configuration for repo-wide consistency:
added explicit compilerOptions.strict and migrated zod dependency to the
import map (bare "zod" specifier instead of inline npm:zod@4.4.3). No
behavioral changes — runtime resolution is identical.
2026.08.25.1
Changed: Updated labels for improved extension discoverability. Added cross-cutting category labels (security, observability, finops, infrastructure, networking, compliance, devops, ai, incident-response) where applicable.
updated labels
2026.08.23.1
Fixed: README's Usage section documented invented CLI flags/subcommands
(--vault, --key, --value) that don't exist. Corrected to the real
swamp vault put/read-secret/list-keys command forms.
Changed: Documentation only — no code changes otherwise. Added a
## Troubleshooting section covering the three-source token resolution
error message from resolveToken, vaultFetch's network-vs-HTTP error
distinction, the KV v1/v2 nesting mismatch that produces a false "not
found," assertSafeKey's path-escape checks, the silent
MAX_DEPTH/MAX_KEYS list truncation (only visible via a span attribute),
and how Vault's own JSON error array surfaces through handleResponse.
2026.08.21.1
Changed: Network-level failures (DNS resolution, connection refused, TLS
errors, timeouts) talking to the Vault server now surface as
Vault <get|put|list> request failed (key: <key>): could not reach <url>: <reason> instead of a bare, context-free fetch error. Previously, only
non-2xx HTTP responses were wrapped with the operation and key that was
being attempted — an unreachable server produced a raw runtime error with
no indication of which vault call or key triggered it. HTTP-level failures
(4xx/5xx responses from Vault itself) are unchanged.
2026.08.20.1
Upgrade note: Bumped zod from 4.3.6 to 4.4.3. No behavioral changes — dependency version alignment only.
2026.07.30.1
Added: Documentation of empirically verified OTel trace safety properties. The README now states that the no-token/no-body guarantee was confirmed against swamp 20260725 + Deno 2.7.14, identifies the condition under which it could break (Deno fetch auto-instrumentation activation), and links to the full probe methodology in issue #276.
Added: Maintainer reference at docs/otel_verification.md covering the
probe environment, results, residual risks, and a re-verification schedule tied
to swamp runtime version bumps. This file is repo-only and does not ship with
the published extension.
2026.07.27.1
Changed: Bump @opentelemetry/api 1.9.0 → 1.9.1
2026.07.26.2
Added: OpenTelemetry spans on get, put, and list, plus one child span
per HTTP request inside the recursive list walk. Span names are Vault get,
Vault put, Vault list, and Vault LIST for the child requests. Attributes:
vault.name, vault.secret_key, vault.kv_version, rpc.system,
rpc.service, rpc.method, vault.keys_returned on list,
vault.truncated on list when the depth or key cap stopped the walk, and
vault.list_depth on each child request.
This closes a real observability gap rather than duplicating the host. swamp
emits swamp.vault.* spans when a human runs a swamp vault subcommand, with
no attributes at all — and emits nothing when a model or workflow resolves a
vault expression. A secret read during a run was invisible in traces. These
spans appear on both paths.
The extension uses @opentelemetry/api only and never constructs a
TracerProvider. With no provider configured the tracer is a no-op and the cost is
a few property lookups.
Changed: Error messages no longer echo a submitted secret value. If Vault
rejects a write and quotes the value back in its errors array, that value is
replaced with [redacted] before the message is thrown. This matters because
the swamp host publishes thrown error messages into its own span as a status
description, an exception.message, and a stack trace — so an echoed value
reached the trace backend regardless of what this extension recorded.
Changed: list now reads and discards the response body on a 404 instead of
dropping the Response unread, which leaked a connection per missing path.
Note on what spans deliberately omit: spans record error.type and an ERROR
status on failure, and never recordException and never a status description. A
vault error message is built from output this extension does not control, and the
host already publishes it once. Recording key names is intentional — a vault span
without the key is close to useless for debugging — so treat key names as visible
to anyone with access to your trace backend and do not encode sensitive
information in them.
2026.07.26.2
Added: OpenTelemetry spans on get, put, and list, plus one child span
per HTTP request inside the recursive list walk. Span names are Vault get,
Vault put, Vault list, and Vault LIST for the child requests. Attributes:
vault.name, vault.secret_key, vault.kv_version, rpc.system,
rpc.service, rpc.method, vault.keys_returned on list,
vault.truncated on list when the depth or key cap stopped the walk, and
vault.list_depth on each child request.
This closes a real observability gap rather than duplicating the host. swamp
emits swamp.vault.* spans when a human runs a swamp vault subcommand, with
no attributes at all — and emits nothing when a model or workflow resolves a
vault expression. A secret read during a run was invisible in traces. These
spans appear on both paths.
The extension uses @opentelemetry/api only and never constructs a
TracerProvider. With no provider configured the tracer is a no-op and the cost is
a few property lookups.
Changed: Error messages no longer echo a submitted secret value. If Vault
rejects a write and quotes the value back in its errors array, that value is
replaced with [redacted] before the message is thrown. This matters because
the swamp host publishes thrown error messages into its own span as a status
description, an exception.message, and a stack trace — so an echoed value
reached the trace backend regardless of what this extension recorded.
Changed: list now reads and discards the response body on a 404 instead of
dropping the Response unread, which leaked a connection per missing path.
Note on what spans deliberately omit: spans record error.type and an ERROR
status on failure, and never recordException and never a status description. A
vault error message is built from output this extension does not control, and the
host already publishes it once. Recording key names is intentional — a vault span
without the key is close to useless for debugging — so treat key names as visible
to anyone with access to your trace backend and do not encode sensitive
information in them.
updated labels
2026.07.26.1
Fixed: Keys were interpolated into the request path unvalidated and
unencoded, so get("../../sys/health") left the configured mount and reached a
different Vault API entirely — secret/data/../../sys/health is not the secret
the caller asked for. Keys containing . or .. path segments, empty path
segments (a//b, trailing/), absolute keys, and empty keys are now rejected.
Fixed: Key path segments are percent-encoded. A key containing a space, a
?, or a # previously changed the request path or started a query string, so
the secret written and the secret read back could be different entries.
Fixed: list built its recursive request paths from Vault's own directory
names without encoding them, so a directory containing a ? or # truncated
the path and the keys beneath it were silently missed.
Upgrade note: If you store keys containing characters that require encoding and have been relying on the previous unencoded behaviour, the encoded path is a different Vault path. Read such secrets with the old version and re-write them with this one.
2026.07.18.1
Changed: Version bump only, no code changes.
- Has README or module doc2/2earned
- README has a code example1/1earned
- README is substantive1/1earned
- Most symbols documented1/1earned
- No slow types (deprecated)1/1earned
- Dependencies pass trust audit2/2earned
- Has description1/1earned
- Platform support declared (or universal)2/2earned
- License2/2earned
- Verified public repository2/2earned