Security overview

1. Keeping customers apart

• Every query for customer data is scoped to one workspace. The workspace is resolved on the server from a checked membership, never taken from what the browser sends.
• Each action then checks the person’s role and permissions. Roles run from Owner to Client, and agencies can narrow what each member may do.
• Automated tests try to reach one tenant’s data from another’s account, and must fail to before a change can ship.
• Websites and funnels customers publish are served under a sandboxing Content Security Policy, so their markup cannot act on the application.

2. Encryption

• All traffic is encrypted in transit with TLS.
• The database and file storage are encrypted at rest by our hosting providers.
• Credentials for the services you connect — API keys and OAuth tokens — are additionally encrypted with AES-256-GCM before they are stored.
• Passwords are hashed with bcrypt. Session tokens, API keys and two-factor recovery codes are stored only as hashes, so a copy of the database does not contain them.

3. Accounts and access

• Two-factor authentication with an authenticator app, and one-time recovery codes.
• Rate limits on sign-in, signup and password reset, and sign-in responses that do not reveal whether an account exists.
• Accepting an invitation for an existing account requires signing in to it, so an emailed link alone cannot open an account.
• REST API keys and connected AI agents act with the permissions of the person who created the key, never more.
• Our own staff tools are separate, logged, and cannot widen a customer’s access.

4. Application security

• A strict Content Security Policy is set on every response, alongside standard security headers.
• Requests the service makes to addresses you supply, such as webhooks, are checked so they cannot reach internal networks.
• Secrets are compared in constant time, and never sent to the browser.
• Every change the AI assistant makes is recorded against the person who asked for it, and the assistant can only reach what that person can.
• Error reports strip what people typed, contact details and IP addresses before they leave the service.

5. Infrastructure and backups

Systemly runs on Vercel, with the database on Neon and background processing on Fly.io, all in the United States. The database provider keeps continuous backups that allow it to be restored to an earlier point in time. The full list of providers is on the sub-processors page.

6. Incidents

If we become aware of a data breach that is likely to result in serious harm, we will notify affected customers and the Office of the Australian Information Commissioner as the Notifiable Data Breaches scheme requires. Customers on the data processing agreement are told without undue delay, with the information they need to meet their own obligations.

7. Reporting a vulnerability

If you find a security problem, email legal@systemly.com.au with the details. Please give us a reasonable chance to fix it before telling anyone else, and do not access other customers’ data or disrupt the service while testing. We will not take action against good-faith research that follows these rules.