Vault Tokenisation research
API not checked

Experiment 04 Security engineering Synthetic data only

Sensitive value, opaque token.

Replace a sensitive value with a random reference before it travels through the rest of your system.

Vault is a technical project for studying token boundaries, tenant isolation, and controlled reveal. It accepts synthetic test data only and is not production-ready.

Read the API Examine the method

01 / Method

A narrow tokenisation path.

One value enters the vault boundary. One unrelated reference leaves it.

  1. 01

    Caller / synthetic input

    { profile: "pii.email", payload: "…" }
  2. 02

    Vault boundary

    validate → encrypt → bind
  3. 03

    Caller / opaque output

    { token: "vlt_xK7…wQ" }

The token carries no original format or value. The illustrated payload and token are abbreviated synthetic examples.

02 / Security properties

Designed around narrow trust.

These are mechanisms implemented and exercised by the spike, not claims of certification or production assurance.

  1. P.01

    Opaque by construction

    Tokens use 192 random bits and do not preserve the input's shape, length, or semantic profile.

    Random reference
  2. P.02

    Context-bound protection

    AES-256-GCM protection binds ciphertext to tenant, token, profile, and key version as authenticated context.

    Authenticated encryption
  3. P.03

    Two client checks

    Protected operations require a registered mTLS identity and a fresh HMAC HTTP message signature.

    mTLS + HMAC
  4. P.04

    Scoped lifecycle

    Write, reveal, and delete actions are tenant-scoped, profile-aware, and tested for idempotent retry behavior.

    Least authority

03 / Input profiles

Validation at the edge.

Profiles constrain accepted synthetic inputs. Every successful profile returns the same kind of opaque vlt_ reference.

  • 01

    generic.opaque

    Arbitrary non-empty synthetic bytes for general integration exercises.

    ≤ 64 KiB
  • 02

    gift_card.number

    Constrained alphanumeric test identifiers, including hyphens and underscores.

    4–64 chars
  • 03

    loyalty.identifier

    Constrained loyalty references for synthetic customer-flow testing.

    4–64 chars
  • 04

    pii.email

    ASCII email-shaped fixtures with basic local and domain validation.

    ≤ 254 chars
  • 05

    payment.pan

    Luhn-valid payment-card-shaped test numbers. Never submit real account data.

    12–19 digits

04 / Integration

From trust to token in four steps.

The documentation is the source of truth for request and response contracts.

  1. 01

    Provision a test client

    Register a synthetic-use mTLS certificate and request-signing key.

  2. 02

    Select a profile

    Base64-encode a synthetic fixture that satisfies its input constraints.

  3. 03

    Sign and tokenise

    Send a fresh signed request and retain the returned opaque reference.

  4. 04

    Control the lifecycle

    Reveal only for an authorised purpose, or delete when the reference expires.

Inspect the exact schema, required signed headers, and synthetic request examples.

Open API reference