Security and privacy # Security and privacy at Maximem Synap This page describes what protections exist and what you can rely on. It is written for the security review you are about to run: plain language, no overselling, and a direct answer to each question that review will ask. Encrypted in transit and at rest Data stored in the United States Strict tenant isolation DPA on request, any plan Self-hosted and air-gapped available Contents 01/Data flow ## Where your data goes When your agent talks to Synap, the request travels a single, well-defined path. Your application calls Synap through our SDK or API, the request arrives at our gateway, and the gateway authenticates it before anything else happens. There is no path into the system that skips that check. Once authenticated, the request is tagged with the identity of the tenant it belongs to, and that tag travels with it for the rest of its life. Memories are then written to, or read from, storage that is already scoped to that tenant. Nothing is stored or returned without a verified identity attached to the request. Synap only receives what you choose to send it. We do not sit in front of your model calls, we do not crawl your systems, and we do not pull data from your infrastructure on our own initiative. Every piece of data in Synap arrived because your application deliberately sent it. Turning your text into a searchable form is done by a model we run ourselves on our own infrastructure, so that step involves no third party at all. Some deeper processing steps do use external model providers; those are named in the [subprocessor section](#subprocessors) below, and they can be removed entirely on self-hosted deployments, where your data never leaves your network. Scroll the diagram sideways to follow the full path → Data flow. Your agent or app calls Synap over TLS 1.2 or higher. The request reaches the Synap API gateway, which authenticates it before anything else happens. Unauthenticated requests are rejected and nothing is stored. Authenticated requests are tagged with the tenant identity taken from the request itself, written to or read from tenant-scoped memory storage, and only that tenant's data is returned to your agent. Authentication happens before storage, not after. There is no path into the system that skips it. 02/Hosting ## Where your data lives Synap's managed cloud runs on Amazon Web Services and Google Cloud Platform, and all customer data is stored in the United States. Both providers are contractually bound as our subprocessors, and neither has any right to your data beyond running the infrastructure we rent from them. We name them here because "whose hardware is my data on" is a question every security review asks, and a page that dodges it invites more questions than it answers. Additional regions are in active development for customers with data-residency requirements. If you need your data held in a specific jurisdiction, talk to us at [support@maximem.ai](mailto:support@maximem.ai) before you build. We would rather scope it with you than have you discover a gap later. Customers who cannot place data with a third-party cloud at all can run Synap self-hosted inside their own environment, including a fully air-gapped configuration with no outbound internet access. 03/Encryption ## Encrypted in transit and at rest Everything is encrypted in transit and at rest. Traffic between your application and Synap runs over modern TLS, and we do not accept unencrypted connections. Inside our own environment, service-to-service traffic is also encrypted, and our streaming and high-throughput paths additionally use mutual TLS, meaning both sides prove who they are with a certificate, not just the client. Data sitting in our databases, search indexes, object storage, and backups is encrypted on disk. Credentials get stricter treatment than ordinary data. API keys are never stored in a form we can read back. We keep only a one-way cryptographic fingerprint, so even with full database access nobody can recover your key. Certificates and secrets are held in a managed key management service rather than in application code or configuration files, and credentials are issued with a limited lifetime and rotated rather than living forever. If a credential is ever compromised, it can be revoked immediately and independently of every other credential you hold. Scroll the diagram sideways to follow the full path → Encryption. In transit: traffic from your application to Synap runs over TLS 1.2 or higher, and service-to-service traffic is encrypted, with mutual TLS on streaming and high-throughput paths. At rest: databases and search indexes are encrypted on disk, object storage and backups are encrypted, API keys are stored only as a one-way hash and are never recoverable, and certificates and secrets live in a managed key management service with short lifetimes and rotation. Credentials get stricter treatment than ordinary data: a key we cannot read back cannot be leaked by us. 04/Retention ## Your memories are kept until you delete them We do not expire your data on a schedule of our choosing or quietly age it out, because memory that disappears on us would defeat the point of the product. You control how long anything lives, and you can set retention policies per data type, so that short-lived working context and long-lived durable knowledge do not have to share the same clock. Retention settings are versioned and auditable, so during a compliance review you can show not only your current policy but the history behind it. Raw input payloads are treated differently and deliberately more strictly. When you send data to Synap, the original payload is stored encrypted for **15 days** and then automatically deleted. Its only purpose is recovery: if a bug affects a specific ingestion run, that window lets us replay and correct it rather than telling you your data is unrecoverable. It is not used for analytics, not used for training, and not retained beyond those 15 days. Scroll the diagram sideways to follow the full path → Retention. When you send data to Synap it splits two ways. The raw payload is stored encrypted for 15 days and then deleted automatically. The processed memory is kept until you delete it, and is removed on your policy or on your explicit request. Two clocks, on purpose. The raw payload expires on ours; the memory expires on yours. 05/Deletion ## Two kinds of delete, and the difference matters By default, deleting data soft-deletes it: it stops being readable and stops being returned in results immediately, but it is recoverable for a short period. That default exists to protect you, because an accidental bulk delete of an agent's memory is otherwise unrecoverable. A **full deletion** is permanent and irreversible, and it includes backups. It is deliberately a separate and explicit request, so it can never happen by accident. You can delete data from your dashboard, or contact us at [support@maximem.ai](mailto:support@maximem.ai) for a full deletion, which we complete within 20 business days. If you leave Synap, the same machinery applies to your whole account: we delete your data on termination rather than retaining it, and we will confirm the deletion in writing if you ask. Encrypted backups are held for 15 days on their normal rolling schedule. On self-hosted deployments, deletion happens entirely inside your own infrastructure and we hold no copy to delete. Scroll the diagram sideways to follow the full path → Deletion. By default, deleting data soft-deletes it: the data becomes unreadable and stops being returned in results immediately, and stays recoverable for a short period in case the deletion was a mistake. Full deletion is a separate, explicit request: it permanently erases the data including backups, completes within 20 business days, and is not reversible. An accidental bulk delete of an agent's memory should be survivable. Permanent erasure should never be an accident. Those two requirements need two different defaults. 06/Subprocessors ## Who else touches your data A subprocessor is any outside company that may handle your data on our behalf so Synap can do its job. We keep the list short on purpose and publish it here rather than burying it, because "who else touches my data" is the first question any serious security review asks. Every subprocessor is bound by contract to confidentiality and security obligations at least as strict as the ones we owe you, and each receives only the data it needs for its specific function. Note what is _not_ on this list: converting your text into a searchable form runs on our own infrastructure, so that step sends your content to nobody. Every call we make to an external model provider is made under a zero-data-retention agreement. That means two things concretely: your content is **never used to train their models**, and it is **not retained by them** beyond the short technical window each provider's own policy defines for handling a request. Those policies are linked below so you can read them yourself rather than take our word for it. If your organisation cannot accept third-party processing at all, the self-hosted deployment removes the question entirely. It runs fully inside your own environment, including an air-gapped configuration, and in that mode no subprocessor sees your data, because none of it leaves your network. ### Providers that process memory content All under zero-data-retention. None used for training. Provider Purpose Their data policy OpenAI Memory processing [openai.com/enterprise-privacy](https://openai.com/enterprise-privacy/) Anthropic Memory processing [privacy.anthropic.com](https://privacy.anthropic.com/) Google (Gemini) Memory processing [ai.google.dev/gemini-api/terms](https://ai.google.dev/gemini-api/terms) Groq Memory processing [groq.com/privacy-policy](https://groq.com/privacy-policy/) ### Providers that never see memory content Infrastructure, sign-in, billing, and product analytics only. Provider Purpose What it receives Amazon Web Services Hosting, storage, key management, account email Encrypted data at rest; account email addresses Google Cloud Platform Hosting, storage, key management Encrypted data at rest Auth0 Dashboard sign-in for your team Account holder identity only Stripe Subscription billing Billing contact and payment metadata only PostHog Product usage analytics Product usage events only Scroll the diagram sideways to follow the full path → Subprocessors. On the managed cloud, your memory content reaches AWS and GCP for hosting, storage and key management, and external model providers under zero-data-retention agreements. Account and billing data goes to Auth0, Stripe, PostHog and AWS SES, and memory content never crosses into that group. Turning your text into a searchable form runs on our own infrastructure and involves no third party. On a self-hosted or air-gapped deployment, your memory content stays on your infrastructure, there are no subprocessors and no egress, and nothing leaves your network. The list is short on purpose. Self-hosted removes it entirely. 07/Isolation ## One customer cannot reach another Every piece of data in Synap belongs to exactly one customer, and that ownership is attached at the moment the data is written, not decided later at query time. Because the tenant identity comes from the authenticated request rather than from anything the caller can set, an application cannot ask for another customer's data even if it tries: there is no parameter to change, no ID to guess, and no query that can widen the scope. Requests without a verified identity are rejected before they reach storage at all. Isolation continues below the customer boundary. Inside your own account you can separate data by environment and by end user, so your staging workspace cannot read production, and one of your users' memories cannot surface in another user's session. That matters if you are building a multi-user product on top of Synap, because the isolation your own customers expect is enforced by the platform rather than by your application code remembering to filter correctly. For organisations that require physical rather than logical separation, the self-hosted deployment gives each tenant its own isolated infrastructure. Scroll the diagram sideways to follow the full path → Tenant isolation. An authenticated request resolves to your organisation, which cannot see any other organisation. Inside your organisation, the production and staging environments cannot see each other. Inside production, one end user's memories cannot surface in another end user's session. Isolation is enforced by the platform, not by your application code remembering to filter correctly. 08/Contract ## A DPA is available to every customer A Data Processing Agreement is the contract that sets out, in legally binding terms, what we may and may not do with the personal data you send us. Ours is available to every customer on request at [support@maximem.ai](mailto:support@maximem.ai). You do not need to be on a particular plan to get one, and you do not need to negotiate for it. In that agreement we act as the processor and you remain the controller, which in plain terms means we handle your data only on your documented instructions and never for our own purposes. The DPA covers the commitments described on this page and makes them enforceable: our subprocessor obligations, our confidentiality and security duties, our obligation to notify you promptly if a breach affects your data, our support for your end users' access and deletion requests, and deletion or return of your data when the contract ends. It also includes the standard international transfer terms where they apply. If your legal or procurement team needs a security questionnaire completed as part of your review, send it to [support@maximem.ai](mailto:support@maximem.ai) and we will work through it with you. 09/Disclosure ## Reporting a vulnerability If you believe you have found a security issue in Synap, email [support@maximem.ai](mailto:support@maximem.ai). Please give us enough detail to reproduce it, and give us a reasonable window to fix it before disclosing it publicly. We investigate every report we receive, we will keep you updated while we work on it, and we will not pursue legal action against researchers who report in good faith and avoid accessing other customers' data. Our machine-readable contact details are published at [/.well-known/security.txt](https://www.maximem.ai/.well-known/security.txt). Reviewing Synap for your organisation? Send us your security questionnaire, ask for the DPA, or scope a self-hosted or air-gapped deployment. We would rather work through it with you now than have you find a gap later. [Talk to us about security →](mailto:support@maximem.ai)[See enterprise plans →](https://www.maximem.ai/synap/pricing) [← Maximem Synap](https://www.maximem.ai/synap)[How Synap works](https://www.maximem.ai/synap/how-it-works)[Memory, privacy and ownership](https://www.maximem.ai/memory-privacy-and-ownership)[Privacy policy](https://www.maximem.ai/privacy)[Terms of service](https://www.maximem.ai/terms) --- Source: [https://www.maximem.ai/synap/security](https://www.maximem.ai/synap/security)