Before you start: configuring this does not change what your application reads back.For every setting except two, your own API keys receive the real value, so your app sees exactly what it sees today. The two exceptions are Do not store it and Protect from everyone, and the page tells you which is which as you pick.Nothing you do on this page takes effect until you approve it. Saving is not turning it on.
Finding the page
Open the Dashboard and go to Sensitive data. The page opens on What we found, which lists what Synap has actually detected in your traffic over the last 30 days. It is deliberately not an empty configuration form: the point is to decide about data you really have. At the top of the page, Applies to controls the scope of everything below it. The default is All instances (whole account). Pick a single instance to give that one instance a policy that overrides the account setting. Most teams set one policy for the whole account and never touch this.Setting a policy
1
Start from a preset, or don't
If you have not configured anything yet, the page offers three starting points under Clients like you usually begin here: Minimal, Standard, and Regulated. One click sets every category. Standard is the right answer for most products.A preset lands as a draft. It is not live until you approve it, and you can change any row afterwards.
2
Work down the findings list
Each row is a field type Synap found, with how many times it appeared and across how many of your users. Each row offers three choices:
The advanced link on a row opens the other three settings: hide from the model only, protect from everyone including your own app, and keep it in your own vault. Most teams never open it.Rows on the floor list, such as card numbers and passwords, show a never stored badge and offer no choice. See the floor.
3
Read the before and after
Picking a different choice renders a real before-and-after for that row, using a sample memory sentence, plus one line saying whether your application is affected. That line is the one to read. Two settings affect your app; the rest do not.
4
Review and apply
Nothing takes effect one row at a time. Changes collect in a bar at the bottom of the page showing how many are not applied yet. Discard throws them away. Review and apply saves them and approves them together.Approving records who approved it and when, and bumps the version. The previous version stays readable under the policy history, so you can always see what was in force when a given memory was created.
Below the findings list there is a line reading “We also looked for N other kinds of sensitive data and did not find any.” Expand it to see the full list of what was searched for. It is there so you can tell “we checked and found nothing” apart from “nobody ever looked”.
Suggestions
Above the findings list, Synap surfaces field types appearing in your traffic that you have not decided about yet. At most three are shown as prominent; the rest sit under show more, and the total is stated so you can see the list is complete. Nothing is hidden by a score; the score only decides the order. Each suggestion offers protect, ignore permanently, or not now. Choosing protect records the decision, it does not switch protection on by itself. You still set the category and approve the policy.The test box
The Try it tab is the fastest way to answer “what would this actually do to my data”. Paste sample text, click See what happens, and the page lists everything Synap found: the field type, where in the text it sits, and what would happen to it at each destination under your current settings. Findings on the floor are badged never stored, and your own field types are badged as yours. Two things about this box are worth knowing:- Nothing you paste is stored. Not the text, not the values, not a counter, not a log line, not an audit row.
- The result carries positions and field type names, never the matched text itself. You can safely screenshot or paste a result into a ticket.
Seeing what is protected
The Protected values tab answers “is anything actually protected right now, and how much”. It shows, per field type, how many distinct values are held, how many times they have appeared, what your application receives for that field type, and what the model sees. It shows no values and no placeholders, deliberately. A page that exists to demonstrate values are not readable would disprove itself by displaying them. The same tab shows what the floor removed and what was suppressed by the memory drop rule, alongside a sample of the memories that were kept. Read the kept sample: a card that shows only what was thrown away makes a working feature look like data loss.Activity and evidence
The Activity tab is the audit trail for everything that happened to your sensitive data. Your own people and Synap staff appear in the same list, with a column saying which is which, so you find out about our access on your own dashboard rather than from us. Each entry carries the time, the action, the field type, who did it, the reason they gave, and the policy version in force. It never carries the value. Entries are kept for one year. Export downloads the trail as a CSV file an auditor can open. The policy history, on the same page, shows every version, who approved it, and when.Your own field types
The Your own field types tab lets you describe a field type Synap does not ship: an asset tag, a policy number, an order id. Give it a name, pick the category it belongs in, and paste two or three real examples. No release and no ticket. See Your own field types for how to pick the category and write good examples.Restricting an API key
Your policy decides what any caller can receive. On top of that, each of your API keys carries a grant that can only ever narrow what the policy already allows:
Use this to give a support tool or an internal dashboard a key that reads memories without reading values. A grant cannot widen access, so there is no way to accidentally hand a key more than your policy allows: to widen, change the policy.
A grant change takes up to about a minute to take effect on live traffic, because the credential is cached.
What does not appear on this page
- Erasing a person is not a self-service action. See Erasing a person.
- Data ingested before you approved a policy is untouched and stays in plain text. Policy applies forward only, and every record carries the policy version that was in force so you can tell which is which.
Next steps
Sensitive Data Protection
The categories, the settings, the floor, and what detection can and cannot do.
Aliases
What your application receives once a field type is protected.
Your own field types
Describe a format Synap does not ship.
Erasing a person
Deleting someone completely, and what becomes unreadable.