Privacy Policy

Last updated 25 August 2026

Airy Digital gives life to digital beings that act on your behalf, using only the capabilities you grant them. This page explains what those beings can reach in your accounts, how your sign-in is handled, and how your credentials are stored.

This service is operated by Airy Digital Inc., 325 Front Street West, 4th Floor, Toronto. A being is assembled from components we call organs. Each organ provides one kind of capability — email, calendar, or workspace documents — and requests only the access that capability needs.

What a being asks for in your Google account

When you set up a capability, the organ behind it requests specific Google scopes. You grant only the organs you choose to set up; an organ you never set up asks for nothing.

• Email requests gmail.modify.
• Calendar requests calendar.
• Workspace requests drive, documents, spreadsheets and presentations.

Two further scopes, cloud-platform and cloudkms, are also used. These are Airy's own infrastructure scopes, used to perform the encryption described below. They are not access to your data.

When a being reaches your data

Email and Workspace act on demand: the organ behind them reaches your account only when your being is doing something that needs it. Calendar does not work this way. The calendar organ runs on a fleet loop that fires roughly every 20 seconds — on the order of 4,000 times a day — and on each pass it decrypts the stored credential of every provisioned being and calls Google. Your calendar is therefore read continuously, whether or not your being is doing anything on your behalf at that moment.

How signing in works

The web front end never receives or holds a Google token. It relays an authorization code only. The organ exchanges that code at Google using its own client secret, which the front end does not have.

How your credentials are stored

At rest, your refresh token is stored encrypted, inside an envelope encrypted under a Google Cloud KMS key, in object storage scoped to the individual being. There is a per-being key ring for each provisioned being, but that structure gives you no isolation today: all twelve key rings carry the identical set of organs, so no being's credentials are walled off from any other's.

Access to those encrypted credentials is scoped by organ, not by individual being. Six identities hold decrypt on a shared master key covering every being: the organ service accounts, and — in addition — the vault's own encrypter-decrypter role, which subsumes decrypt. Any of them can open any credential in its reach, not only one user's. You can revoke that credential at Google at any time, which makes every stored copy of it inert.

How your data is shared

Your data is not sold. It is not shared with third parties other than Google, whose APIs the organs call on your behalf.

Logging and retention

The organs themselves hold the line on user content in what they log. No subject lines, no message bodies, no file names, no event titles and no attendee lists appear in an organ's logs. We verified this across the full 30-day log vocabulary. This is not the same as no personal data: some does reach organ logs. Third-party email addresses appear inside raw calendar event IDs, and the acting mailbox address is logged.

Credentials have also reached the logs, and the picture now differs by sign-in path. On the organ sign-in relay, authorization codes no longer appear in the logs at all: the consent response comes back as a POST body, so there is no query string to log — we confirmed this with a positive control. Human sign-in callbacks, however, still log authorization codes in full, because their state cookie cannot survive a cross-site POST. Those codes carry identity scope only: they do not grant access to mail, calendar or drive.

The sign-in front end previously logged Google's response bodies — carrying real names, email addresses and account identifiers — across several code paths. That logging is now closed, verified against the deployed artifact: the format strings that emitted those bodies are present in the binary that was serving before and absent from the one serving now, so they can no longer be written.

A separate internal component does not hold that line. Each being keeps its own working record — its own account of what it did — and writes 400 to 800 characters of prose per line, paraphrasing what the being read and did. That prose includes real names and the substance of conversations, and it is not redacted.

Both of these — the user data a being handled and the being's own working record — sit in a log that is retained for 30 days, unredacted.

Revoking access

You can withdraw a being's access at any time from your Google Account, under Security → Third-party access. Removing Airy Digital there revokes the tokens the organs hold for you.

Deleting your data

To ask us to delete the credentials and data we hold for you, email privacy@airy.digital.