Privacy

What this covers

This describes what Force Labs collects, what an agent reads on your behalf, what is stored and what is not, and who else your data reaches. It covers the product at the address you are reading it on. It does not cover the sites your agent visits, which have their own.

The short version: the product reads your mail only if you grant it, read-only, and tells you on the screen what it read. It stores what an agent did so you can check it. It stores no card, and no password in anything readable. And it cannot yet delete everything on request, which is said again below in the place where you would look for it.

What we collect because you gave it to us

Your email address

To make an account and to sign you in. Through Google, or an address and a password you set.

What you type

The description of the job you want done, and the conversation that turns it into an agent.

A phone number, if you give one

Only to send an agent's questions and answers to your phone, and only after that number has proved itself by texting a code in.

An email address on the waitlist

To tell you when something opens. Nothing else, and never anybody else's queue position.

What an agent reads, and why

Nothing is read until you connect the account it belongs to. The list below is generated from the same list the authorisation request sends, so this page cannot describe a narrower grant than the one you actually give. It once said two permissions while the code asked for seven; that is the mistake this is built not to repeat.

Signing in lets Force know who you are and nothing else. It cannot read your mail, your calendar or your files with this. Where an agent needs to read a mailbox, that is a separate connection you make on its own card, and anything that would change something outside this product stops and asks you first.

It can know who you are

It is only how the account is identified. It reads nothing. Without it, we cannot sign you in. The scope is openid, which Google classes as basic.

It can know which address this is

Your address, so two mailboxes are not mistaken for each other. Without it, we cannot tell your mailboxes apart. The scope is https://www.googleapis.com/auth/userinfo.email, which Google classes as basic.

None of them can change anything, and none of them can read anything. Signing in with Google tells us who you are and which address you use, and that is the end of what that permission does. This list used to carry four more — reading your mail, sending as you, reading your Drive, writing to your calendar — and two of those four were never used by any feature at all. They are not asked for any more.

Reading a mailbox is a separate decision, made separately, and it goes through Composio: see who else sees it, below. The name on Google's screen when you connect a mailbox is Composio's, not ours, because the application Google has verified is theirs. Google will ask for access to the whole mailbox at that point, which is Composio's grant rather than a narrower one we chose, and that is worth knowing before you press it.

Leaving a box unticked is allowed. The token response says which permissions actually came back and that is the only statement believed; the product says exactly which one is missing and offers one button to ask again for the gap.

A website you sign in to

So an agent can do the job on the site where the job lives. The sign-in is typed into that one site and nowhere else.

A public page

No account, no sign-in. Most of what an agent reads is this.

Reading can never write. While an agent is reading a page it cannot change anything on it, and the rule is lifted in exactly two narrow places: inside a sign-in, for the site being signed in to, and inside an action you approved, for the site, the action and the amount you approved. The Security page explains how that is enforced and where it stops.

Limited Use

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

• The data is not used for advertising, and no advertising is served anywhere in this product.
• It is not sold, and it is not shared with anybody for their own purposes.
• It is not used to train generalised models. Model requests are made with data collection denied and zero-data-retention endpoints required where the gateway supports it.
• It is not transferred to anybody except as needed to provide the features you asked for, meaning the four processors named below, to comply with the law, or as part of a merger or acquisition with notice.
• No human reads it except where you ask us to look at something, or where the law requires it.

What is stored

Your agents

What each is for, what it may do, every published version, and the conversation that produced it. Versions cannot be edited or deleted, because the database refuses, so a run can always name the definition that produced it.

Your runs

What was asked for, every model and tool call with its input and output, the pages observed, stored screenshots, and what it cost.

Connected accounts

An encrypted token where a service issued one. For an ordinary website, an encrypted username and password, in a table whose only reader is the step that types it into the one origin it belongs to.

Sessions

A browser, a time and the address it came from, per signed-in device, so you can sign a lost device out.

An activity log

Role changes, connections, device sign-outs and exports, with who did them. It is append-only in the database, not by convention: the table refuses updates and deletes, so not even an Owner can edit it.

For how long

This section said there was no retention schedule, because there was not one, and a period written here that nothing enforced would have been the easiest and worst lie in this document. There is one now, and a scheduled job enforces it. What follows is what that job does.

Deleting a workspace, or an account, starts a thirty day grace period. Everything is hidden immediately, so the person who asked gets what they asked for. Nothing is erased until the thirty days are up, so somebody who pressed it by mistake can restore it themselves for a month without anybody restoring a backup.

After thirty days a scheduled job erases it: the conversations, what was read, what was learned, the agents, their runs and their versions, the mailboxes and the connections. That is permanent and we cannot undo it for you.

Disconnecting a mailbox or an app is different and has no grace period at all. What was read from it is deleted immediately. Somebody revoking access is not asking us to keep a copy for a month.

The audit log is kept for one year, whatever else goes, including after a workspace is erased. It is the record of what was done in your name: what an agent sent, what you approved, and what was refused. A company asking afterwards what was sent on its behalf is owed an answer, and that answer has to outlive the thing it was about.

Only an owner can start a deletion, and only by typing the workspace's name. The owner is emailed when it starts and again when it completes.

What is never stored

