Skip to main content
This page covers everything an enterprise security review will ask about. If your specific question isn’t answered here, email [email protected].

​
Encryption

All traffic between SDK and Synap Cloud is verified against pinned certificates. The SDK never falls back to plaintext if TLS negotiation fails.

​
Sensitive data protection

Synap detects sensitive values in the content you send and applies a policy you set, per category, deciding what reaches the model, what we store, what your application receives, and what our staff can see. The full explanation is in Sensitive Data Protection; this section is the part a security review needs. Protected values are held in one place, encrypted individually under a key that belongs to your account alone. That key is itself held encrypted, and removing it makes every value it protected unreadable at once. Memory text is not field-encrypted, deliberately: 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.

​
Sensitive data detection: measured

We publish accuracy per field type rather than claiming one number, because the detection mechanisms are not equally strong and selling them at the same confidence would be dishonest. Measured with detector version 1.2.0 against a labelled corpus of 64 cases that we maintain ourselves: Zero false alarms across the corpus. Every recorded minimum was met. Read these numbers for what they are. They are measured against a corpus we wrote, not against your production traffic, and a corpus of this size proves that each detector works on the cases we know about rather than that no case exists which it misses. They are the bar we hold ourselves to and re-run against, and they are published rather than asserted. Field types found by check digit carry a genuinely stronger promise than the rest: a value that fails its checksum is rejected outright rather than guessed at.

​
Names and addresses: measured, and switched off

Every field type in the table above is found by a pattern or a check digit. Names and street addresses cannot be, so they need a statistical model, and a statistical model has to be judged on numbers rather than on the fact that it exists. We built one and measured it against a second corpus of 103 passages carrying 95 labelled names and addresses, plus 37 passages carrying none. It is switched off in every environment, and this table is the reason. We are publishing it because a reviewer deciding whether to trust us is better served by a measured failure than by silence. The three columns are one body of text under three mechanical transforms, so the only variable between them is capitalisation and punctuation. The transcript column is what speech recognition actually emits, so a voice product would get the right-hand column: under half the names and under a quarter of the addresses. Three specific findings sit behind those averages, and each matters more than the average does.
  • Street address does not find street lines. Recall on an actual house number and street is 0 of 8, in all three columns. What the detector finds is cities and localities. The part of an address most people mean when they ask for addresses to be protected is the part it is worst at.
  • Place names are mistyped along regional lines. Indian place names come back typed as people while Western ones come back typed as places. The text would still be covered, so this is not a leak, but a policy that sets Identity and Location differently would apply the wrong one, and you would have no way to see why.
  • Precision is under our own floor. We require 0.80 precision from a statistical detector before it may be enabled. Person name as written measures 0.75. That is the specific line this detector fails.
If names or addresses are load-bearing for your compliance position, this feature does not currently meet it, and we would rather you know that from this page than discover it in an audit.

​
What we promise, and what we do not

Taken without softening. We promise that the field types on the floor list are never stored, for every account, whatever the settings say. That list is: full card number, card security code, card PIN, passwords, API keys and other secret codes, private keys, and raw biometric data. No account setting, no preset, and no support request changes it. We promise that a field type you mark Do not store it does not come to rest in our memory store, our vector store, our graph, or our logs, subject to the detection limits below. What is kept is the fact that a value was given, not the value. We promise that deleting a person or an entire account makes their protected values permanently unreadable everywhere, including in database backups we cannot go back and rewrite. See Erasing a person. We promise that our staff cannot read a protected value without leaving a record. A reveal requires a named person and a written reason, writes one audit entry per value, and appears on your own Activity tab the same day. An impersonated session cannot reveal at all. We do not promise perfect detection. Pattern-based fields with a check digit are close to certain. Names and addresses are found statistically, with both misses and false alarms, and we publish measured numbers per field type rather than a claim. Specifically today:
  • person_name and street_address have no detector running. Names and street addresses are not detected for any account. A statistical detector for them exists and is switched off in every environment, because we measured it and it is not good enough to turn on. The numbers are published below rather than kept internal. Do not plan around names being protected.
  • Health, and origin and belief data are not detected. Those two categories accept a setting and it is stored and applied, but no field type ships in either, so nothing in them is currently found.
  • Biometric detection is text only. Synap detects an encoded biometric template when it appears in text alongside a word that labels it, such as “fingerprint template”, “iris minutiae”, or an ISO 19794 header. An unlabelled binary attachment is not covered, and neither is an unlabelled encoded blob, which is indistinguishable from any other encoded blob.
