Hashicorp Vault

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.

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.

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.