AddThisFeature

Sensitive Data Masking

Show enough of a sensitive value to recognise it, and no more.

moderate Security & Reliability

What it adds

Server-side masking of sensitive fields so the full value never leaves the server, with a gated path to reveal it.

What your agent is told to do

6
  1. 1

    Inventory the sensitive fields first — emails, phone numbers, card numbers, API tokens, national identifiers, bank details — and classify each one.

  2. 2

    Mask at the point the value is serialised on the server. The full value must never be sent to the client and hidden with CSS; that is not masking, it is a suggestion.

  3. 3

    Write per-type rules: cards keep the last four, emails keep the first character and the domain, tokens keep a short prefix. A single generic rule makes some fields useless and others still identifying.

  4. 4

    Apply the same rules everywhere the value can escape: UI, API responses, CSV and PDF exports, application logs, error reports, and internal support tooling.

  5. 5

    Gate any full reveal behind an explicit permission plus recent re-authentication, and record who revealed what and when.

  6. 6

    Do NOT build a client-side show/hide control here — that is owned by Sensitive Field Reveal, which deliberately refuses to toggle server-masked values. This feature is what produces those masked values; the two must not overlap.

Edge cases it handles

7
  • Secrets shown once at creation (API keys) are a separate flow — masked afterwards, never retrievable.
  • Search and filtering must work against the real value server-side while still returning masked results, or the feature breaks the app.
  • Masking must be consistent across an entire response — one endpoint returning the full value undoes every other.
  • Log redaction must cover request bodies, query strings, and exception messages, which are where full values usually leak.
  • A reveal must be time-boxed. Do not leave the full value in client memory or in a cached response after the user moves on.
  • Some masks still identify: a partial phone number plus a name is often enough. Classify by risk, not by field name.
  • Support staff need a different mask level than customers. Make it a permission, not a separate hardcoded view.

Definition of done

8
  • No API response, export, or log contains a full sensitive value without an authorized reveal.
  • Each field type has a documented mask rule appropriate to it.
  • Masking is applied identically in UI, exports, logs, and support tooling.
  • Full reveal requires permission plus recent authentication and is recorded in an audit log.
  • Server-side search against real values still functions.
  • The client-side toggle remains owned by Sensitive Field Reveal.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.