Start free. Pay when it is doing real work.

Start free. Move up when your tools are doing enough work to be worth it.

Four things no plan takes away.

• ApprovalsHolding a call for a person is a safety control, not an upsell.
• RulesWhatever you decided an assistant may not do stays decided.
• The audit logWritten on every plan, and kept for the same 365 days on every plan.
• Reading your own historyYour record of what happened is yours, including after you stop paying.

The controls are the same on every plan. The key is not.

The audit trail, scoped keys that fail closed, the erasure receipt and the backups below are identical on every plan. What differs is which key seals your stored credentials: Free uses one shared with other workspaces by default, and Pro has a key of its own.

• Credentials, sealed
  Stored credentials are encrypted with a Cloud KMS key, and the workspace they belong to is part of the lock: a credential sealed in the current format cannot be opened while serving a different workspace, so a bug that mixed workspaces up would fail instead of leaking. Our service and the administrators who run it can still open any workspace’s credentials on purpose, as the privacy policy says. Values in older formats carry no workspace, and a deployment that has not finished re-sealing them can still open them. REST API keys you register are sealed the same way, with your workspace’s key, and stored in your workspace. Which key it is depends on the plan, below. The tokens your agents authenticate with use a separate hardware-backed key.
• Free: a shared key by default
  Stored credentials are sealed under a key shared with other workspaces, with the workspace bound into each value sealed in the current format. That keeps workspaces apart; it does not let you destroy a key to make your credentials unreadable, because the key is not yours alone. It is the plan’s default. On request we can give a single workspace a key of its own by hand; erasing that workspace then leaves destroying the key to us, also by hand.
• Pro: a key of your own
  A key that seals only your workspace’s stored credentials and secrets. We make and hold the key in Cloud KMS: you cannot hold, disable or destroy it yourself, and only we can undo a destruction during its window. When a workspace is erased, its key is destroyed. After a 30-day window in which the destruction can be undone, the stored credentials and secrets sealed under that key cannot be opened by anyone, us included. Erasure is done by a person after a closed workspace’s 30-day grace period, with no fixed deadline yet, and a closed workspace keeps its key until then. There is no self-serve destroy button today. The key does not stop Inline using your credentials while it exists, which it has to do on your behalf. What it does not do, in the order that matters most:

  1. It covers stored credentials and secrets, not everything Inline holds. Not sealed by this key: tool-call arguments in the activity record, script source and run records, saved tool versions, large results, audit rows, and workspace configuration and settings. Agent keys use a separate hardware-backed key.
  2. It takes effect once the move to your own key has finished. The app shows the date your move finished; until then, values stored earlier are still under the shared key.
  3. Backups taken before then still hold a copy under the shared key until they age out: 7 days for daily backups, 98 days for weekly ones. Database point-in-time recovery also keeps earlier versions for 7 days.

  If you leave Pro, your credentials are returned to the shared key before your key is destroyed. From then on, destroying a key can no longer make them unreadable. Before anything moves, Inline tells the workspace owners, in the app and by email, the date it will happen and what it means, at least 7 days ahead. The email goes to up to 20 owners; every member sees the notice in the app. Staying on the plan, or coming back to it before that date, keeps the key. Coming back after the move has finished is different: the old key is destroyed first, and a new one is made and filled over the days after, with your credentials on the shared key until then.

• A trail you can check without trusting us
  Every governed call and every administrative change is written once and never replaced. Each row carries a hash that chains it to the one before, so an edited, deleted or reordered row is visible to anyone holding a copy — and the checker is a single file that imports nothing from Inline, which you are welcome to read before you run it.
• A limited key stays limited
  An agent key scoped to particular tools is refused every tool if we cannot read what it is allowed to do. It never widens to everything because a lookup failed.
• Your model calls are yours
  When a process asks a language model something, it is paid for with your own OpenRouter key or your organisation’s, within caps you set. We buy no model tokens, so there is no pool of ours for your prompts to be routed through.
• Recoverable
  Every database is backed up daily and kept for a week, weekly and kept for fourteen, with point-in-time recovery on top. Alerts watch the parts that fail quietly — a lost audit row, a key used by anyone but the service, a database written by anyone but the service.
• Deletable
  Ask, and a person’s data is erased with a receipt saying what went, what was kept and the reason it was kept. A workspace is erased the same way. Copies stay in backups until they age out, up to 14 weeks.

What we do not have, said plainly: no SOC 2 report, no second factor required of everyone by default (each person can turn one on; requiring it of a workspace is set up with us), no single-tenant database, and no completed restore rehearsal — so we quote no recovery time. If any of those decide it for you, we are not there yet.

Before you pick one