Security

Security

What protects a desk holding other companies' customer correspondence, described precisely enough to check. Last updated 19 September 2026.

A support desk holds the most sensitive thing a business owns after its accounts: what its customers actually said, in their own words, with whatever they attached. Everything below is a property of the running system, not an aspiration, and the last section is the list of things we do not have — because a security page without one is marketing.

Tenant isolation

  • Every ticket, message and file is scoped to a desk in the storage path itself. A query from one desk has nowhere to reach another; isolation is structural rather than a filter that could be forgotten.
  • No browser writes to the database. Every stored collection refuses client writes outright — all writing goes through the service, which resolves who you are first.
  • A new collection is denied until somebody allows it deliberately. The rules enumerate the tree rather than using a catch-all, so the default for anything new is "no".
  • The rules running in production are checked against the ones in our source on every deploy, and a deploy stops if they differ.

Who gets in

  • We hold no passwords. Sign-in is your MyAndGo account through Google, Microsoft or Apple; we never see or store a password, and there is no separate password to breach.
  • Membership is keyed to your identity, and everyone after a desk's first owner arrives by invitation matched on an address the hub has verified. An invitation email carries no token and no authority — losing one costs nothing.
  • Sessions expire. A signed-in session has a hard seven-day life anchored to the sign-in itself, not to a value in the browser.
  • Our own access to a customer desk is recorded — who, which desk, when — in an audit log you can ask us to produce.

The data itself

  • Stored in Sydney (australia-southeast1): the database, the files and the service. Why the operating company matters as much as the region.
  • Encrypted in transit and at rest.
  • Attachments live in a private store that refuses public access outright, and are served only through an authenticated request that re-checks the file belongs to your desk. They are returned in a way that cannot execute in a browser.
  • Backups run daily, kept seven days, plus a weekly backup kept fourteen weeks.
  • Deleted files remain recoverable for seven days and are then permanently gone — which is true, where "deleted instantly" would not be.

What arrives from outside

  • Every automated sender is authenticated with a signature checked in constant time, and a time window so a captured request cannot be replayed later.
  • Forged email is contained. We read the SPF and DKIM verdicts on inbound mail: a message that fails authentication cannot join an existing conversation, and junking it can never teach the desk to block the address it was pretending to be. It is still delivered and still answerable — ordinary forwarded mail fails those checks routinely.
  • Hostile content cannot stall the service. Message parsing is bounded by construction, so a deliberately malformed message costs milliseconds rather than blocking other customers' mail.
  • Customer HTML never reaches an agent's browser as HTML. It is converted to text on the server, so a message cannot run script in the cockpit.

The AI

  • It runs in Sydney, and refuses to run anywhere else. The code checks the resolved endpoint before every call and fails closed rather than falling back to an overseas region.
  • A person approves anything that reaches a customer. The AI drafts; it does not send.
  • Customer text is fenced before it reaches the model, and the model's answer is constrained to a fixed set of values rather than being trusted as instructions.
  • Your customers' messages are not used to train models.

How the service is built and shipped

  • A deploy refuses to ship on a failing test, and the suite includes the isolation tests that prove one desk cannot read another's data.
  • The browser is sent a strict content policy that forbids inline and evaluated script, refuses to be framed by another site, and names every origin the app may contact.
  • Security fixes carry a test that fails if the fix is removed, and we check that by removing it deliberately before we trust it.

What we do not have

Published here for the same reason our comparison pages carry a section on where the competitor is better: you will find out anyway, and it is worth more coming from us.

  • No SOC 2, ISO 27001 or IRAP assessment. If your procurement process starts with one of those attestations, the incumbents have them and we do not.
  • No third-party penetration test yet. The security work described above is our own, reviewed by us.
  • No customer-managed encryption keys, and no bring-your-own-cloud deployment.
  • Three providers handle data outside Australia — email delivery, push notifications, which carry no content at all, and voicemail on desks that enable a phone number. They are named on the privacy page, with what each one sees.

Reporting a vulnerability

Email supportandgo@support.myandgo.com.au with enough detail to reproduce it. We will acknowledge you, tell you what we found, and tell you when it is fixed. We will not take action against anyone who reports a genuine issue in good faith and does not access or alter other people's data while finding it.

Common questions

Can one business's agents ever see another's tickets?

No. Every ticket, message and file is scoped to a desk in the storage path itself, so a query from one desk has nowhere to reach another, and the database refuses writes from browsers entirely. The isolation tests that prove it run on every deploy, and a deploy stops if they fail.

Do you hold our passwords?

No. Sign-in is through your MyAndGo account using Google, Microsoft or Apple. We never see or store a password.

Are you SOC 2 or ISO 27001 certified?

No, and we would rather say so here than let you find out in a procurement questionnaire. We have no third-party penetration test yet either. What we can show you is the architecture, the audit log, the deletion certificate and the region every component runs in.

What happens if there is a data breach?

If a breach is likely to cause serious harm we notify you and the Office of the Australian Information Commissioner, as the Notifiable Data Breaches scheme requires.