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 in Synap’s live systems. Backups taken before that still hold the data until they expire. 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 version1.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
Street addresses are found by shape, like the field types in the table above: a house number followed by a street word such as Road, Street or Nagar. An address written another way can be missed. This pattern is not yet in the measured table. Names cannot be found by shape, so they come from a separate statistical service, and a statistical model has to be judged on numbers rather than on the fact that it exists. While that service is unavailable, names are not found. We measured it against a second corpus of 103 passages carrying 95 labelled names and addresses, plus 37 passages carrying none. We are publishing the result because a reviewer deciding whether to trust us is better served by a measured weakness 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.
Two specific findings sit behind those averages, and each matters more than the average does.
- 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 hold a statistical detector to 0.80 precision. Person name as written measures 0.75.
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 erasing a person deletes their protected values and memory records from our live systems, and that removing an entire account makes every protected value it owns unreadable there. Backups taken before either still hold the data until those backups expire. 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 are found statistically, with both misses and false alarms, and we publish measured numbers per field type rather than a claim. Specifically today:person_namedepends on a separate service. Names are found by the statistical service measured above; while it is unavailable, names are not found. Do not plan around every name 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.
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:- Instance visibility: every memory is tagged with the Instance that stored it, and the Instance is resolved server-side from your API key. By default, Instances under the same client and customer share memory, so one Instance can retrieve another’s memories. To control which Instances read each other’s memories, set an Instance Visibility policy. Under Isolated mode an Instance sees only itself and the Instances you grant it. Client-scoped shared knowledge stays visible to every Instance.
- Scope isolation: within an Instance, every memory is tagged with USER, CUSTOMER or CLIENT scope. A user-scoped retrieval never returns memories from a different user, regardless of similarity. See Memory Scopes.
- Network isolation: Synap Cloud is network-isolated per region.
Data residency
You pick the region at Client creation. Data replicates between the Ohio and Mumbai regions.
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 direct deletion of individual memories and conversations. For erasing a person or an entire user scope, contact privacy support.- Memory delete:
memories.deleteremoves the memory record directly. It is not a soft delete. - Soft delete: applies only to direct
forgetoperations. - Hard delete (on request): removes the memory records. Deleted memory records are removed from backups within 30 days. Use this for GDPR Right-to-be-Forgotten and CCPA Right-to-Delete requests. Contact [email protected] to initiate.
- Dashboard: deleting memories and approving forget requests needs the delete permission, which Owners and Admins hold and Members do not. A delete from memory search reaches another instance only after the person confirms it. Deleting permanently is a separate permission, also held by Owners and Admins. See Deleting memories. Approving an agent’s forget request is not permanent, and an agent cannot ask for a permanent delete.
- Your agent, with
memories.forget: reaches every instance the asking instance can read under instance visibility. In an instance it cannot read, nothing is changed: a request is filed there for a person to decide, and the asking agent is never shown that instance’s memories. - Dashboard deletes and approvals are recorded in the memory’s change history, without the memory’s text. Memories held for a whole account rather than a customer or user are not recorded there yet.
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 withcorrelation_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 72 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 memory records. Once a hard delete completes, the memory records are gone from live systems. Deleted memory records are removed from backups within 30 days.