Security

What we store

This is the whole list of what we keep about you and your work, enumerated rather than summarized.

• Who you are — your name, email address, and profile photo, as your sign-in provider supplies them.
• What your agents are — their names, configuration, and the soul document that holds each agent’s instructions.
• What your agents did — conversations, scheduled run history, and the tool calls made during a run.
• What your agents read and wrote — knowledge base documents, files you upload, and the dashboards agents build.
• What your published pages collected — form submissions and visitor chat transcripts from pages you chose to publish.
• What happened in your organization — audit records of the actions above.
• Billing state — your subscription status and your usage totals. Not your card.

We do not mirror the services you connect. Nothing is copied out of a mailbox, a drive, or a repository in bulk, and no background job walks your accounts. An agent reads what it needs at the moment it runs, and what persists afterwards is whatever the agent chose to write down in your knowledge base.

We never see your password or your card number

There is no password. Sign-in is delegated to Google, GitHub, Microsoft, or LinkedIn, and email-and-password authentication is switched off in the product rather than merely unadvertised. There is no password field, no reset flow, and no password hash anywhere in our database. There is nothing for us to leak and nothing for us to mishandle.

Card details go to Stripe and never reach us. We store your subscription status and what you have spent. Stripe holds everything else.

How your agents hold credentials to your systems

This is the part of the product that should worry you most, so it gets the most detail.

Credentials are encrypted before they are stored. When you connect an account, the OAuth credential the provider issues is encrypted in the application layer using authenticated symmetric encryption, before it reaches the database. It is decrypted only at the moment a run needs to make a call, and re-encrypted when the provider issues a new one.

The access we ask for is read-only, with two exceptions. Every scope the product requests is a read scope, except two, and both exist because the feature is meaningless without them: LinkedIn is granted permission to post on your behalf, and Notion is granted permission to write notes back. Notion is also the narrowest connection we offer, because it requests no scopes at all: you pick the individual pages the connection can see, page by page, at the moment you grant it.

Disconnecting deletes our copy, and that is precisely as much as it does. Removing a connection deletes the stored credential, which destroys the ciphertext; there is nothing left for us to decrypt or use. It does not call the provider’s revoke endpoint, because no connector in the product calls one. The grant may therefore still exist in the provider’s own account settings, and if you want it gone you should remove it there as well. We would rather tell you that than write “revoked” and let you believe more happened than did.

Who can see your data

Your data belongs to your organization, and membership is what grants access to it. Members hold one of three roles: owner, admin, or member. The audit log is visible to admins only.

We can enter your account for support, under four constraints. Each is enforced in the software, not by policy:

• Only accounts on a list written into the source code can do it. It is not a role that exists in the application, so it cannot be granted to anyone, by us or by an attacker who reaches an admin screen. Adding an account is a code change and a deployment.
• A support session expires one hour after it begins.
• For the entire time we are in your account, a banner sits at the top of your screen saying so, showing the time remaining and a button to end it immediately.
• The administrative tooling that would let us change roles, create accounts, or set passwords is not reachable at all. Exactly two endpoints exist, one to begin a support session and one to end it. Every other administrative endpoint answers as though it were not there.

What happens when an agent calls a model

There is one path out to a model, and it is OpenRouter. No other model provider is called directly from anywhere in the product, which is why the answer to “who saw my prompt” has a bounded shape at all.

Every request we build carries a routing constraint that excludes any endpoint that trains on prompts. There are exactly two places in the code that construct a model request, and both set it, so this covers every model call the product makes, including research and voice.

That constraint governs training, not retention, and we will not blur the two. It says no endpoint that trains on prompts may serve your request. It does not say that no endpoint retains anything: some hold a request briefly for abuse monitoring, and we cannot verify deletion on someone else’s infrastructure, so we do not claim it. This is not a zero-retention arrangement and we do not describe it as one. Which providers sit behind that router is on the Subprocessors page.

We don’t train on your data

We do not train models on your data, and we do not use it to improve the product. Not your conversations, not your documents, not your agent configurations. We do not sell it, and we do not hand it to anyone else for their own purposes.

There is one thing that does leave the front end, and it is worth naming rather than burying: the app loads Google Analytics. The page addresses it receives include identifiers for the agent or document you were viewing. It does not receive message content, document contents, uploaded files, or credentials. This marketing website carries Google Analytics and a LinkedIn advertising tag; the application itself carries neither of the latter.

Beyond that, the application runs no product telemetry, no session recording, and no third-party error reporting service. When something breaks, the error is written to our own database.

Everything your agents do in your organization is written down

The audit log records 51 distinct kinds of action, including every tool call an agent makes, with its arguments recorded in truncated form. Agent creation and deletion, permission grants and denials, scheduled runs and the ones that were missed, document sharing, connected-app activity, run failures, and billing events all land in the same log.

Organization admins can filter it and export it as CSV, up to 10,000 rows per export.

The 90 days you see by default is a view, not a retention limit. Nothing in the product deletes an audit row, and you can query further back than the default window.

Nothing is shared until you share it

Documents and dashboards are private to your organization until you publish one. Publishing produces a link, and anyone holding that link can open the page without signing in, which is the entire point of it.

Unsharing does two things: it retires the link, and it deletes the published copy. The old address stops resolving, so future access really does stop rather than merely becoming undiscoverable.

What it cannot do is recall a copy someone already downloaded. That is true of every link ever shared, and we mention it because a promise that ignored it would be worthless.

Getting your data out

An organization’s admins can export the organization on demand, as a single machine-readable file, downloaded directly. There is no ticket to file and no waiting on us.

Individually, you can export your own account at any time: your name, your email address, and the soul document of each of your personal agents.

Reporting a problem

If you find a security problem, contact us and say that is what it is. Tell us what you found and how to reproduce it, and we will tell you what we are doing about it.

We answer security questionnaires in writing. If your own review process needs something this page does not cover, ask us directly rather than assuming the answer.