Privacy

Who we are

Calliper is a console for managed service providers. It connects to the Microsoft 365 and Google Workspace tenants a provider manages, tests security controls against them, and reports what it found. It is operated by BaseHost, a managed service provider based in Melbourne, Australia.

The entity responsible for the personal information described in this policy is Anamorphic Creations Pty Ltd (ACN 087 351 102), trading as Calliper, ABN 40 087 351 102, of Suite 1, 293 Bay Street, Brighton, Victoria 3186, Australia. Everything in this policy applies to Calliper itself. A provider using Calliper publishes their own privacy policy to their own clients, and that document is theirs rather than this one.

This policy covers the Calliper platform at app.calliper.ai, this marketing site at calliper.ai, and the client portal a provider invites their clients into. It does not cover a provider's own systems, or the Microsoft and Google tenants Calliper reads.

The law this is written under

We are an Australian business. We handle personal information under the Privacy Act 1988 (Cth) and the Australian Privacy Principles, and the regulator is the Office of the Australian Information Commissioner.

Where a provider's client is outside Australia, that provider may have obligations we do not, and the agreement between us is where those are dealt with rather than here.

Whose information this is about, and who decides what happens to it

There are three groups of people in this platform and they are not in the same position, so the policy says which is which rather than treating them as one.

• People at a providerThe managed service provider who subscribes to Calliper. We hold their staff as a list of who may sign in, their billing contact, and the record of what they did in the console. They are our own customer and we decide, with them, what we hold.
• People at a provider's clientThe organisations a provider manages, and the people inside them. Almost none of this is stored: Calliper reads a client's directory live and discards it. What is stored is the finding rather than the evidence behind it, and a provider decides which clients are connected at all. We hold it on their instruction and for the purpose of running the service they bought.
• People BaseHost has not metProspects, and anybody who fills in a form on a provider's front door. This is BaseHost's own sales activity or the provider's, and is the one category here that is not a byproduct of running the platform. It is listed in the register below with the rest.

The design rule this whole policy rests on

Calliper is built to be a window into a client's tenant rather than a copy of it. Users, groups, devices, mailboxes, licences and directory roles are read at the moment somebody looks and are not written down. What persists is the finding: that a control passed or failed on a date, that somebody signed an attestation, that a provider granted an exemption and why.

That is not a preference about privacy. It is about who is in scope when a client is audited: the moment this platform holds a client's data, BaseHost becomes a third party inside that client's own compliance programme, a subprocessor on their data-flow diagram and a party whose breach becomes their notifiable incident. The register below is the full list of the places that rule has a deliberate exception, and each one says why.

Where it is held

Everything Calliper stores is in Australia. The one part of the platform that is not is named in the list of recipients further down, and so is every third party that receives data without storing it.

• The applicationSydney (Vercel syd1)
• The databaseSydney, Australia (Supabase on AWS ap-southeast-2)
• Compute we operate ourselvesSydney, Australia (AWS ap-southeast-2). The Zabbix monitoring server, the two worker nodes that touch client data, and the Respond event store with its private snapshot bucket. The probe nodes that watch public addresses also run in Singapore, Oregon, N. Virginia and Ireland, and deliberately hold nothing: they check an address and report the verdict to Sydney.
• File storageNot used. The store is empty and the dependency is removed.
• The one thing that leaves, and it is not storedTest traffic goes to Cloudflare's nearest data centre, not to BaseHost. Cloudflare sees the visitor's IP address. Nothing is stored, by them or by us, and the page says so before the test runs.

Everything we hold, store by store

This is not a summary. It is the platform's own data register, rendered onto this page from the same file the engineering team appends to in the change that adds a store. Every entry says what is in it, why the service cannot work without it, where it came from, how long it is kept, and what is deliberately not kept.

The last of those is the one worth reading. A register that only lists what is held shows nothing about whether anybody thought about it; a register that says we hold that a control failed and do not hold which of your staff it named shows a decision was made, and points at the line that records it.

We group what we hold into four kinds. The counts below are computed from the same register the platform keeps for assessors, so they move when Calliper does rather than when somebody remembers this page. Across all four there are 155 record types covering 206 stores, and 60 of them hold something that identifies a person other than a member of our own staff.

