Data Security

Access to the SynovAI platform requires authentication. Users are assigned to permission groups that control which models and features they can access. Single sign-on is available through Microsoft Entra ID, Google or GitHub, over OIDC, so access is managed from the identity infrastructure a customer already runs. SAML 2.0 single sign-on and SCIM 2.0 user provisioning are both built, and each is turned on by a connection configured for one customer's team rather than by a platform-wide default. Connecting a directory over SCIM is part of standing up a trial, so account lifecycle sits with the customer from the first day: disabling an account in their own directory sets it non-authenticating here, deletes every session it holds and revokes its other live credentials. Access can also be revoked immediately by an administrator, and no SynovAI staff account can read a customer's chemistry through the product by virtue of being staff.

Your submissions, results, and molecular data are associated with your account and are not visible to other users. Uploaded chemical catalogs are stored per-user and not shared across accounts. Task results, favorite routes, reagent flags, and feedback are all scoped to the authenticated user. Team-scoped catalogs and shared task views require explicit membership and are not accessible to non-members.

All traffic between you and the platform is encrypted in transit using TLS 1.2 or higher, terminated at the edge. Two internal hops run over a private network inside our Google Cloud project rather than over TLS: the application to the retrosynthesis inference host, and the application to our shared cache. Both are encrypted by Google's infrastructure at the network layer and reachable from no address outside that network, and we state them rather than let a blanket claim cover them. Nothing readable crosses the cache hop: what it carries is counters, opaque identifiers, and values the application has already encrypted with AES-256-GCM under a key the cache does not hold. Data at rest, including the application database, backups, and object storage, is encrypted using AES-256 with keys Google manages. Customer-managed encryption keys are not available today.

Credentials we only ever need to check are stored as one-way hashes, so we cannot read them back even from our own database. That covers API keys, OAuth access and refresh tokens and authorization codes, supplier-portal sessions and their password-reset tokens, and the single-use codes in email sign-in links. An API key is shown once, at creation, and never again.

Two credentials are deliberately not hashed, because the platform has to use them rather than merely verify them: the secret an outgoing webhook is signed with, so that your endpoint can check the signature, and the token we present to a registered supplier's own pricing API. Those stay recoverable by the application by design. We state that explicitly rather than let the sentence above be read as covering every credential we hold. Neither is returned by any interface, API response or data export after it is set.

Session tokens are opaque random values rather than encoded credentials, held in HttpOnly, Secure, SameSite cookies and in the session table, and they expire.

Molecular structures submitted to the platform are used for generating retrosynthesis routes and related analysis, and for nothing else. We do not use customer task data to train or fine-tune our models without your explicit written consent. Two derived caches are shared across customers and keyed by the content rather than by the account, so a reaction one customer asks about can be answered from a cached prediction without either customer being identified to the other; those caches are listed in the deletion report a full erasure produces, because they are the stores an erasure by account cannot reach. Your molecular IP remains yours; see our Terms of Service for the IP-ownership posture.

The platform runs on Google Cloud Run, with a managed PostgreSQL database that accepts only encrypted connections and is reachable only through an authenticated connector, never directly from the public internet. Each release is a new immutable revision, so a rollback is a traffic switch back to the previous one rather than a redeploy. The production and staging web services and their databases are separate; the inference hosts behind them are not, so staging load reaches the same model servers that serve production. The application has a deep healthcheck endpoint that probes the database, queue, and model servers, and circuit breakers in front of external dependencies (PubChem, payment processor, model servers) gracefully degrade when an upstream is slow or unreachable.

The application database is backed up at least daily, and the most recent 30 daily images are kept, so ordinary retention is about a month. They are encrypted at rest and stored in a separate failure domain from the live database. Recovery lands on one of those daily images and takes hours; we do not offer point-in-time recovery to an arbitrary moment. We also take an image before each production release, and those sit outside the daily rotation and are kept until they are deliberately destroyed.

