Security & privacy
Private by default.
Your calendar is one of the most sensitive datasets you own. Neos Meet is built so that the least possible amount of it ever reaches us — and so you can check that claim rather than take it on faith.
What we ask for, and why
Three grants, each requested separately, each revocable from your Google account at any time.
Identity only. Signing in to Neos Meet never touches your calendar — connecting a calendar is a separate, explicit step you can skip.
So a booking link can't offer a slot you're already committed to. We request the granular free/busy scope, which cannot return event titles, guests, descriptions, or attachments — that limit is enforced by Google, not just promised by us. (Limit enforced by the provider's API.)
So you can tick which calendars should be checked for conflicts, instead of copying a Calendar ID out of Google's settings and pasting it to us. It returns the list and nothing else: this scope cannot read a single event, and your busy times still come from the free/busy scope above, which Google keeps incapable of returning titles or guests. It is read-only — we cannot add or remove calendars from your list. What it does mean, plainly: we see what your calendars are called. (Limit enforced by the provider's API.)
So a confirmed booking becomes a real calendar invite with a Google Meet link. Google publishes no Calendar scope restricted to the events an app created, so this is the narrowest write scope that lets us book at all — unlike the free/busy line above, this is a limit we keep, not one the API enforces. Our code only ever creates and manages the events Neos Meet books, and never lists or reads your other events. It does not cover calendars merely shared with you. (Limit kept by our code, not enforced by the API.)
So a booking link can't offer a slot you're already committed to, and so a confirmed booking becomes a real Outlook invite with a Teams link. Microsoft publishes nothing narrower that can do both: it has no equivalent of Google's title-blind free/busy scope, and creating an invite needs write access to the whole mailbox, with no scope restricted to the events an app created. So unlike our Google free/busy grant, this is a limit we keep rather than one the API enforces. What our code actually does with it: read the calendars you tick to find the times you're busy, and create, move and cancel the events Neos Meet books. When we read a calendar we ask Microsoft for four fields only — start, end, busy/free status, and whether the event was cancelled — so your titles, guests and notes are never sent to us at all. That is a stronger limit than promising to look away, and it is still ours to keep rather than Microsoft's to enforce: this permission would allow the wider read, and only our own request stops it. (Limit kept by our code, not enforced by the API.)
If this list ever changes
§4 of our covenant says we never widen our access quietly. That is a promise you can hold us to: if we ever need a new permission, we will announce it here — with the reason — before we request it, not after. And Google itself is a backstop: adding a scope forces a fresh consent screen, so no new access can be granted without you approving it in the moment. Below is the full history of what we ask for.
Where your data lives
Bookings and availability are stored in our managed Postgres database; the application runs on managed serverless hosting. Google refresh tokens get a second layer on top of the provider's encryption at rest: they are encrypted in the application with AES-256-GCM before they are written, so a database dump on its own does not yield usable calendar access. Every stored token is covered — verified as of 20 July 2026, with zero plaintext records remaining. Credentials are never sent to the browser and are excluded from data exports. We rely on a small set of sub-processors — Google (calendar and video), Vercel (hosting), Neon (database), Stripe (payments), Resend (transactional email), and PostHog (product analytics). The privacy policy is the authoritative list, and it also covers retention and how to request deletion.
Claims you can check
A security page that only asserts is one you have to trust. Each of these is written so you can try to prove it false. Several are also documented in the data processing annex.
Our Stripe and Resend webhook endpoints verify every request's signature (HMAC, compared timing-safe) before acting, so a forged billing event can't change your plan or suppress your mail. POST an unsigned or tampered body to the webhook route and it returns 400 without touching any data.
Every cron route requires a bearer secret and returns 401 without it — a missing or wrong secret makes the job do nothing, never run open. Call any /api/cron/* path without the Authorization header and you get 401, not a run.
Google refresh tokens are encrypted with AES-256-GCM before they are written, on top of the provider's own at-rest encryption, and are excluded from data exports. A database dump on its own yields no usable calendar access. As of 20 July 2026 zero plaintext token records remained.
Nightly encrypted backups run automatically, and we rehearse restoring them — most recently 21 July 2026. Our recovery targets are RPO ≤ 24 hours and RTO ≤ 2 hours, written down in our restore runbook rather than assumed.
What we don't have yet
If any of these is a hard requirement for your team today, we are not your tool yet — and we'd rather you learn that here than three weeks into a procurement review.
Reporting a vulnerability
The people most likely to catch a security failure are researchers, and §8 of our covenant is only real if they have a front door. If you find something, email support@neos.network — the machine-readable version of this lives at /.well-known/security.txt.
- We will acknowledge your report within two business days and keep you updated as we work it.
- Please give us a reasonable window to fix the issue before disclosing it publicly. We will not go quiet on you.
If you are testing in good faith to find and report a vulnerability, we will not pursue or support legal action against you. Stay within your own account and test data, don't run attacks that degrade the service for other people, and don't access, modify, or keep data that isn't yours. Tell us what you found and give us time to fix it. That's the whole deal.
If we shut down
The strongest continuity guarantee we make is not a backup — it's that you are never building on sand. If we shut down, are acquired and discontinued, or stop maintaining the product, its source code is released to the public under an OSI-approved open source license. This is a binding commitment, written into our terms, and stated in full as §7 of the Neos Covenant. The software you built your work on can outlive us.
Security question we haven't answered here?
Email us and you'll get a straight answer, including "we don't do that yet."
support@neos.network