The full register, store by store, is what we give an assessor and is what sits behind these four groups. Ask us for it, or for what we hold about you in particular, and we will send it: Australian Privacy Principle 12 gives us 30 days and we do not need that long.

Google user data

A Workspace customer is connected when one of their own super administrators signs in at Google and approves Calliper's consent screen. What comes back is a refresh token carrying that person's authority, and it is the only credential this platform holds for any customer directory. It is encrypted with AES-GCM under a key held in the environment, it is never returned to a browser, and the administrator can end the grant at any time from myaccount.google.com/permissions, which stops every reading immediately.

These are the scopes Calliper asks for. Every one is read-only except one, which is labelled as a change: it lets Calliper make a person a super administrator, or take that role off them, when a fix the provider has approved needs it, and it does nothing else to an account. Nothing else in this integration can change anything in a Workspace, and no Gmail, Drive, Calendar or Chat scope is requested at all.

Delegated access. Calliper holds no service account key and uses no domain-wide delegation. The authority is one administrator’s, granted at Google’s own consent screen, and it ends when that account does.

• https://www.googleapis.com/auth/admin.directory.user.readonly

  The list of user accounts, whether each is suspended, and what each one reports about its two-step verification. Answered by the Admin SDK Directory API.

• https://www.googleapis.com/auth/admin.directory.customer.readonly

  Which Workspace customer answered, and its primary domain. This is what names the connection. Answered by the Admin SDK Directory API.

• https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

  Which accounts hold administrator roles, so a super administrator can be told apart from a delegated one. Answered by the Admin SDK Directory API.

• https://www.googleapis.com/auth/admin.directory.domain.readonly

  Every domain this Workspace customer sends mail from, not only the primary one. The email authentication checks (SPF, DKIM, DMARC) grade each domain, and without this they can only see the primary domain. Answered by the Admin SDK Directory API.

• https://www.googleapis.com/auth/admin.reports.audit.readonly

  What administrators last changed in the Admin console, for the nine settings the Google policy API does not return: Gemini access and beta features, Gemini notes sharing in Meet, the Gmail security sandbox, Context-Aware Access, post-SSO verification and multi-region processing. Only changes to those settings are kept, and only long enough to be graded. Answered by the Admin SDK Reports API.

• https://www.googleapis.com/auth/admin.directory.user

  Permission to make a person a super administrator, or to take that role off them, when a fix the provider has approved needs it. Nothing else about an account is changed: it only ever acts on a person named in the approval, and it never creates, deletes, suspends or edits a user. Answered by the Admin SDK Directory API.

• https://www.googleapis.com/auth/cloud-identity.policies.readonly

  The administrative policy settings this organisation has chosen: external sharing, two-step verification, Gmail safety, Drive sharing and the service policies beside them. This is what a posture reading of a Workspace customer is made of. Answered by the Cloud Identity API.

• https://www.googleapis.com/auth/userinfo.email

  The address of the administrator approving this, and nothing else about them. A grant of this kind ends when that account does, so a connection that stops working is otherwise a mystery. Answered by the Google Identity.

Calliper's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Read the Google API Services User Data Policy.

What happens to Google user data once it is read

It is read at the moment somebody looks at a compliance result, and it is discarded when the request ends. The account list, whether each account is suspended, whether it reports two-step verification, and which accounts hold administrator roles are all read live. None of it is written to our database, and there is no copy of a customer directory anywhere in this platform.

What is written is the outcome: that a control passed or failed for that customer on that date. The full record of what is stored about a connected Workspace customer is the entry named Connected Google Workspace customers in the register above, and it is the whole of it.

Google user data is used only to provide and improve the features the connecting administrator granted it for: measuring that customer's security controls and reporting the result to the provider who manages them. It is not sold. It is not used for advertising. It is not used to train any model, and it is not sent to the AI provider named in the recipients below, which receives organisation names and domains and is refused personal data by a runtime check rather than by convention.

Nobody's name is read. Calliper reads an account's Google identifier and its primary email address, its suspended and archived state, whether it holds a super administrator or a delegated administrator role, what it reports about two-step verification, and when it last signed in. It does not request or read a person's given name, family name, photograph, phone number, address, or any other profile field.

How it is protected

Only the controls this deployment actually has. There is no certification behind any of this: BaseHost holds no accreditations, is not an assessor, and nothing here should be read as an audited claim.

