Security at Sully

Your walks, your account and our database are stored in Australia, in Google Cloud’s Sydney region. Our API and processing services run on Cloud Run, our database is Cloud SQL for PostgreSQL, and files are kept in Cloud Storage, which holds redundant copies across the region.

Our websites and web app run in Vercel’s Sydney region and are delivered over its global edge network.

Some processing happens outside Australia: every AI model step, transcription included, runs on Google’s global Vertex AI endpoint. Our service logs, which include IP addresses, are kept in Google Cloud’s logging service, which is not limited to the Sydney region. Our Privacy Policy sets out exactly which steps, and lists every provider that can receive personal information.

Production runs in its own Google Cloud project, separate from development, and development holds no customer data.

Every connection to Sully is encrypted with TLS. Our sites and API send HTTP Strict Transport Security headers, so browsers refuse unencrypted connections, and the connection between our services and the database is encrypted too. Uploads go straight from your device to our storage over HTTPS, through signed upload links.

Data at rest is encrypted by Google Cloud with Google-managed keys. The credentials that let Sully deliver to your Microsoft or Google account are encrypted again with a dedicated key in Google Cloud KMS, which rotates every 90 days.

Our database has no public address; it is reachable only from our private network. Our processing services accept no traffic from the internet. Our API sits behind a Google Cloud load balancer that redirects plain HTTP to HTTPS and blocks our internal endpoints at the edge. Calls between our workflow services carry signed requests, and storage events reach our API with Google-issued identity tokens.

You can sign in with your Microsoft or Google work account, so your organisation’s password and multi-factor rules apply to Sully. A workspace can require that everyone with its email domain signs in with Microsoft.

Accounts that use a password need a verified email address and a password of at least 10 characters, and can add an authenticator app with backup codes. Accounts are linked across sign-in methods only through a verified email address, and sessions use secure, HTTP-only cookies.

Every record in Sully belongs to a workspace, and every request is checked against your membership of that workspace before any data is read. A workspace can limit a member to the projects they are added to. Automated checks on every code change enforce how our code is allowed to reach data.

Share links use long random tokens that we store only in hashed form, and they expire after 90 days unless you choose otherwise. We can revoke a share link for you at any time.

Only a small number of Hey Sully staff can reach production systems, each with the access their role needs and no more. Each of our services runs under its own identity and can read only the secrets it needs.

To help with a support request, an authorised staff member can see a workspace as its user sees it. That view is read-only, lasts at most 15 minutes, and cannot be used on another administrator. A lasting record of who opened it, whose account it was and when is written before the view opens, and a view that cannot be recorded is refused.

Every AI step, transcription included, runs on Google’s Vertex AI, whose terms bar Google from using your content to train its models without our permission. We use only models Google has released as generally available, which its data processing terms cover, never preview releases.

We do not use your walks to train AI models. Our analytics provider receives technical measurements of each AI step, such as which model ran and how long it took, never the content of your walks.

For your AI due diligence, for example under the RICS professional standard on the responsible use of artificial intelligence, we will give you written information on request about how Sully processes content, its limitations, and what each provider may do with it.

Our infrastructure is defined in code and changed through pull requests. Every change runs automated checks, including type checking, linting, tests, builds and our architecture rules. Production updates deploy from our main branch and roll back automatically if a deployment fails its checks.

Our deployment pipeline reaches Google Cloud with short-lived federated credentials rather than stored keys. Application secrets live in Google Secret Manager, each readable only by the service that needs it. Our database, storage and encryption keys are protected against accidental deletion.

Dependency updates are proposed weekly and screened for supply-chain risk. Our sites send security headers that stop other sites framing them and stop browsers guessing content types.

Our database is backed up every day. Backups are kept for 14 days, and point-in-time recovery covers the last 7 days.

We aim to keep Sully available, and our services report errors as they happen so we can respond. We do not offer a service level commitment unless your signed agreement includes one.

If we become aware of a data breach that affects your information, we will contain it, assess it, and tell the affected customers without undue delay. Where the Notifiable Data Breaches scheme applies, we will notify the people affected and the Office of the Australian Information Commissioner as it requires. Our Data Processing Addendum sets out what we commit to for your firm.

Sully does not yet hold an independent security certification such as SOC 2 or ISO 27001, and has not yet had an external penetration test. We will update this page when that changes. In the meantime, we are happy to answer your security questionnaire.

If you think you have found a security vulnerability in Sully, email hello@heysully.ai with “Security” in the subject line, the steps to reproduce it, and what someone could do with it. We will acknowledge your report within 3 business days and keep you updated while we fix it.

Please give us a reasonable chance to fix the problem before you tell anyone else, do not access or change data that is not yours, and do not degrade the service for other people. If you act in good faith within these rules, we will not take legal action against you for your research. We do not currently run a paid bug bounty.

Security questions, questionnaires and reports go to hello@heysully.ai. Our security contact is also published at heysully.ai/.well-known/security.txt.