Start here: nothing changes for your application unless you choose it.For any field type you protect, your own API keys receive the real value by default, so the text your app reads back is identical to what it reads today. Request and response shapes do not change. There is no new SDK call to make, and no code to write.Two settings do change what your app receives, and both are yours to pick: Do not store it, and Protect from everyone. Nothing else alters your reads.
What this feature is
Synap reads the content you send. Some of it is sensitive: an Aadhaar number in a support transcript, a card number a customer read out on a call, an API key somebody pasted into a chat. Two things are true about that content at once. You need it, because answering the customer’s next question depends on remembering the conversation. And keeping it is a liability, because it sits in a memory store, gets embedded for search, and passes through a language model on the way in. Sensitive data protection separates those two. Synap finds the value, replaces it with a stable placeholder everywhere it would come to rest, and hands the real value back to your application when it asks. Your product behaves the same. What we hold on disk does not contain the value. You decide which kinds of value get that treatment. The decision is made once, in the dashboard, per category.The three things that can be true
These are separate, and mixing them up is the easiest way to misread the feature.1
Watching
Synap runs its detection over every document and records what it found: which field types, how many times, across how many of your users. Nothing is changed, nothing is replaced, and your memories are byte for byte what they would have been.This is what every account gets before anyone configures anything. It is not a degraded state. It is how you find out what is actually in your traffic before you make a decision about it.
2
The floor
A short list of field types is never kept, whatever your settings say. Card numbers, card security codes, card PINs, passwords, API keys and other secret codes, private keys, and raw biometric data.There is no setting for these. They are not one of your eleven choices, and no preset, exception, or support request turns them into one.
3
Your policy
Once you have set a policy and approved it, Synap applies it to everything ingested from that point on. Each category gets one choice, and that choice decides what the model sees, what we store, what your application receives, and what our staff can see.A policy is inert until a person approves it. Saving a draft changes nothing.
The eleven categories
Field types are grouped into eleven categories so you configure eleven things rather than a long list of individual formats. The grouping is for navigation. Nothing about detection depends on it.
You can add field types Synap does not ship, put them in whichever category you think they belong to, and move them later. An asset tag, a policy number, an order id: you know your own data better than we do.
The six settings
Each category gets one choice. Three of them are offered on the row itself; the other three sit behind an advanced link for the minority who need them.
The three offered up front are Not sensitive (“keep it”), Protect at rest (“protect it”), and Do not store it. Protect at rest is the one most clients want: the value is not in our store, and your application still reads the real thing.
Logs and telemetry are deliberately not a column in that table. They always receive the most restricted treatment your chosen setting allows, and there is no setting for them, because nobody has ever wanted a real value in a log line.
Your own vault is not available yet. The setting exists and a policy can carry it, but the outbound path to a customer-operated endpoint is a separate track that starts when a client asks for it. Until then, treat it as equivalent to Protect fully and talk to us before selecting it.
What a placeholder is
A placeholder, which the product calls an alias, looks like this:Presets
Rather than starting from eleven empty dropdowns, you can apply one of three starting points, then adjust.
A preset is a starting point, not an answer. It lands as a draft and still needs approving.
The floor
Seven field types are never stored, for any account, in any industry, whatever the settings say:- Full card number
- Card security code
- Card PIN
- Passwords
- API keys and other secret codes
- Private keys
- Raw biometric data
[a card number was given and not kept], and the record that it happened is kept. Nothing is stored that the value could be recovered from.
What happens to the memory around it
If a value never reaches the model, the model will sometimes still write a memory about the empty space. “Their card number is a card number” answers no question, takes up room, and reads as though we hold the number somewhere. The rule Synap applies is simple: keep a memory if it records something happening, drop it only if it does nothing but assert a value we chose not to keep. “Requested an address change on 12 August” survives, because the event is the useful part and the address was only one attribute of it. Suppressed memories are counted and shown on your dashboard with the reason, alongside a sample of what was kept, so a working feature does not look like data loss.What detection can and cannot do
Synap does not claim perfect detection, and the strength of the promise differs by field type. This matters more than a single accuracy number would.
Measured precision and recall are published per field type rather than claimed as one number. See Security and Trust for the current figures and the size of the corpus they were measured on.
Known limits, stated up front
- Names and street addresses are not detected. There is no detector for either. Do not plan around them being found.
- Health, origin and belief data are not detected. The categories exist and accept a setting; no field type ships in them.
- Biometric detection is text only. Synap finds an encoded biometric template when it appears in text next to a word that labels it, such as “fingerprint template” or “iris minutiae”. An unlabelled binary attachment is not text and is not covered.
- Images, audio, and scanned documents are not covered. Detection runs over text.
- Voice transcripts are covered for four field types. Numbers dictated as words (“nine eight seven six five…”) are reconstructed for Aadhaar, card number, phone, and PIN code, including Hindi digits and corrections mid-number. Other field types are not recovered from speech.
- The shipped identifier list is largely India-first. Aadhaar, PAN, GSTIN, IFSC, UPI, voter ID, and vehicle registration are Indian formats. Email, phone, card number, IP and MAC address, passwords, API keys, and private keys are not region-specific. Phone number detection assumes an Indian number by default.
- Data ingested before you turned this on is unaffected. It stays exactly as it is, in plain text. Policy applies forward only.
Turning it on
Everything is configured on the Sensitive data page in the dashboard. See Sensitive data and data controls for the step-by-step, including the test box that shows you what would happen to sample text before you commit to anything.Next steps
Configure it in the dashboard
The step-by-step, the test box, and how a policy is approved.
Aliases
What your application receives, and why search still works.
Your own field types
Describe a field type Synap does not ship, and pick its category.
Sensitive data FAQ
The questions engineering teams and security reviewers actually ask.