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

Relationships

#1529 swamp vault put should support tags for secret governance

Opened by stack72 · 8/5/2026· Shipped 8/5/2026

Problem

When storing a secret with swamp vault put, there's no way to attach metadata tags to the secret. Organizations with governance requirements need to tag secrets with information like owner, team, environment, classification level, rotation schedule, or compliance framework.

Today, swamp vault annotate exists as a separate command to add annotations to vault keys after the fact. But this creates a gap — the secret is stored without tags, and the operator must remember to run a second command to add them. In a CI pipeline or automated workflow, this means two steps where one should suffice, and the secret exists untagged between the two calls.

Desired Outcome

swamp vault put accepts tags inline, following the same pattern as vault annotate:

swamp vault put my-vault api-key "secret-value" \
  --tag owner=platform-team \
  --tag environment=production \
  --tag classification=confidential \
  --tag rotation-schedule=90d

Tags are stored atomically with the secret — the key is never in an untagged state.

Design

CLI interface

Add a repeatable --tag flag to swamp vault put:

--tag <key=value>    Attach a metadata tag to the secret (repeatable)

Multiple tags via repeated flags:

swamp vault put my-vault db-password "s3cret" \
  --tag owner=dba-team \
  --tag env=prod \
  --tag rotate=quarterly

How it works

vault put currently calls vaultService.put(vaultName, key, value). The change:

  1. Parse --tag flags into a Record<string, string>
  2. After the put succeeds, call the annotation API to store the tags — same mechanism vault annotate uses
  3. If the put succeeds but annotation fails, warn but don't fail the command — the secret is stored, the tags are best-effort. Log which tags failed.

Alternatively, if the vault provider supports atomic put-with-metadata, use that path. But the annotation-after-put approach works with all existing vault backends.

Interaction with vault annotate

Tags set via vault put --tag are identical to tags set via vault annotate. They use the same storage mechanism, the same API, and are visible via vault inspect. There's no distinction between "put-time tags" and "annotate-time tags."

vault annotate remains for adding/updating tags after the initial put. vault put --tag is for setting tags at creation time.

JSON output

When --json is used, include the tags in the output:

{
  "vault": "my-vault",
  "key": "api-key",
  "status": "stored",
  "tags": {
    "owner": "platform-team",
    "environment": "production"
  }
}

Governance use cases

  • Ownership tracking: --tag owner=team-name — who owns this secret
  • Environment scoping: --tag env=prod — which environment this secret belongs to
  • Classification: --tag classification=confidential — data classification level
  • Rotation policy: --tag rotation-schedule=90d — how often the secret should be rotated
  • Compliance: --tag compliance=soc2 — which compliance framework requires this secret
  • Audit trail: --tag created-by=ci-pipeline — who/what stored this secret

These are all user-defined — swamp doesn't enforce any tag schema. The value is in the operator's ability to query and report on tagged secrets.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/5/2026, 5:20:37 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/5/2026, 12:50:58 PM

Sign in to post a ripple.