You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #715 / PR #1554 (store) and #1550 / PR #1582 (consumption), from the P1b design decision.
Problem
The hdb_secret store treats every row as sensitive: values are write-only through the operations API (never returned by reads), redacted in MCP audit surfaces, and read_audit_log is blocked for the table. That is the right default, but some configuration values are shared, non-secret settings (feature flags, service URLs, tuning values) that teams still want centrally stored, replicated, and delivered through the same env: declaration surface — without losing the ability to read them back in Studio/ops tooling.
Today the only options for non-secret values are inline literals in each component's env: block (not centrally managed) or storing them as secrets (write-only, so ops can't view/diff them).
Proposal
Add a sensitive: false flag on hdb_secret rows (default true, preserving current behavior):
sensitive: false rows store the value as plaintext (no enc: envelope required) and are readable back through the operations API (get_secret/list_secrets return the value) and Studio.
Redaction, audit-read blocking, and MCP default-deny continue to apply only to sensitive: true rows — audit redaction becomes conditional on the flag.
Flag flips: false → true is allowed (tightening). true → false must be rejected — the stored value was written under write-only expectations and must not become readable after the fact; require a new value write to downgrade.
Follow-up to #715 / PR #1554 (store) and #1550 / PR #1582 (consumption), from the P1b design decision.
Problem
The
hdb_secretstore treats every row as sensitive: values are write-only through the operations API (never returned by reads), redacted in MCP audit surfaces, andread_audit_logis blocked for the table. That is the right default, but some configuration values are shared, non-secret settings (feature flags, service URLs, tuning values) that teams still want centrally stored, replicated, and delivered through the sameenv:declaration surface — without losing the ability to read them back in Studio/ops tooling.Today the only options for non-secret values are inline literals in each component's
env:block (not centrally managed) or storing them as secrets (write-only, so ops can't view/diff them).Proposal
Add a
sensitive: falseflag onhdb_secretrows (defaulttrue, preserving current behavior):sensitive: falserows store the value as plaintext (noenc:envelope required) and are readable back through the operations API (get_secret/list_secretsreturn the value) and Studio.sensitive: truerows — audit redaction becomes conditional on the flag.env:declarations, grants/two-tier delivery) is unchanged: a declaration resolves the row the same way regardless of sensitivity.false → trueis allowed (tightening).true → falsemust be rejected — the stored value was written under write-only expectations and must not become readable after the fact; require a new value write to downgrade.Acceptance
sensitive: false; default remainstrue.true → falsetransition rejected without a new value.