Security and privacy at Maximem Synap

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 [email protected] 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.

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.

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.

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 [email protected] 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.

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.

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.

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 [email protected]. 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 [email protected] and we will work through it with you.

If you believe you have found a security issue in Synap, email [email protected]. 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.