TabTunnel lets an AI assistant drive a browser you are signed into. That is an unusual amount of access, so this page is specific about where the data goes rather than reassuring about it. Everything below describes what the service does today.
Last updated 6 September 2026
When you sign up we store your email address, your name if you give one, the date you joined, and the timezone you choose for showing timestamps — UTC until you set one, never detected, and deleted with the account like everything else here. Passwords are stored as an Argon2id hash, never in a form we can read.
We also store whether you want news and updates by email, and the date you said yes. Signing up turns it on, and we say so in the email we send you when you join. Your preferences page turns it back off, and so does the link in that email — you do not have to sign in to use it. Turning it off does not stop the email we have to send you about your own account — an invitation, a password reset, or a warning about a browser you connected.
If you sign in with Google instead, we receive and store the permanent id Google uses for you, plus the email address, display name, profile picture URL and Workspace domain from your Google profile. If you sign in with GitHub, we receive and store GitHub's permanent numeric account id, plus your username, display name, avatar URL and the primary verified email address on that account; the access token GitHub gives us is used for those two reads and then discarded, never stored. Either way we match you on the identifier, never on the email address — addresses get reassigned, and treating one as proof of identity would let whoever inherits it inherit your account too.
An organization stores its name, its policy settings, the plan limits we set for it, and its list of members with their roles. Where somebody was added automatically — because they signed in with an address on a domain the organization had registered — it also stores whether an owner or admin has approved them yet. When someone is invited we store the address the invitation was sent to, and we keep that record after the invitation is accepted or expires — it is how an organization can show who invited whom. Withdrawing an invitation deletes it. The invitation link itself is stored only as a hash, so the link in the email cannot be recovered from our database, and resending an invitation issues a new link and retires the old one.
An organization can register the email domain its people use. For each one we store the domain itself, the verification code we asked the organization to publish in its DNS — which is public by design rather than a secret, so we store it as it is — when we last looked that record up, and whether we found it. When you sign in with Google or GitHub, the address your provider has verified is checked against these domains to decide whether to add your account to the organization that holds yours, and whether you may still enrol a browser into your own personal organization. A password sign-in is never checked this way. Releasing a domain deletes the record.
An organization can also bring its own sign-in provider — its Okta, its Entra, or any other OpenID Connect server — so that its people sign in with the account their employer already gives them. For each one we store the name it is shown under, the four addresses it is reached at, the client id we are registered under, and the client secret it issued us, which is encrypted before it is written down and is never shown again to anybody, including the owner who entered it. Only an owner of the organization can add, change or remove one. When you sign in that way we receive and store the permanent id that provider uses for you, plus the display name, profile picture URL and verified email address it tells us — the same things Google’s sign-in stores, and matched the same way, on that id and never on the address. We also add you to that organization as a member awaiting approval. Two organizations’ providers can call two different people by the same identifier without either becoming the other. Removing a provider deletes it and the sign-in links made through it; the accounts and memberships themselves stay.
An owner or admin can see how much of the organization’s plan is in use — how many browsers, shared machines, members, outstanding invitations and CDP browsers it has in total — and, on the organization’s browsers page, which browsers those are: each machine’s name, its owner’s email address, whether it is a personal or a shared machine, whether it is connected, whether CDP is switched on for it and, if it is, which owner or admin switched it on and when. That list is what managing seats needs, and it is all that list shows: not a machine’s hostname, platform or Chrome version, not its tags, not when it last checked in, and nothing about what is open in it.
An owner or admin can also open a machine they do not own and rename it, tag it, pause it, retire it, and switch CDP or tab closing on and off for it, because those decide what occupies a seat and a paid slot. On that page they additionally see whether its owner has paused it, which is there so that the pause control says what it will do. That is the whole of what administering somebody else’s machine means here, and each of those acts either restricts who may use the machine or restores what its owner had withheld. None of them is a way to use it. An owner or admin who has not been granted your browser still cannot drive it, cannot open a DevTools session on it, cannot see what is open in it, cannot read the sites it has asked you about, cannot share it with anybody, and cannot re-enrol it. They see its command history and its sharing history only where they could already — for a shared machine the organization owns, never for your own. We do not notify you when somebody does one of these things to your machine; you will see that it was renamed, or that your agents have stopped, the next time you look.
Every member of the organization, whatever their role, can see how many of the CDP browsers it pays for are in use — a count, never a list — so that being told there is no room to switch CDP on for another one makes sense. The limits themselves are set by us, not by the organization, and lowering one never takes away anything that already exists.
For each browser you connect we store the name you gave it, its platform, OS version, Chrome version and extension version, and the public half of a device key. We store the time it last checked in. If you pause a browser we store that it is paused, when, and who paused it — that record is cleared when you resume it.
We also store any tags you put on a browser
— short labels of your own, such as location:us, that let an agent ask for a machine
by attribute rather than by name. They are free text and we do not interpret them.
Tags are not private: anybody you have shared that browser with sees
them, and so does any agent acting for them, exactly as they see the name you gave it. Do not put
anything in a tag that you would not put in the name.
The private half of that device key is generated inside your browser, marked non-extractable, and never leaves it. We could not obtain it if we were asked for it.
We hold a current snapshot — not a history — of how many tabs an agent has open on the browser and up to five hostnames from those tabs. It covers only tabs the agent itself opened; your own tabs are not counted and not named. Sites on your denylist are stripped from it even so, and you can switch the whole field off in the extension's options. Each check-in overwrites the previous snapshot, but the last one is not currently erased when a browser is cut off, when a browser is deleted, or when an account is deleted — and since a browser that has been cut off never checks in again, that last snapshot stays indefinitely. Switching the field off in the extension's options is what stops it being recorded at all.
Once you have cut a browser off you can delete it outright, from the same list. That removes its record here, its sign-in sessions, the record of who was given that machine, and the consent decisions recorded against it. What was run on it stays in your command history — see below.
An MCP application can ask for access by sending you here to sign in and approve it, instead of you pasting a token into its settings. Before it can do that it registers itself with us, and we store what it tells us: the name it calls itself and the addresses it may be sent back to. That registration is not tied to your account or to anyone’s — it is made before any person is involved — so it names nobody, and it is kept indefinitely. There is no page yet for reviewing or removing past registrations.
We do not verify that name. Anyone can register an application and call it anything, which is why the approval page says so and why you should approve only something you started yourself. Approving one creates an ordinary MCP token in your own list, named after the application, and you can see it there and stop it like any other. Nothing is created until you approve.
This is the part worth reading twice. Connections use HTTPS, but this is not end-to-end encryption: our servers decrypt what passes through them, because relaying a command to your browser is what the service does.
Page text, accessibility trees, console lines, network entries and screenshots travel through our servers in memory and are handed back to the agent. Screenshots are decoded, downscaled and re-encoded in memory on the way through. None of it is written to a database or to disk. Response bodies an agent asks for are capped at 256 KB and discarded once returned, and request headers are never collected at all.
What we do keep is one entry per command, recording who ran it, with which token, on which browser and under what authority, the name of the tool, how long it took and whether it succeeded. That entry carries a full web address only for the two tools that take one — opening a tab, and navigating one. For every other tool that field is empty.
One more thing is in that entry, and it is about us rather than about you. Sometimes we send a command, lose the answer, and cannot tell whether your browser carried it out — a dropped connection, or one of our own servers going away mid-request. We send it again rather than failing it, and the entry says so whenever we can tell. A command marked that way may have happened more than once; an unmarked one is not a guarantee that it happened once, because there are cases we cannot distinguish.
Arguments are recorded through a per-tool allowlist rather than a list of
things to strip, so a tool nobody has classified records nothing. Text you type, keys you press, scripts
you evaluate and search queries are recorded only as a length. Anything typed into a password or
one-time-code field is replaced with «redacted»
inside your browser, before it is sent to us at all. Password fields are left out of the page an agent
reads as well, so a value your password manager filled in is not readable by an agent either.
There is no organization-wide activity feed, and its absence is deliberate. An administrator can see their own commands, everything done on machines they own, and activity on the organization's shared service browsers. They cannot see what is open in a colleague's browser, and being an owner or an admin does not grant use of anybody's machine — access to a browser is granted per browser, never inherited from a role.
One thing that does leave the service: when an agent lists the browsers it can reach, each entry carries the owner's name and email address, so that a person driving a shared machine knows whose it is.
When you answer a permission prompt with Allow always or Deny, that answer is remembered against the site's domain and mirrored to us so it can be shown on your dashboard. Only the browser's owner sees it there, and nobody else in your organization can reach it, whatever their role. Allow once, a dismissal and a timeout are not recorded anywhere. While a prompt is open, the message telling our servers to hold the command carries no domain at all.
Three, all our own, none for advertising or analytics: a session cookie that keeps you signed in for two weeks, a CSRF token that protects forms against other sites, and a short-lived cookie carrying one-off notices such as “invitation sent”. There are no third-party cookies, because there is no third-party content on this site. The session cookie is normally set when you sign in; it is also set on the first page you reach from a Google ad, because that is where the click identifier is kept until you sign up or sign in.
We count failed sign-ins and other credential attempts per address, to make password guessing expensive. That counter does not hold the address: what it holds is a keyed hash, so the table cannot be read back as a record of who connected from where, or checked against a guess.
Our server logs are the exception, and we would rather say so than imply otherwise. Every request writes one line, and that line carries the address the request came from, the method, the path, the response code, the size and how long it took. It carries no query string, no cookie, no request body and no account name — though the path can name the organization you were looking at. Where a link carries a one-time secret, such as a password reset or an invitation, the line records that the request happened and not the secret itself. The logs exist to diagnose an outage and to trace abuse. Deleting your account does not reach them; they are kept for 14 days and then discarded.
You can delete your account yourself, from your account settings. Doing so removes your profile, your personal organization, the browsers you enrolled, their sessions and consent decisions, your MCP tokens, every grant of access you were given, and every grant on your own machines. Browsers you enrolled stop working immediately. A grant you made on one of the organization's shared machines stays — it is somebody else's access to a machine that is not yours, and taking it away would penalise them for your leaving — but it stops recording you as the person who gave it.
Two things survive on purpose. Your command history and the record of sharing changes stay until their retention period ends, no longer naming an account that exists — an audit log that can be emptied by deleting the account that filled it is not an audit log. The click identifier from a Google ad goes with the account; a conversion record already written stays until its 90 days are up, no longer naming you. Where the deletion also removes an organization, its retention setting goes with it, and what is left of its command history is kept for 90 days rather than whatever that organization had chosen. And if you are the last owner of an organization with other people in it, we ask you to hand ownership over or remove the organization first, so nobody is left in one that nobody can administer.
Very few parties, because very little is wired up:
There is no analytics provider, no error-reporting service and no CDN. We do not sell data. The only advertising network we share anything with is Google Ads, only as described above, and only about our own advertising — never to help anybody else target you.
Your sign-in credential for the browser, which browser it is enrolled as, your consent decisions and denylist, and short-lived working state. The device key lives in the browser's own database and cannot be exported. Signing out erases the credentials. The extension asks for no host permissions at all, and holds no MCP token.
Email hello@tabtunnel.dev for a copy of what we hold, a correction, or anything on this page that is not clear. If we change this policy in a way that affects what we collect, we will say so here and date the change.