06 · Vault
The core throws the original away. Sometimes you need it back.
This is the one place allowed to keep it, and it is built to make that hard.
The tension
Two good rules that contradict each other
The core's promise
It detects and redacts without ever storing the matched plaintext. A finding is a type and a range. There is nothing to steal, because nothing was kept.
The real requirement
An agent redacts a customer's card number, gets an answer, and now has to place the real order. Something, somewhere, has to put the value back.
The shape of it
Redact with a receipt
The approved value, to the approved destination
And nowhere else.
The central rule
A token alone grants nothing
The whole design depends on this rule. Holding the receipt does not entitle anyone to collect. At restore time, a server integration resolves who is asking and why from trusted runtime context, never from something the model said.
- Principal. Which authenticated identity is asking.
- Tenant. Cross-tenant lookups fail.
- Source. Where the capture came from.
- Sink and exact path. Which destination, and which structural field inside it.
- Purpose. What it is for, declared by the application.
- Liveness. Expiry, revocation, usage budget, and the exact issued tokens.
A trap it closes on purpose
A visible label is not a key
The core can format a typed placeholder from safe metadata, such as <JWT_1>, including PII types like <PII_JURISDICTION_US_SSN_1>. It is tempting to treat a label like that as proof the value was kept.
Grants nothing
A typed display placeholder, whether the core's own or an application label like <SSN_1>. It is a formatting concern. It does not imply the original was retained, or can be restored.
Grants a chance
An issued vault token, plus an application grant naming the sink and the exact path. Restoration never parses a display placeholder as proof of ownership.
Which matters because a model can write <SSN_1> into its output whenever it likes. Model output, tool arguments and visible placeholder text cannot authorize their own restoration.
What may be kept
Never everything
- Blocked
- A core
blockfinding, private-key material, can never become a restorable entry. Not opt-in, not configurable. - Other findings
- Require an explicit eligibility decision. Retention is opt-in, never a side effect.
- Personal data
- Retained only when the application names its exact type in the capture's allowlist,
pii: { retain: […] }. Every other PII finding becomes a display placeholder that cannot be restored.
The pieces
Two published, one research, one on paper
@redact-secret/vault
The portable piece: opt-in, bounded, in-memory capture and the token lifecycle. Qualified for Node.js 20/22/24 and the browser main thread, with an optional dedicated-Worker mode qualified separately. Worker mode is not an implicit upgrade, and the two modes' guarantees are documented apart.
@redact-secret/vault-server
The authority layer: principal, tenant, source, sink, path and purpose checks on every restore, with an in-memory backend built on the package above. Tested on Node.js 20/22/24.
redact-secret-vault (Python)
Research-grade. A native Python implementation of the same server authority contract, not of the portable vault API. It passes the shared conformance corpus against the real core through a documented Node.js service boundary.
@redact-secret/store-*
Persistent backends. A written contract exists; no implementation does. Persistence is a storage choice, not a third trust environment.
The npm names do not make this JavaScript-only. The server security contract is language-neutral, and Python, Rust and Go each need their own native distribution or a separately qualified service boundary.
Being honest