• No public database accessRow level security is enabled on every table with no policies granted, so the publishable key reads nothing at all. Reads and writes go through server-side code holding a secret key that never reaches a browser.
• Encrypted in transit and at restTLS to the database and to every API. Supabase encrypts stored data at rest on AWS.
• Access limited to named staffSign-in is restricted to a single Microsoft Entra tenant, a BaseHost address, an assigned application role and membership of a named security group. Membership is re-checked on every request rather than at sign-in, so removing somebody takes effect within minutes.
• Sessions expire in eight hoursRather than the thirty-day default. Sessions are tokens and cannot be revoked centrally, so the window is kept short deliberately.
• No standing write access to client directoriesDirectory role assignment borrows a client administrator's authority for one call and stores no refresh token. No application here holds standing permission to change directory roles. A connected Google Workspace customer is the one place a refresh token is held at all, and every scope on it is read-only, so it is standing read access and not write access — the entry for google_workspace_connections says what it is and how a client ends it.

Who else receives it

These are the third parties that data actually reaches, with the place in the platform each relationship lives so the claim can be checked rather than taken. A provider's own connected tools are not on this list: a provider supplies their own credentials for their own RMM, backup, billing and chat systems, and what flows to those is between the provider and their supplier.

We do not sell personal information, we do not disclose it for advertising, and there is no analytics, tag manager or advertising pixel on any Calliper surface.

• Vercel. Sydney, Australia (syd1).Runs the application itself. Every request passes through it. vercel.json pins the region and the scheduled jobs.
• Supabase. Sydney, Australia (AWS ap-southeast-2).The database. Everything in the register above is stored here and nowhere else. lib/supabase.ts is the only path to it, and it holds a secret key that never reaches a browser.
• Amazon Web Services. Sydney for the database and the monitoring server. The probe nodes also run in Singapore, Oregon, N. Virginia and Ireland, and hold nothing.The substrate Supabase runs on, and the machines Calliper operates itself: the monitoring server and the probe nodes. Named in the register's own region list above.
• Railway. Singapore. That is offshore, it is recorded here rather than left to be discovered, and it is the one part of the platform that is not in Australia.A container that does the three things a serverless runtime cannot: open an SMTP connection, run a headless browser to render a PDF or a page speed audit, and run PowerShell. It holds no database credentials and stores nothing. worker/ in this repository, called through lib/worker-client.ts.
• Microsoft. Microsoft's own regions for the tenant being read.Signs staff in through Entra ID, and answers the reads Calliper makes against a connected client's Microsoft 365 tenant under consent that client's own administrator granted. The Microsoft Graph calls throughout lib/, and the consent flow at /api/admin-consent.
• Google. Google's own regions.Answers the Workspace directory reads described in the Google Workspace section below. Google Fonts also serves the typefaces on this marketing site, which means Google sees the IP address of anybody reading this page. lib/google/ for the directory, and the stylesheet link in app/(marketing)/layout.tsx for the fonts.
• SendGrid, part of Twilio. SendGrid's own regions. Offshore.Sends every email the platform sends: alerts, digests, reports and portal invitations. It receives the recipient's address and the content of the message. lib/sendgrid.ts and worker/src/email.js.
• Twilio. Twilio's own regions. Offshore.Sends SMS alerts, where a provider has configured one. It receives the number and the alert text. lib/alerting/senders.ts.
• Stripe. Stripe's own regions. Offshore.Bills a provider for their Calliper subscription. Card details are typed into Stripe's own fields inside our page and never reach this application, which is why no payment instrument appears anywhere in the register above. lib/billing/stripe.ts, and the billing entry in the register.
• Anthropic. Anthropic's own regions. Offshore.Answers the staff search box, the application packaging recipe and the printer driver lookup. What is sent is decided by hand in one module rather than inherited from whatever a reader returned: organisation names and domains go, and nobody's name and nobody's address do. A runtime check refuses a request carrying personal data rather than trusting the projection. lib/search/readers.ts names every field that leaves, and lib/search/personal-data.ts enforces it.
• Cloudflare. Cloudflare's nearest data centre, which for an Australian visitor is an Australian one.Measures the speed test on this site, and answers DNS lookups the platform makes. A visitor running the speed test opens connections to Cloudflare, so Cloudflare sees their IP address. Nothing is stored by them or by us, and the page says so before the test runs. lib/speed-test-config.ts switches the engine's own results logging off.
• Globalping. Wherever the probe answering the measurement is. Offshore by design.Runs a DNS or network measurement from a machine in the country being asked about, which is the only way to see what a user there is handed. It receives the address being measured. lib/globalping.ts.
• Lusha and the Australian Do Not Call Register. Lusha's own regions. Offshore. The Do Not Call Register is Australian.Lusha supplies the business contact details behind BaseHost's own sales prospecting. Phone numbers are washed against the Do Not Call Register before anybody is called. This affects prospects only and nothing here touches a client's data. lib/prospecting/, and the prospecting entries in the register above.

