> ## Documentation Index
> Fetch the complete documentation index at: https://docs.maximem.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Sensitive Data Protection
> Synap finds sensitive values in the content you send, and you decide what happens to each kind at each destination. Sometimes called PII protection. This page covers the eleven categories, the six settings, and the short list of field types nobody is allowed to keep.
**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.
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.
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.
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.
| Category | Field types Synap detects today |
| ---------------------- | -------------------------------------------------------------------------------------------- |
| **Raw Identity** | *(nothing shipped yet, see below)* |
| **Contact Info** | Email address, phone number |
| **Formal Identity** | Aadhaar number, PAN, passport number, voter ID, driving licence, vehicle registration, GSTIN |
| **Payment Info** | Card number, card security code, bank account number, IFSC code, UPI ID |
| **Health** | *(nothing shipped yet, see below)* |
| **Location (coarse)** | PIN code |
| **Location (fine)** | *(nothing shipped yet, see below)* |
| **Device and Online** | IP address, MAC address |
| **Secrets** | Card PIN, password, API key or secret code, private key |
| **Origin and Beliefs** | *(nothing shipped yet, see below)* |
| **Biometric** | Raw biometric data (see the limits below) |
**Four categories have no shipped detection yet: Raw Identity, Health, Location (fine), and Origin and Beliefs.**
You can set a policy on them, and the setting is stored and applied. But Synap ships no detector for names, street addresses, health conditions, or origin and belief data, so under a policy alone nothing in those categories is currently found and nothing is replaced. Statistical detection for names and addresses is planned and is not built.
If you need protection in one of these categories today, describe your own field type for it. See [Your own field types](/guides/custom-field-types).
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.
| Setting | The model sees | We store | Your app gets | Our staff sees |
| ----------------------- | -------------- | ------------- | ------------------ | -------------- |
| **Not sensitive** | real value | real value | real value | real value |
| **Hide from the model** | a placeholder | real value | real value | a placeholder |
| **Protect at rest** | a placeholder | a placeholder | real value | a placeholder |
| **Protect fully** | a placeholder | a placeholder | a placeholder | a placeholder |
| **Do not store it** | a description | nothing | nothing | nothing |
| **Your own vault** | a placeholder | a placeholder | your vault answers | a placeholder |
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:
```text theme={null}
[[PERSON_AADHAAR_h2n7v5cx8m0d]]
```
The same value always becomes the same alias, so deduplication, corrections, and search keep working on a consistent string. Search for the real value and Synap matches the memory that stores its alias. See [Aliases](/concepts/aliases) for what your application receives and why search still works.
### Presets
Rather than starting from eleven empty dropdowns, you can apply one of three starting points, then adjust.
| Preset | What it does | Who it suits |
| ------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Minimal** | Keeps everything except the things nobody may keep. | Products where the personal detail is the point, such as a companion app. |
| **Standard** | Protects identifiers and payment details. Your app still gets real values. | Most products. Start here if you are not sure. |
| **Regulated** | Protects everything that identifies a person, and drops what you must not keep. | Health, finance, insurance, and anyone answering to an auditor. |
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
No setting on your account changes this. It is not a category-level rule, so it does not drag the rest of the category with it: a bank account number sits in Payment Info and plenty of products legitimately keep one.
When one of these appears, the value is replaced with a short description of what was taken, such as `[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.
| How a field type is found | What that means | Examples |
| ------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **Check digit** | The value carries a checksum that has to pass. A near miss is rejected rather than guessed at. | Aadhaar, card number, GSTIN |
| **Fixed format** | The value has a shape distinctive enough to match on its own. | PAN, IFSC, email, IP address, private key |
| **Needs context** | The shape alone is too common, so a nearby word has to confirm it. | Card security code, card PIN, bank account number, PIN code |
| **Statistical** | Found by judgement rather than by shape. | Names, street addresses. **Not shipped.** |
Measured precision and recall are published per field type rather than claimed as one number. See [Security and Trust](/resources/security-trust#sensitive-data-detection-measured) 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](/dashboard/pii-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
The step-by-step, the test box, and how a policy is approved.
What your application receives, and why search still works.
Describe a field type Synap does not ship, and pick its category.
The questions engineering teams and security reviewers actually ask.