We do not promise that data already stored is protected. Everything held before this shipped is plain text and stays that way until a re-processing job runs, which costs real time and money. We do not cover images, audio, or scanned documents in this version. Detection runs over text.

​
What we do not protect against

We do not protect against an attacker who holds both our application environment and our database at the same time. The key that opens account keys is held in the deployment environment, so anyone who can read that environment and also read the database can read protected values. A managed key service would close that gap by moving the key into hardware the application can never read, and we are not using one. We state this rather than leaving a reviewer to work it out.

​
Isolation model

Synap enforces isolation at three boundaries:
  1. Instance isolation: each Instance has its own logical storage namespace across vector and graph stores. Memories from one Instance are never queryable from another, even by accident, because every query is scoped to an Instance ID resolved server-side from your API key.
  2. Scope isolation: within an Instance, every memory is tagged with USER → CUSTOMER → CLIENT → WORLD scope. A user-scoped retrieval never returns memories from a different user, regardless of similarity. See Memory Scopes.
  3. Network isolation: Synap Cloud is network-isolated per region. Customer data never crosses regions.

​
Data residency

You pick the region at Client creation. Memories stay in that region for their entire lifecycle, including backups and replicas. Cross-region replication is not done automatically.

​
Deployment options

Synap is offered as a fully managed cloud service, and, on Enterprise, as a private/VPC deployment or a self-hosted/on-premise install for teams with strict data-residency or air-gap requirements. The open-source SDK (github.com/maximem-ai/maximem_synap_sdk) is available independently of the managed platform.

​
Enterprise access controls

Contact [email protected] to enable SSO/SAML, RBAC, VPC/private deployment, or self-hosting.

​
Deletion guarantees

Synap supports per-memory, per-conversation, per-user, per-customer, and per-instance deletion.
  • Soft delete (default): the memory is removed from retrieval results immediately and purged from active stores within 24 hours. The deletion is logged to the audit trail.
  • Hard delete (on request): removes the memory from backups as well, within 30 days. Use this for GDPR Right-to-be-Forgotten and CCPA Right-to-Delete requests. Contact [email protected] to initiate.
Deletion cascades through the entity graph: when a user is deleted, any entities exclusively referenced by their memories are also removed. Entities co-referenced by other users (e.g., a shared product entity) are retained. Erasure is a third and stronger option for accounts using sensitive data protection. Protected values are encrypted under a key held per account; erasing a person destroys the encrypted form of every value held for them, which makes those values unreadable everywhere at the same moment, including in backups already taken. There is no waiting period and nothing to scan for, because there is no longer anything that could be read. Removing an entire account has the same effect across all of its data in one operation. Erasure covers protected values. It does not reach data ingested before you approved a policy, which was never protected and is ordinary content. Values shared with other people are deliberately kept and are named in the preview before anything runs. See Erasing a person for the full behaviour and how to request it.

​
Compliance posture

Synap maintains a vendor security questionnaire (CAIQ + Lite SIG). Request via [email protected].

​
Sub-processors

Synap maintains a public sub-processor list. See the Synap sub-processor disclosure for the current list.

​
Audit logs

Every dashboard and SDK action is logged with correlation_id, principal (user / API key), timestamp, action, and resource. Audit logs are retained for 90 days by default and can be exported from the Dashboard (on Enterprise plans).

​
Reporting a vulnerability

Email [email protected] with reproduction steps. We acknowledge within 24 hours and aim to issue a patch within 7 days for critical vulnerabilities. We do not currently run a public bug bounty but will reward responsibly-disclosed issues.

​
What we do NOT do

Stated explicitly so there are no surprises in your security review:
  • We do not train models on customer data.
  • We do not share customer data with sub-processors beyond what is listed above.
  • We do not allow Synap engineers to query customer data without a documented support ticket from the customer. Where that access happens through our own tools it leaves a record: revealing a protected value requires a named person and a written reason, writes one audit entry per value, and appears on your Activity tab. Direct database access is restricted to a small number of engineers by credential, and is not separately recorded query by query. We would rather tell you which of those two things you are relying on than describe both as the same control.
  • We do not retain deleted memories. Once a hard delete completes, the data is gone, including from backups within the 30-day window.