Skip to main content
For the concepts behind these answers, read Sensitive Data Protection. For the claims a security review needs in one place, read Security and Trust.

​
From your engineering team

No, unless you choose it.For any field type you protect, your own API keys receive the real value by default, so the text your application reads back is identical to what it reads today. Request and response shapes do not change.Only two settings change what you get back, and both are yours to pick: marking a field type Do not store it, and restricting one of your own API keys. A third, Protect from everyone, exists behind the advanced link and does exactly what its name says, including to you.
No. There is no new call to make, no parameter to pass, and no version to pin for this. Everything is configured in the Dashboard.If you deliberately restrict a key so it receives placeholders, your code has to be ready to see a placeholder in the text. See Aliases.
Placeholders are stable: the same value always becomes the same placeholder, in the same form, however it was spelled. So deduplication still merges duplicates, corrections still supersede what they correct, and entity identity in the graph still resolves to one thing rather than two.Every change to this feature is held to the same benchmark gate Synap uses for retrieval quality, with a hard limit on how far any individual benchmark may move.
Ingestion picks up a detection pass, and ingestion is asynchronous, so it does not sit in your request path.Reads pick up a small step to put real values back before the response is assembled, which is short next to a fetch that is already dominated by retrieval. If a fetch returns no placeholders at all, which is the case for every account that has not configured anything, that step is skipped entirely.
Yes, and this is a hard requirement in the design rather than an optimisation.Your query goes through the same detection step your content did. A search for 9876543210 is turned into the same placeholder that was stored, so it matches the memory holding it. A value Synap has never seen leaves the query untouched, which is correct: no memory holds that value either.
They stay exactly as they are, in plain text. Policy applies forward only, from the moment you approve it.Every record carries the policy version that was in force when it was created, so you can always tell which memories were written under which rules. Re-processing older memories under a new policy is possible and is a job we run for you on request; it costs real time and money, so it is not automatic.
Yes. Set the categories back and approve, and new memories stop being protected.Memories already protected stay that way, and stay readable: your application keeps receiving the real values for them, because the placeholders still resolve.
We do not promise perfect detection, and Security and Trust states exactly what we do and do not promise.What you get instead of a promise is visibility. Watch mode runs for every account from day one and shows you what is being found in your own traffic, by field type, with counts. A gap is a number you can see rather than something you find out about later. The publication of measured precision and recall per field type is part of the same idea.
For the settings most people pick, it costs you nothing visible. A false positive is protected on the way in and revealed straight back to you on the way out, so the text your application receives is unchanged.It shows up as a count on your dashboard. If a field type is producing noise, move it down a level or set it to Keep it.
Describe it on the Your own field types tab with a name, a category, and a few real examples. No deploy and no ticket.One caveat that matters: a field type you describe is currently detected in the Try it test box only, and is not yet applied to live ingestion. See Your own field types for the full picture, and contact us if you need a custom format protected in production now.
Yes. The Try it tab takes sample text and shows exactly what would be detected and what your current settings would do with it at each destination.Nothing you paste there is stored: not the text, not the values, not a counter, not a log line. The result carries positions and field type names rather than the matched text, so it is safe to paste into a ticket.
Yes. Issue that tool a restricted API key. A key’s grant can only ever narrow what your policy already allows, never widen it, so there is no way to accidentally hand a key more access than you intended. See restricting an API key.
It depends on whether you have a policy in force.In watch mode, a detection failure is counted and the document proceeds. Watch mode changes nothing about your data, so a failure there must not be able to break your ingestion.Under an approved policy, a document that cannot be protected is refused rather than stored. Continuing anyway would send a value to a model you told us to keep it from, which is the one outcome this feature exists to prevent.
Protected values are held in one place, encrypted under a key that belongs to your account alone. The plain value is not written to the memory store, the vector store, the graph, or our logs.This applies to field types you have protected. A field type you set to Keep it, and anything ingested before you approved a policy, is ordinary content.
The application can, using a master secret held in the deployment environment.Synap staff cannot read a protected value without a deliberate reveal action, which requires a named person, a written reason, and writes an audit entry that you can read on your own dashboard the same day. There is no path that shows a value to our staff without leaving that record, and an impersonated session cannot reveal at all.The reason field is itself screened, and a reveal whose reason contains what looks like a sensitive value is refused along with the reason.We state the limits of this honestly: see what we do not protect against.
Yes. Erasure destroys the encrypted form of every protected value held for that person, which makes every reference to them permanently unreadable everywhere at once, including in database backups we cannot go back and rewrite.Removing an entire account is a single operation with the same effect across all of its data.One thing is deliberately kept and is named in the preview before anything runs: values shared with other people, because deleting those would break other people’s memories. See Erasing a person.
Yes. During ingestion, content is sent to the model provider that performs extraction.Under a policy, protected values reach that provider as placeholders rather than real values. Floor field types never reach it at all.Whether a given provider retains or trains on data sent to it is a contractual question and is answered in our Data Processing Agreement, not here. Request it from [email protected].
Protected values are encrypted individually, under a key held per account, on top of the volume-level encryption described in Security and Trust.Memory text itself is not field-encrypted, and that is a deliberate choice rather than an omission: encrypting it would make semantic search impossible, and semantic search is the product. Protection for memory content comes from the sensitive values not being in it.
We publish it per field type rather than claiming a single number, and we do not sell two different mechanisms at the same confidence.Field types with a check digit, such as Aadhaar, GSTIN, and card numbers, are close to certain: a value that fails its checksum is rejected rather than guessed at. Field types found by shape are strong but weaker than that.Names and street addresses are found statistically, with both misses and false alarms, and no detector for either is switched on today. One exists, we measured it, and it is off because the measurement says it is not good enough: it finds two thirds of names in written text, under half in a voice transcript, and none of the 8 street lines in the corpus at all. The full table is published rather than summarised.The current measured figures for both, and the size of the corpora they were measured on, are in Security and Trust.
Yes, append only, kept for one year.Each entry records the field type, the action taken, the placeholder involved, the scope, the time, who acted and whether they were your person or ours, the reason they gave, and the policy version in force. It never records the value, and never records the text around it.You read it on your own Activity tab and export it as a CSV file. Your policy history shows every version, who approved it, and when.
Stated plainly, because a reviewer will find these anyway:
  • Names and street addresses are not detected. A detector exists and is switched off in every environment, because its measured precision is under the bar we set for it. Do not plan around names being protected.
  • Health, origin and belief data are not detected. Those categories accept a setting; no field type ships in them.
  • Biometric detection is text only, and only for an encoded template that appears next to a word labelling it. An unlabelled binary attachment is not covered.
  • Images, audio, and scanned documents are not covered.
  • Data stored before this shipped is plain text and stays that way.
  • We do not protect against an attacker who holds our application environment and our database at the same time.
The full list is on Security and Trust.

​
Next steps

Sensitive Data Protection

The categories, the settings, and the floor.

Security and Trust

Everything an enterprise security review asks about, in one place.

Configure it

Set a policy, test it, and approve it.

Erasing a person

Deleting someone, and what becomes unreadable.