Draft — last updated 7 October 2026
Inline is operated by Agentic Users, a business of 1001538151 Ontario Inc. (Ontario, Canada). Questions, corrections and requests about your data: contact@agentic-users.com. There is no self-service control for some of what is described below (erasing a single person, for example); those requests are handled by hand, by email.
Retention below is what is configured on the running service today. Where a record expires, Firestore deletes it on its own schedule, usually within a day of the date shown. Copies in backups are covered under deletion.
| What | How long |
|---|---|
| Your sign-in. Your address, name and photo; how you signed in (Google, email link, or your organisation’s single sign-on), whether a second factor was used, and when. If you turn on an authenticator app, its secret is held by Google’s Identity Platform. | Until the record is erased. Closing a workspace does not erase it, because one sign-in serves every workspace you belong to. |
| Workspace structure. Who belongs, their roles, groups, single sign-on registrations, claimed domains, and the workspace’s sources, servers, rules, playbooks and settings. Folder paths from your own machine if you use folder routing. | While the workspace exists. |
| Credentials for the services you connect (OAuth tokens and client secrets), agent keys, your own model-provider key, notification webhook addresses and the secrets of rule webhooks. | Until you disconnect, revoke or delete them, or the workspace is erased. Sign-in codes last minutes; refresh tokens 90 days. |
| REST API keys: the one you register, and the keys people in your workspace add for themselves for an API that asks each person for one. They are sealed with your workspace’s key, exactly like the credentials for services you connect, and stored in your workspace. A workspace manager can remove a person’s key but cannot read it. See below. | Until you delete the API, the person is removed or removes their key, or the workspace is erased. Backups and point-in-time recovery keep a copy for the periods under “Backups” below. |
| The activity record of every call. Who (their address), which key, which server, source and tool, when, how long, how it ended, and the arguments: with values that look like credentials removed, capped at 8 KB, plus a fingerprint (SHA-256) of the whole. Searches record what the agent asked for and which tools it was shown. Of the result, only its size and fingerprint are kept — unless a source has been set to keep responses, in which case a redacted copy capped at 16 KB is kept as well. A source can also be set to keep no arguments. | 365 days from each record. |
| The record of administrative changes. Who changed which person, source, server, key or rule, and the details. | 365 days from each record. A few older rows written before expiry dates existed have none. |
| Saved tools. The source code of every tool you save, and its earlier versions. | No expiry. Deleting a tool in the product removes the tool and its earlier versions. Deleting a server removes the tools saved on it, with theirs (a server deleted before 13 October 2026 may have left its tools behind until they are cleaned up). |
| Script run records. Every script an agent runs is kept: the full source as written (not redacted, so anything the script contains is kept), who ran it, the names of the tools it called, timing and outcome, and any error text. | No expiry. They stay after you delete the tool, until the workspace is erased. |
| Calls held for approval. The call’s arguments (sealed), who asked, who decided. | 30 days after the decision or lapse. A hold not decided in 24 hours is not run. |
| Large results. A result too large to return directly is stored so it can be read in pieces, in a private bucket, readable only by the person and key that produced it. | Deleted after one day, then held in Google’s seven-day soft-delete, so up to about eight days in total. |
| State a script saves between runs. | One hour after the last save. |
| Counters that enforce limits and budgets: calls per day and month, model tokens, spend on an organisation model key. | Between minutes and 40 days for daily figures; about 400 days for monthly ones. |
| Billing. The billing account (owner, billing email, Stripe customer id, plan history), the subscription, and, where a plan bills for use above its allowance, one row per billable call (address, tool reference, time). | The account and subscription: kept, on purpose, after the workspace is erased. Per-call rows: about 400 days. |
| Marketplace records if you publish: publisher identity, listings and their versions. | Kept, on purpose, after the workspace is erased, because other workspaces’ installs depend on them. |
| Logs kept by Google Cloud. Each call record and admin record is also printed to the service’s log, so it contains the same fields. Cloud Run also logs each request, including the network address it came from. Individual entries cannot be deleted. | 30 days in the default log bucket. Admin-change lines and Google Cloud audit logs about who and what touched our storage and keys (names of resources, not content) are also copied to a separate log bucket for 18 months. |
The application itself does not store your network address, and sets no advertising or analytics cookies. It sets one cookie to remember which workspace you chose, and one short-lived cookie while you connect a service. Your browser keeps your sign-in session in its own storage, as the sign-in library requires. Our own pages load fonts from Google Fonts and, on the sign-in page, scripts from Google’s servers, so Google sees your address and browser when they do.
Everything stored on Google Cloud is encrypted at rest by Google with its own keys. That is the baseline, and for most of what we hold it is all there is.
These values are sealed field by field before they are written: AES-256-GCM with a fresh key for each value, that key wrapped by Google Cloud KMS. Each sealed value is bound to the workspace it belongs to, the record it lives in, and the key that wrapped it, so a value copied into another record or another workspace will not open.
By default, workspaces share one key for their sealed credentials. A plan that includes a key of its own gives the workspace a key made for it alone. Destroying that key makes the sealed credentials and secrets under it unrecoverable after a 30-day window in which the destruction can still be undone. That covers only the sealed values listed above, and only from the moment the move to the workspace’s own key has finished: copies in backups made before then are under the shared key and age out on the schedule under “Backups” below, and point-in-time recovery keeps earlier versions for 7 days. A workspace’s own key is not rotated automatically and holds one version; the shared keys rotate every 90 days. Before a workspace returns to the shared key we tell its owners, in the app and by email, at least seven days ahead.
In transit, the service is reached only over HTTPS.
Inline works because our servers open your stored credentials at the moment of a call and use them on your behalf. So the service can obtain them, and so can anyone who administers it with the right permissions on the Google Cloud project. Encryption at rest protects against a stolen or copied database. It is not a promise that we cannot read your credentials.
Nobody at Inline reads workspace data as a matter of routine. There is no technical control that stops them. Access to the production project is held by one person at Agentic Users, plus the service accounts the service runs as. We cannot yet produce a report of who has access to what.
Workspaces are separated in software, not in infrastructure. Self-serve workspaces share one database, divided by a per-workspace path that our own code enforces, and every workspace is served by the same service account. A mistake in that code could expose one workspace to another.
Inside a workspace: owners, admins and auditors can read its whole activity record. Everybody else can read only their own calls.
The results of your tool calls pass through our servers on the way to the AI assistant that asked for them. Apart from the cases in the table above, we do not keep them. What that assistant and its vendor then do with them is governed by your arrangement with them and is outside our control.
These are the companies that process data for us. Hosting is in Google Cloud region us-west1 (Oregon, United States) for the databases, the results bucket and the encryption keys. Secret Manager and the default log bucket are managed by Google and are not pinned to a region by us.
| Who | What it does, and what it receives |
|---|---|
| Google Cloud | Hosts and runs the service: Cloud Run, Firestore, Cloud Storage, Cloud KMS, Secret Manager, Cloud Logging, Cloud Monitoring and Cloud Scheduler. It holds everything in the first table on this page, including your stored credentials in their sealed form. |
| Google Identity Platform (Firebase Authentication) | Signs you in. It holds your address, name, photo, the sign-in methods linked to your account and any authenticator-app secret, and sends the one-time sign-in link to your inbox. It does not hold a password: none is set. |
| Google Firebase Hosting | Serves the marketing website (useinline.dev), which keeps ordinary request logs. The application itself is served from Cloud Run. |
| SendGrid (Twilio) | Delivers the email we send. It receives the recipient’s address and the message: the welcome email, the notice that a workspace is leaving a plan with a key of its own, and notices that a call is waiting for approval, has been waiting, or lapsed, which name the tool, who asked, the server and the rule but never the call’s arguments. Whether SendGrid adds open or click tracking is a setting on our SendGrid account, not something in our own code to confirm: SendGrid tracking settings. |
| Stripe | Takes payment and manages subscriptions. It receives your billing email, a workspace and account identifier as metadata, subscription state, and usage totals where a plan bills for extra use. Card details go from your browser to Stripe and do not touch our servers. Paid plans are charged to the card you give at checkout, through Stripe’s live service. |
| OpenRouter, and the model vendors it routes to — only if you set this up | If a person saves an OpenRouter key, or an admin adds an organisation key, and model calls are then switched on, the prompts a script or the app preview builds are sent to OpenRouter under that key. OpenRouter routes each request to whichever vendor serves the model you chose, and that vendor processes it too. Details below. |
| PostHog — website only | Counts visits to useinline.dev, and only if you agree. It is not in the application. See the website privacy page. |
| Every service you connect | Each MCP server and REST API a workspace connects receives every call that is made to it, including the arguments the agent chose and the credential we apply. Its own terms and privacy policy govern what it does next. That includes services other people in your workspace connected. |
| Addresses you configure | A notification webhook (for example a chat room) receives a short notice that a call is waiting, who can decide it, and a link. It does not name the tool or the caller, and carries no arguments. A rule that asks a webhook to decide sends that address the call’s arguments, with credential-looking values replaced. |
| Your AI assistant and its vendor | Receives the results of the tools it calls. We do not choose it and are not its processor. |
It can, but only in these cases, and never because of something we switched on for you.
About onward routing: OpenRouter is a broker. It sends your request to a
provider that serves the model, and that provider processes the content
too. Unless a person or server owner chose “any”, we ask
OpenRouter to route only to providers that do not collect user data
(its data_collection: deny preference). We do not send
OpenRouter’s zero-data-retention option, we cannot verify what each
provider does, and the terms of your own OpenRouter account apply as well.
We have no agreement with the model vendors behind it.
Creating an account sends one welcome email to the address you signed up with. Sign-in links come from Google’s sign-in service, not from us. Approval notices go to the people a rule names. When a workspace leaves a plan that includes a key of its own, its owners (up to 20) get one notice of the date, by email and in the app, naming the workspace and the date and never a key.
What each action removes, and what it does not.
Disconnecting your own account from a source deletes your stored credential. Deleting a source deletes the credentials of everyone connected to it. In both cases we then try to revoke the token at the provider, so it stops working there too. That is best effort: many providers offer no way to revoke, and we tell you when that is so. A REST API key is different. Deleting the API deletes the keys we hold for it, including any that people added for themselves, but we cannot revoke them at the service that issued them; revoke them there if you want them to stop working.
An admin removing a person ends their agent keys, sessions, group memberships and connections, deletes their model key, and revokes their connected tokens where providers allow. It revokes their sign-in refresh tokens and, if they have access nowhere else, disables their Identity Platform account. It takes up to 30 seconds to reach every running instance, and sign-in tokens already issued can stay valid for up to an hour. It does not erase the person: their account is disabled and their membership is marked removed, so a record of who had access remains, and their address stays in the activity record. To have a person erased, write to us. There is no button for it.
An owner can close a workspace. It stops serving immediately: no agent can use it and nothing in it can change. The owner can still read it and can reopen it until the grace period ends: 30 days, and never fewer than 7. Closing does not cancel a paid subscription; that has to be cancelled separately. Closing does not revoke anything at the services you connected, and once it is closed you cannot disconnect them, so disconnect your sources first.
When the grace period is over, deletion is not automatic. A person at Inline runs it by hand, using a script that keeps a receipt of what was erased, kept and changed. We do it within 30 days after the grace period ends.
Its sources and their sealed credentials, its registered REST APIs and their sealed keys, servers, rules, playbooks and settings; saved tools and their versions; script run records; the activity record of calls; held calls; script state; model keys and settings; agent keys, sessions and refresh tokens; memberships, groups, single sign-on registrations and claimed domains; its marketplace installs; and the large results in the bucket.
Whatever rights you have to see, correct or erase your personal information depend on where you live and which law applies. Write to the address above and we will respond within 30 days. We handle these by hand; there is no automated tool for it yet.
If what the product does changes, this page changes with it, and the date at the top says when. We would rather correct it than have it be wrong.
These are the statements above we could not stand behind yet, or that need a decision: