Security Overview

This page describes, in plain language, how Neivan Technology Holdings, LLC ("Neivan") protects data in the Synapse platform. It is a summary, not a contract: our commitments are in the Terms of Service and the Data Processing Agreement. Anything not yet in place is marked Planned, so this page never claims more than we do.

"Customer" means an organization that uses Synapse; "Authorized Users" are that organization's people.

1. Where data lives

• The platform runs on DigitalOcean in New York, and its database, sign-in and file storage run on Supabase in AWS us-east-1 (Virginia). Both are in the United States. The full list of providers is on our Subprocessor List.
• EU or UK data residency is not offered today.

2. Encryption

• In transit. Our domains accept only HTTPS (TLS 1.2 or newer), and browsers are told to always use HTTPS (HSTS, preloaded).
• At rest. Stored data is encrypted at rest by our database and hosting providers.
• Credentials. Connection tokens, API keys for connected apps, and customers' own AI provider keys are additionally encrypted by Synapse itself (AES-256-GCM) before they are stored, are only decrypted on our servers when needed, and are never sent to the browser.

3. Keeping each customer's data separate

• Synapse is multi-tenant. Every customer data table enforces row-level security in the database, so a query can only reach the rows of the organization it runs for.
• Personal data inside a workspace — such as an individual's personal knowledge — is further restricted to that person.

4. Access control inside your organization

• Roles and permissions. Administrators decide what each role can do; permission checks run on the server, not only in the interface.
• Approvals. Agent actions that reach outside the platform — such as sending, posting or deleting — can be set to wait for a person's approval; publishing to or deleting from a connected social-media account always requires it.
• Session limits. Sessions end after the period of inactivity your organization sets. Whatever that setting, a session also ends after 7 days without use, and 30 days after sign-in.
• Audit log. Administrative and security-relevant actions are recorded in an audit log that administrators can review. Recorded entries cannot be edited.
• Multi-factor authentication. Available to every customer account: anyone can add an authenticator app. Once a person has one, signing in asks for its code after the password, and our servers refuse a session that has not entered it. Administrators can require multi-factor authentication for everyone in their organization. Sensitive changes — deleting an account, creating or revoking agent runtime keys or the SCIM provisioning token, configuring single sign-on, changing roles, permissions or members, and turning the organization's multi-factor requirement on or off — ask a person who uses an authenticator for a code entered within the last 10 minutes.
• Sign-in protection. Sign-in, sign-up and password-reset forms include an automated-abuse check (Cloudflare Turnstile). Passwords must be at least 12 characters and include a lower-case letter, an upper-case letter, a digit and a symbol, and passwords known to have appeared in data breaches are refused.
• Invitations. An invitation link stops working 48 hours after it is sent, and we store only a hash of it, not the link itself.
• Single sign-on. SAML single sign-on and SCIM user provisioning are in development; contact us if you need them.

5. Access by Neivan staff

• Only a small number of Neivan staff have production access, and only to operate and support the Service.
• Our operations console requires multi-factor authentication for every staff account: a staff session that has not entered an authenticator code is refused.
• When staff need to look at a customer account for support, they use a read-only, time-limited support view; every such session is recorded in the audit log.

6. AI providers

• Neivan-managed AI features send the prompt and the content needed for a request to Anthropic or OpenAI through their APIs. Under those providers' API terms, that content is not used to train their models.
• Neivan does not use customer content to train any model.
• If a customer connects its own AI provider key, those requests go to that provider under the customer's own account.

7. Observation and the Recorder

Observation features are off until a Customer enables them and the person being observed consents. What is and is not captured — including that Recorder screenshots are not redacted — is set out in the Observation & Screen-Recording Disclosure.

8. Application security

• Code changes are reviewed and tested before they are released.
• Errors in production are reported to our error-monitoring provider (Sentry) so we can find and fix them.
• Uploaded files are accepted by what their content actually is, not by the file name or type the uploader gives them.
• Webhooks that start a workflow can be signed: each request carries an HMAC-SHA256 signature over a timestamp and the request body, and a request is refused if its signature is wrong, its timestamp is more than 5 minutes away from when it arrives, or the signature was already used. New webhooks require a signature.
• Planned: automated security scanning on every change, and an independent penetration test.

9. Backups and recovery

• The database is backed up automatically once a day by our database provider (Supabase), and the daily backups from the last 7 days are kept.
• Point-in-time recovery is not enabled, so a restore returns the database to the most recent daily backup, and changes made after that backup could be lost.
• Files kept in file storage (such as uploads and Recorder screenshots) are not included in the database backups.
• We maintain a written backup and recovery procedure.
• Planned: point-in-time recovery, published recovery objectives, and regular restore drills.

10. Incidents

• We follow a written incident-response plan.
• If a security incident affects a Customer's personal data, we notify that Customer without undue delay, and no later than 72 hours after we confirm it, with the information we have to help the Customer meet its own obligations.

11. Compliance

• We have not completed a SOC 2 audit or ISO 27001 certification. We have written security policies modelled on SOC 2 and are working toward an independent audit.
• HIPAA: Synapse is not designed for protected health information, and we do not sign business associate agreements today.

12. Reporting a vulnerability

Email [email protected]. Please give us a reasonable time to fix an issue before disclosing it. Our security contact is also published at https://neivan.ai/.well-known/security.txt.

13. Shared responsibility

We secure the platform. Each Customer is responsible for how it uses it: who gets access and which roles they hold, which apps are connected and what agents may do in them, whether actions require approval, whether observation is enabled, and keeping its users' sign-in details safe.