Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLITeam
Assigneesstack72

Relationships

#1420 No way to select which vault receives a sensitive-marked field's value

Opened by magistr · 7/26/2026· Shipped 7/27/2026

A resource field marked sensitive: true causes the runtime to store the real value into "the serving repo's vault" and persist a ${{ vault.get(...) }} redirect. There appears to be no way to say WHICH vault.

Why it matters

A repo can legitimately need two vaults with different trust levels — one holding operator-only bootstrap credentials, another for values a long-running service generates at runtime. Because both are just "the repo's vault", runtime-generated material lands in whichever vault the selection rule picks, potentially alongside higher-privilege material and behind the same encryption key.

Observed selection rule

Determined empirically in a scratch repo: with two local_encryption vaults and a model whose sensitive field declares no preference, the value landed in the more recently created vault. Adding a third vault that was alphabetically first but chronologically last moved the value to it. So the rule appears to be most-recently-created wins.

That is difficult to rely on, because vault creation order can differ between a development machine and a deployed host — the same repo can route sensitive values to different vaults in each environment, with no local signal that it will.

What I looked for and did not find

  • swamp serve — no vault option in its flag set.
  • swamp vault — no rename, no set-default. migrate documents "The vault name stays the same" and requires source and target types to differ, so it can neither rename nor re-home within one type.
  • .swamp.yaml — no vault field.
  • swamp vault search --json / vault get — no default or primary marker; sibling vaults are structurally identical.
  • Model surface — no vault-selection argument; the vault reference documents vaultName for output schemas only.

Ask

One of:

  1. A documented way to direct a sensitive field's storage to a named vault (e.g. vaultName on the spec or field).
  2. A repo-level setting for which vault receives sensitive storage, so vaults of differing trust can coexist.
  3. If a mechanism exists and I missed it, a pointer — the search paths above all came up empty.

Separately: it is unclear whether sensitive METHOD ARGUMENTS are vaulted at all, and if so whether the same selection question applies. The documented vaultName override covers output schemas only.

Environment

swamp 20260725.011748.0-sha.bb2cb3ef, macOS.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 7 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/27/2026, 2:15:07 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/26/2026, 10:51:15 PM
Editable. Press Enter to edit.

stack72 commented 7/27/2026, 2:15:18 PM

Thanks @magistr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.