What Soba sees

Exactly what crosses Soba, what never leaves the user's machine, and what is kept afterwards. Written for the question an enterprise buyer asks first.

The overview says you own the tools and the data. That is true, and it is worth being precise about, because a run's prompt does travel through Soba: the boundary is not "nothing" and claiming otherwise would not survive the first security review.

What crosses Soba#

Everything a run needs in order to happen somewhere else, which is:


The request	`prompt` or `messages`, the `system` slot, `model`, the `policy` and `route` you asked for
Tool schemas	The `name`, `description` and `inputSchema` of every app-defined tool
Tool calls and results	The model's arguments, and what your app answered. They travel between the machine and your app, so they pass through Soba
The output	Every `delta`, `thinking` and `status` event, which is the answer itself
Usage	Model, provider, token counts, cost class, cost in micros

If a tool returns a customer record, that record crosses Soba on its way back to the model. Design your tool results the way you would design an API response to a third party, because for the duration of the run that is what Soba is.

What never leaves the machine#


Files and directories	The model reads them on the machine. Their contents reach Soba only if the model quotes them into its answer
The shell	Commands run there. Soba sees a `status` event with a tool slug, not a command line
Provider credentials	The user's Claude or ChatGPT login stays in their CLI. The worker never reads it and Soba never receives it
Your tool code	Only the schema is registered. The implementation runs in your app, against the data it already touches
Metered provider keys	Stripped from the child environment unless the owner opts in
Approval decisions	Appended to `~/.soba/audit.log` on that machine

Nor do your own provider keys, which never reach Soba at all. A run handed back to your app is served in your app, with your key, and only its usage is reported.

What is kept#

Soba's own records are what billing and routing need, and nothing else:

A run row: who it was attributed to, which machine and runtime served it, the cost class, the outcome, the environment.
A usage row: model, provider, token counts, cost in integer micros.
A billing record: which Stripe customer, subscription and plan a user maps to, and every write Soba made to your Stripe account. Card details never reach Soba; Stripe holds them.

Prompts, messages and completion text are not part of that record. They pass through in flight and are not retained, which is why the dashboard can tell you what a run cost and never what it was about.

This is the claim to check before you rely on it

Everything above describes the system as designed. If you are answering a security questionnaire, ask for it in writing rather than citing a docs page, including retention windows for the run and usage rows themselves, which are a policy question rather than an architectural one.

Why Soba is not trusted with more#

Soba is the component this architecture asks you to trust least, which is why the policy intersection runs on the worker rather than here. The same reasoning bounds what Soba can learn:

It cannot widen a machine's grant, so it cannot ask a run to read a file the owner did not put in roots.
It cannot enable a sensitive tool by request, so it cannot reach bash, write or edit on a machine whose owner did not grant them.
It cannot use the approval channel to probe: a tool outside the askable set is refused without asking anyone, so no request is sent that would reveal what a machine might say yes to.
A run arriving over the network does not inherit the owner's CLAUDE.md, hooks, skills or plugins, so a remote prompt cannot trigger local configuration.

The honest residue, stated in the security model too: with an agent runtime the resolved policy is advisory: the CLI is given the permitted tool set and is trusted to honour it. With a model runtime the gate is in-process and nothing has to be trusted.

The end user's side#

They are the other party to this, and the product is built so they can see it:

No credential is ever displayed or pasted. Pairing is a device grant approved in a browser where they are already signed in.
What their machine will and will not allow is a file they own, on their disk.
Every approval decision is logged locally, on their machine, not on Soba's.
The run is on their machine, under their login, for their own account, which is not a courtesy but the distinction the whole design rests on.