• A card number. Not encrypted, not truncated, not briefly. There is no payment processor in this product and no card is held anywhere in it.
• A password in anything readable. A stored site password is encrypted with a key that lives in the environment and never in the database, and it is never selected into a model prompt, a trace, a log or a run's context.
• A password in a conversation. The model is given a placeholder. The real value is typed into the site by the step that decrypts it, and nowhere else.
• A one-time code beyond its use. A texted code is asked for when the site sends one, used, and not kept.
• Anything from a mailbox, sender or label you rule out, once that is enforced. Today the list is stored and nothing reads it, which the screen says before you fill it in.

Who processes it for us

Five. The browser is Kernel's, the models are OpenAI's, the texting is Photon's, signing in is Google's, and a connected mailbox goes through Composio. What reaches each of them is below, because that is the part that matters and it is the part most policies leave out.

OpenAI

The model that reads, plans and drafts. Reaches them: The text of what you asked for, the agent's definition, and the contents of the pages and messages it is working on at the time. That includes the text of mail it has been given read access to. Does not reach them: A stored password or an API key. The model is handed a placeholder; the real value is decrypted by the step that types it into one site and is never selected into a prompt, a trace or a log.

Kernel

The hosted browser the agent works in. Reaches them: Every page the agent opens, and anything it types into one, including a site password at the moment it is typed. Sessions are created fresh for a run and deleted at the end of it. Does not reach them: Your mailbox. Mail is read through Google's API, not through the browser. No account profile is shared between workspaces or silently kept.

Google

Signing in. Nothing else. Reaches them: Your email address and the fact that you signed in. That is the whole of it: Force's own Google client asks for `openid` and your address, and for nothing that can read or change anything in your account. Does not reach them: Your mailbox, your calendar or your files. It once asked for all three and never used two of them, and it no longer asks for any. An agent that reads a mailbox connects separately, through Composio, which is the next entry and a decision worth reading.

Composio

The connection to Gmail, where an agent reads mail. Reaches them: Your mail, when you connect a mailbox. Composio holds the access token and the messages pass through them on the way to the agent. Said plainly because it is the part that matters: there is one more company between you and your mail than there would be if we ran this ourselves. Does not reach them: Anything until you connect a mailbox, and nothing at all if you never do. Connecting is a Google screen you press through yourself, and the name on that screen is Composio's rather than ours, because the application Google has verified is theirs. Taking it away is at myaccount.google.com/permissions, under Composio.

Photon

Messages out to a phone, where you set that up. Reaches them: The text of a message an agent sends you, and the number you proved. Nothing is sent to a number that has not proved itself by texting a code in first. Does not reach them: Anything, until you have set up a number. No channel is configured by default.

Model requests are made with data collection denied and zero-data-retention endpoints required where the gateway supports it. That is a setting on our side; it is not an audit of theirs.

Not built yetThere is no signed data processing agreement with any of the four on file, and no sub-processor change notice to subscribe to. For a company that needs those before it can use a product, the honest answer today is that they do not exist yet.

Who inside your company can see it

Everything is scoped to a workspace, and every page and route checks the role on the server before reading anything. A hidden button is a courtesy; the check behind it is the thing that stops the action.

Owner

Everything, including billing, members and deletion.

Editor

Build, run and connect. Not billing, not members.

Viewer

Read. Starts nothing.

One exception runs the other way. An Owner cannot see anybody else's signed-in devices or the addresses they connected from. Reading a colleague's IP addresses is surveillance, and being an Owner is not a reason for it.

Deleting your data, and taking access away

Two different things, and you can do either without asking us. Taking access away stops an agent reading anything new. Deleting removes what was already read.

Three removals work today, and they work immediately.

• Take access away at Google, at myaccount.google.com/permissions. There may be two entries and they are different things: Force Labs is the sign-in, and Composio is a mailbox you connected. Removing either takes effect at once, whatever this product does, and neither depends on us. Microsoft is the same at myapps.microsoft.com, under the account's own permissions.
• Remove a connected account from the Accounts page. An encrypted token is deleted; a site sign-in is detached from the browser profile that held it.
• Sign out everywhere, from the Security page. Every other session ends at once and the browser you are in is left alone.

Not built yetDeleting your account and all of its data on request is not built. Doing it properly means removing runs, steps, files, tokens and the rows the sign-in library owns, in an order that strands no reference, and getting it wrong leaves somebody half deleted. The button on the Security page records a dated request and says, in those words, that nothing has been removed. It does not pretend otherwise, and neither does this page.

Until that is built, a removal request reaches a person and is done by hand. That is slower and it is not a promise of a timescale, because no timescale has been committed to.

Children, and where this runs

This is a product for businesses and it is not for anybody under 18. No account is knowingly made for a child.

Not built yetWhere the data physically sits depends on where this installation is deployed and on where the four processors run, and no region commitment has been made. A company that needs data kept in a particular region should ask before connecting anything, because the answer today is that it has not been decided.

What this page is not

It is not a compliance statement. There is no SOC 2 report, no penetration test, no audit by anybody outside this project, and no data processing agreement. The controls described here are real and the assurance around them is not yet. Both of those are worth knowing before you connect a mailbox.

Also

• Terms of use
• Security: what stops an agent, and where it stops
• What is not live yet, the product’s own list

Last written 18 October 2026.