Privacy policy
Last updated 29 August 2026
Ondago moves a coding-agent session — the conversation and the working tree — off one machine and opens it on another. This document says what we hold while that happens, what we do not hold, and which of those two is a decision we could change.
The short version. Your session is encrypted on your own machine before it reaches us. What our servers store is ciphertext plus a small amount of index information — who owns it, its identifier, its size, when it happened, and an encrypted title. We hold no key that opens any of it.
That is not a policy we are choosing to follow. There is no key on the server to search, preview or summarise your work with, so there is nothing for us to switch on later, nothing to hand over in response to a request for the contents, and nothing an employee could be talked into looking at. The parts of this document that are ordinary — your email address, your IP address, an analytics cookie on the marketing page — are called out below as precisely as we can manage, because burying them under the encryption story would be the dishonest way to write this page.
Contents
1. Who this is
Ondago is operated by [LEGAL ENTITY NAME], of
[REGISTERED ADDRESS] (“we”, “us”). This policy covers the Ondago
command-line tool, the Ondago web application, the macOS application, the hosted service
behind them, and this website at ondago.ai.
For the purposes of data-protection law we are the controller of the data described in this policy. Where your sessions contain personal data belonging to somebody else — a customer name in a support transcript, say — you are the controller of that and we are, at most, a processor holding ciphertext we cannot read on your behalf.
2. Your sessions: what we store
A “session” is one agent conversation together with the state of the code it was working on.
When you lift a session, the Ondago tool on your machine seals it into a single encrypted
bundle before anything is uploaded. The encryption is age — X25519 key agreement
with ChaCha20-Poly1305 — and the recipient is a key belonging to your workspace whose private
half never leaves the devices you have enrolled.
We store that bundle as opaque bytes, and alongside it the minimum index needed to list it for you:
| What | Why it exists | Readable by us |
|---|---|---|
| The encrypted bundle | The thing you asked us to keep | No |
| Bundle identifier | To fetch the right one | Yes |
| Owning account and workspace | To show it to you and nobody else | Yes |
| Size in bytes | Uploads, storage accounting, limits | Yes |
| Created and deleted timestamps | Ordering the list | Yes |
| Title | Shown in your session list | No — stored encrypted |
| Which agent tool it came from | Choosing how to render and resume it | Yes |
| A label for the machine it came from | Telling two sessions apart in a list | Yes |
The last two are worth naming plainly rather than leaving in a table: we can see that an
account lifted a session from a machine called daniels-mbp using Claude Code at
14:02, and we cannot see a single word of what was said or a single line of the code. The
session list you see in your browser is assembled by decrypting those titles locally, in your
own client, after it has fetched them.
3. What we cannot do, and why
Three consequences follow from the section above, and none of them is a promise about our conduct:
- There is no server-side search, preview, summary or analysis of your sessions. Not disabled — absent. Any feature that implied one would be a change to the product's encryption format, not a setting.
- We cannot train anything on your work, and we could not begin to. There is no plaintext to train on.
- If you lose every enrolled device and your workspace recovery passphrase, your sessions are unreadable — including by us. We cannot reset that passphrase. It is used to encrypt a copy of your workspace key, and we store only the result. This is the cost of the paragraphs above and you should treat it as real: keep the passphrase in a password manager.
There is one row of data in this product that nobody can open, including its owner: when a session runs in a cloud container, the copy handed to that container is re-encrypted to a key the container generated for itself and destroyed when it exited. We keep it because deleting it would remove the record that the run happened; nothing can decrypt it.
4. Your account
There are two ways to create an account.
Google sign-in. We request the scopes openid,
email and profile, and nothing else. From the profile Google
returns we store your email address, your name, your Google account identifier, and the URL
of your profile picture. We do not receive or store your Google password, and we have no
access to your Gmail, Drive, calendar, contacts or anything else in your Google account. If
Google tells us an address is unverified, we refuse the sign-in rather than matching it to an
existing account.
Email and password. We store your email address and a
scrypt hash of your password. The hash is a verifier and nothing else: it is
compared against and then discarded, and no key that encrypts anything is derived from your
password. This is why changing your password does not re-encrypt a single byte, and why an
account with no password at all works exactly the same way.
Either way we also store the workspaces you belong to, your role in each, when you joined, and when you last signed in.
5. Technical and security data
To operate the service and to let you answer the question “what can currently reach my account”, we store:
- Sessions. For each signed-in browser: a hash of the session token, the IP address and user-agent string it was created from, and when it was created and last used. You can see and revoke this list in the app under Devices & access.
- Devices. A label, the public half of each device's encryption key, and when it was enrolled and last seen. No table in this product has a column for a private key, and the code that accepts these values refuses one on the way in.
- An audit log. Security-relevant actions — a device enrolled, a key granted, a recovery passphrase set or replaced, an invite accepted, a workspace token created — with who did it, when, and the IP address it came from.
- Sign-in attempts, so that repeated failures against one account can be slowed down.
- Server logs. Each request produces a log line with a trace identifier, the route, the status, and the calling IP. Bodies are not logged; the one deliberate exception is described in section 8.
6. Cloud runs and container logs
When you run a session in the cloud, it executes in a container created for that run and destroyed when it ends. The machine that hosts containers writes, on its own disk:
- Everything the container printed, with timestamps — one plain-text file per run.
- The container runtime's own event trail — created, started, died, exit code, whether the kernel killed it for exceeding its memory limit.
These files are plaintext, and this is the one part of the product where your agent's output is not encrypted at rest. They exist because a run that fails is otherwise undebuggable: an agent that died silently, a container the kernel killed, a credential that did not reach it. They are not served by any route — no API, no browser, no support tool reads them — and are readable only by an operator with access to that host. Nothing currently prunes them; we intend to add retention and will update this section when we do. If this is not acceptable for your work, run the session locally rather than in the cloud: the local path never produces them.
7. Provider keys
To run an agent in the cloud, that agent needs a credential for its model provider — an Anthropic, OpenAI or GitHub key. You can either forward the key already on your own machine for a single run, or store one for a workspace.
A key stored for a workspace is encrypted to your workspace's key before it is sent, exactly as a session is, and we store only the result: we cannot read it. When you start a run, your own client re-encrypts it to the key that run's container generated, and the container is given a scoped credential of ours that is revoked the moment the run ends. We never see the plaintext of your provider key, and we do not use it for anything other than the run you started.
What happens inside your agent is between you and its provider. Prompts and code that your agent sends to Anthropic, OpenAI, GitHub or any other model provider are covered by their terms and privacy policies, not by ours, and we are not in the path.
8. This website
Analytics. The marketing page at ondago.ai loads Google
Analytics 4 (measurement ID G-KVC6F4DW9S) from Google's servers. It sets cookies
in your browser and reports to Google information including your IP address (which Google
truncates), your approximate location, your device and browser, the pages you viewed and how
you arrived. We use it to understand which parts of the page people read. It runs on the
marketing page only — this page does not load it, and the Ondago application does not load
analytics at all. Block it with any content blocker, or with your browser's own controls, and
the page works identically.
Theme. This site stores one value in your browser's local storage — whether you chose the light or dark theme. It is not a cookie, is never sent anywhere, and is read only by the page itself.
The early-access form. If you request early access we collect your name, work
email, company, role, which agents you use, how often, what you do today when you step away,
and how you rate continuing in the cloud. That is emailed to our team and stored in no
database. There is no form vendor and no CRM in the path: the message goes to
team@ondago.ai with a blind copy to members of our team, and the reply address is
set to yours so that answering the email answers you. The address you gave is also written to
the request log so a lead is not lost when sending fails; the rest of your answers are not
logged. Ask us to delete it and we delete the email.
Fonts. The typefaces these pages are set in (Geist Sans and Geist Mono) are
served from ondago.ai along with everything else on the page. Your browser makes
no request to a font host. This used to say the opposite — the fonts came from Google Fonts,
at fonts.googleapis.com and fonts.gstatic.com — and that is no
longer true of any page on this site.
So, in total. This page and the terms page now load nothing at all from anybody but us. The marketing page loads one third-party thing: the analytics script named above.
9. Who else processes data for us
| Who | What for | What they hold |
|---|---|---|
| Cloudflare | Hosting, CDN, object storage, outbound email for the early-access form | Encrypted bundles, request logs, the emails that form sends |
| Sign-in, analytics on the marketing page | Your Google profile as you already gave it to them; analytics events | |
| Our database and container hosts | Running the service | Everything in sections 2, 4, 5 and 6 |
We will keep this table current. We do not sell personal data, and we do not share it with anybody for advertising.
10. How long we keep things
- Sessions you lifted: until you delete them. Deleting one destroys the ciphertext.
- Account data: while your account exists.
- Browser sessions and device rows: until they expire or you revoke them.
- Audit log: retained, because its purpose is answering questions about the past.
- Container logs (section 6): currently not pruned. See that section.
- Early-access emails: in our inbox until we clear it, or sooner on request.
Ondago is early-access software. If we shut the service down we will give you notice and time to collect your sessions, because for anything a cloud run produced, the copy we hold may be the only one.
11. Your rights
Depending on where you live you may have the right to access, correct, export or delete your personal data, to object to or restrict its processing, and to complain to a supervisory authority. Email team@ondago.ai and we will act on it.
Two honest limits on what we can give you. An export of your sessions is an export of ciphertext — the plaintext exists on your devices and not with us, so only you can produce it. And deleting your account deletes the encryption grants held by your devices, which for a workspace whose other members hold none would leave its sessions unreadable; we will say so before we do it rather than after.
12. Security
Everything travels over TLS. Session tokens and API credentials are stored as hashes, never in the clear. Each request carries a trace identifier so that an incident you report can be found in our logs. A container is given a credential scoped to its own run and revoked when it ends, and it never holds your account's key. Access between tenants is enforced twice — once by a guard every route passes through and again by a condition on every database query — because the second one is what holds when somebody forgets the first.
Found something? Email team@ondago.ai. We would rather hear it from you.
13. Children
Ondago is a developer tool and is not directed at children. We do not knowingly collect personal data from anybody under 16.
14. Changes to this policy
We will update this page when the product changes, and change the date at the top. If a change materially reduces the protection described here we will tell account holders by email rather than relying on you noticing a new date.
15. Contact
team@ondago.ai, or [LEGAL ENTITY NAME], [REGISTERED ADDRESS].
See also our terms of service.