Deletion works at two levels, and the difference is worth stating plainly. Deleting your own account marks your tasks, projects and API keys deleted and removes them from the product immediately; the underlying rows are retained until a full erasure is carried out. A full erasure, which an organisation can request and which we run for an enterprise customer at the end of an engagement, removes the rows themselves and is verified by counting every affected table before and after, so what you receive is the counts rather than an assurance. The same report names every store that a database deletion does not reach, including the content-keyed caches, our application logs, the database dump buckets and the backup images, so the list is in front of you rather than left to be asked for. Backup images predating the deletion are destroyed as part of the request and attested with their identifiers, which we check against the instance rather than take on trust, because the pre-release images do not age out on their own. Some records are kept longer where law requires it, for example tax records.

Authentication is handled through industry-standard protocols. Session tokens are high-entropy random values carrying no encoded claims, stored in HttpOnly, Secure cookies, and they are never written to browser local storage. Enterprise SSO integrations use OAuth 2.0 / OpenID Connect through Microsoft Entra ID. The identity provider verifies who you are; the session record itself is stored in our own database rather than with a third party, so session lifetime and revocation are ours to control. API keys are scoped to the issuing user, can be rotated or revoked at any time, and are rate-limited per key.

Where a customer requires it, each class of outbound lookup can be switched off for their organisation independently, and the switch is enforced server-side rather than in the interface:

• Third-party compound lookups: PubChem and equivalent external catalogs. Off means sourcing and safety data come only from what we already hold.
• Live supplier queries: per-compound requests to a registered supplier's own API. Off by default, at the supplier record itself, and requires a deliberate change to enable. A supplier registering an endpoint does not by itself start sending them customer structures.
• Third-party enrichment: annotation services that receive a compound identifier. Today this is the compound-novelty badge, which sends InChIKeys to Google BigQuery.
• Shared first-party services: services we operate ourselves but run across tenants, currently the IUPAC naming engine. A structure sent here never leaves SynovAI, but it does leave a dedicated customer's own boundary, so it is switchable for anyone who draws the line there.
• Public sharing: whether members may make a task publicly visible at all. Off means the capability is removed for that organisation rather than left to individual discretion.

Retrosynthesis and condition-prediction inference is deliberately not on this list. Turning it off would be indistinguishable from cancelling the product, so the line we draw is that optional ancillary lookups can be switched off and core inference cannot. We would rather say that plainly than offer a switch that no customer could use.

Controls agreed contractually can be locked by us, so that they cannot later be loosened from inside the customer's own admin interface by someone who did not see the agreement. A tenant administrator may always make their own policy stricter.

Some of the most useful things to know about a platform are the things it does not have. Each of these is a property of how SynovAI is built rather than a setting:

• Your chemistry is not sold, brokered or used to target advertising. We do not run an advertising business and your structures are not a product we sell. Any service that processes your data appears in the sub-processor list above, which is the list to check rather than taking a promise about a category.
• Our retrosynthesis and condition models are our own. They run on infrastructure we operate, so predicting a route does not send your structure to a general-purpose AI provider. If that ever changes for a feature, that provider appears in the sub-processor list above and sits behind the per-tenant egress controls below, like every other outbound lookup.
• No staff route into your chemistry. Administering the platform and reading what a customer made with it are separate things. There is no staff override that opens a customer's tasks in the product.
• Deletion is certified by counting, not asserted. When a customer's data is deleted we count every affected table before and after, and the routine refuses to report success while any count is non-zero. What you receive is the counts, not a confirmation message.

Where data is held is a property of the deployment rather than a setting inside the product, because nothing in the platform selects a region while it runs. A trial is launched as a dedicated deployment in the customer's region once they agree to it: their own database and backups, application service, scheduled jobs, log bucket and their own instances of every model service. The shared platform is in the United States.

We monitor platform availability continuously and maintain a documented incident-response playbook covering the most likely failure classes. In the event of a confirmed security incident affecting customer data, we will notify affected customers without undue delay and in any case within 72 hours of confirmation, with the information available at the time and follow-up communications as the investigation continues. Confirmation is a defined event in that playbook rather than a judgement made in the moment: where we cannot rule exposure out within 24 hours of a report, we treat the incident as confirmed and start the clock.

The live state of each platform component is published at /status, which reports whether each dependency is up rather than carrying an incident narrative. An incident affecting customer data is communicated directly, by email, to the named security contact for each affected customer. The playbook itself is available to enterprise customers on request as part of a security review.

If you have specific data security requirements, want to start a security review, or need to report a suspected vulnerability, contact us at info@synovai.net.