Information that goes overseas

Australian Privacy Principle 8 is about disclosure to a recipient outside Australia, and the honest answer is that some of this platform does that. Every store is Australian. Several of the services in the list above are not, and they are marked.

The ones that matter most: email is sent through SendGrid, subscription billing runs through Stripe, SMS alerts go through Twilio, the worker that renders documents and opens SMTP connections runs in Singapore, and the search feature sends organisation names and domains to Anthropic. The prospecting data BaseHost buys comes from Lusha. Serving this page fetches typefaces from Google Fonts, which means Google sees the IP address of anybody reading it.

The database moved from Virginia to Sydney on 27 August 2026 for exactly this reason, and the rule since is that a new store in another region is a decision taken explicitly rather than inherited from wherever a service happens to default.

How long it is kept

Store by store, in the register above. There is no single retention period, because a compliance finding and a notification are not the same kind of record and giving them the same answer would be a worse policy rather than a simpler one.

Three different mechanisms enforce those periods and it is worth knowing which one is behind a given line. Some stores are pruned by a scheduled job that runs daily. Some hold one row that is replaced on every sweep, so there is no history to prune. Most are tied to the life of the thing they belong to, and go when the tenant, the provider or the connection goes.

Where the register says a record is kept, it means kept, and the entry says why. An authorisation to run an invasive test, the record of what that test sent, and the decision somebody took about a client are all deliberately permanent, because the value of that kind of record is only ever realised after something has gone wrong.

Asking what we hold, and asking us to fix it

You can ask what personal information we hold about you and ask us to correct it. Write to legal@calliper.ai or to Suite 1, 293 Bay Street, Brighton, Victoria 3186, Australia. We will ask enough to be sure who you are, and then answer. Australian Privacy Principle 12 gives us 30 days.

Where we hold information about you because a provider connected your organisation, the fastest route is usually that provider, because they hold the relationship and can often answer without us. You do not have to go to them first, and we will not refuse a request because you came to us directly.

If we refuse an access or correction request we will tell you why in writing and how to complain about it.

Complaining

If you think we have handled your information badly, tell us first at legal@calliper.ai. We will acknowledge it and tell you who is looking at it.

If we cannot resolve it, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au. You do not need our permission to do that, and you can go to them at any point.

If something goes wrong

The Notifiable Data Breaches scheme in Part IIIC of the Privacy Act applies to us. Where a data breach is likely to result in serious harm and we cannot prevent that harm, we are required to notify the people affected and the Office of the Australian Information Commissioner, and we will.

Where the breach involves data we hold because a provider connected their client, that provider will be told as well, because it is their client relationship and very often their notification to make.

Cookies and tracking

There is no analytics on any Calliper surface, no tag manager, no advertising pixel and no cross-site tracking. This marketing site sets no cookie of its own.

Signing in to the console or the client portal sets a session cookie, because that is what a session is. It expires after eight hours rather than the thirty-day default, and it is the only cookie the platform sets.

The typefaces on this site are served by Google Fonts, so loading a page here opens a connection to Google and Google sees your IP address and browser. Self-hosting the same families is a change we can make and have not yet.

Changes to this policy

The date at the top of this page is the date it last changed, and it is held in one place in the codebase so the privacy policy and the terms cannot claim different ones.

The register of what we hold is not edited when this policy is edited. It is rendered from the platform's own data register, so it changes on the day a store is added or removed rather than on the day somebody remembers this page.

What is still to be confirmed

This policy was drafted from what the Calliper codebase can prove about itself. That is a good input and it is not the same thing as legal advice. Nobody with legal qualifications has reviewed it, and it should be reviewed before it is relied on, whether for an application to Google or for anything else.