> ## 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 FAQ

> The questions engineering teams and security reviewers actually ask about Synap's sensitive data protection, sometimes called PII protection. Two halves: what it does to your application, and what it means for a security review.

For the concepts behind these answers, read [Sensitive Data Protection](/guides/pii-protection). For the claims a security review needs in one place, read [Security and Trust](/resources/security-trust).

## From your engineering team

<AccordionGroup>
  <Accordion title="Will this break my application?">
    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.
  </Accordion>

  <Accordion title="Do I need to change my SDK code?">
    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](/concepts/aliases#what-your-application-receives).
  </Accordion>

  <Accordion title="Will my memories get worse?">
    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.
  </Accordion>

  <Accordion title="Will it be slower?">
    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.
  </Accordion>

  <Accordion title="Does search still work if the value is protected?">
    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.
  </Accordion>

  <Accordion title="What happens to memories I already have?">
    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.
  </Accordion>

  <Accordion title="Can I turn it off after turning it on?">
    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.
  </Accordion>

  <Accordion title="What if you miss something?">
    We do not promise perfect detection, and [Security and Trust](/resources/security-trust#what-we-promise-and-what-we-do-not) 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.
  </Accordion>

  <Accordion title="What if you flag something that is not sensitive?">
    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**.
  </Accordion>

  <Accordion title="How do I add a field type you do not know about?">
    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](/guides/custom-field-types) for the full picture, and contact us if you need a custom format protected in production now.
  </Accordion>

  <Accordion title="Can I check what would happen before I commit to it?">
    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.
  </Accordion>

  <Accordion title="Can I stop my own support staff from seeing values?">
    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](/dashboard/pii-and-data-controls#restricting-an-api-key).
  </Accordion>

  <Accordion title="What happens if detection fails on one of my documents?">
    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.
  </Accordion>
</AccordionGroup>

***

## From a security or legal reviewer

<AccordionGroup>
  <Accordion title="Where do the real values live?">
    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.
  </Accordion>

  <Accordion title="Who can decrypt them?">
    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](/resources/security-trust#what-we-do-not-protect-against).
  </Accordion>

  <Accordion title="Can you delete a person completely?">
    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](/guides/erasure).
  </Accordion>

  <Accordion title="Is our data sent to third parties?">
    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 **[legal@maximem.ai](mailto:legal@maximem.ai)**.
  </Accordion>

  <Accordion title="Is data encrypted at rest?">
    Protected values are encrypted individually, under a key held per account, on top of the volume-level encryption described in [Security and Trust](/resources/security-trust#encryption).

    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.
  </Accordion>

  <Accordion title="What is your detection accuracy?">
    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](/resources/security-trust#sensitive-data-detection-measured).
  </Accordion>

  <Accordion title="Do you keep an audit trail?">
    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.
  </Accordion>

  <Accordion title="What is not covered?">
    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](/resources/security-trust#what-we-promise-and-what-we-do-not).
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Sensitive Data Protection" icon="shield" href="/guides/pii-protection">
    The categories, the settings, and the floor.
  </Card>

  <Card title="Security and Trust" icon="shield-check" href="/resources/security-trust">
    Everything an enterprise security review asks about, in one place.
  </Card>

  <Card title="Configure it" icon="sliders-horizontal" href="/dashboard/pii-and-data-controls">
    Set a policy, test it, and approve it.
  </Card>

  <Card title="Erasing a person" icon="trash-2" href="/guides/erasure">
    Deleting someone, and what becomes unreadable.
  </Card>
</CardGroup>