A router that cannot read your prompts

When the Graspable agent runs on a Routstr node, it pays a stranger's server in bitcoin to pass its requests to a model provider. There is no account and no card, which is the point. The price is trust: the node holds the provider's API key, so every request goes through it in the clear.

The person who runs the node can read your prompts, which for an agent means your source code. They can change what comes back, including the tool calls the agent then carries out on your computer. And they can run a cheaper model than the one you chose and bill you for the dear one.

A node can now give all of that up, and Graspable can use it that way.

The idea, from Juraj Bednar

Juraj Bednar runs the Routstr node at routstr.cypherpunk.today and is a co-founder of Paralelná Polis. On 10 October 2026 he published a protocol, a paper, and working code for what he calls confidential mode:

• the paper, "Confidential and verifiable upstream inference over standard TLS 1.3";
• his introduction to it;
• the code, and a version that runs in a browser tab.

The usual answer to "how do I know the server is not reading my data" is a hardware enclave: the server proves it runs known software inside a protected chip. That moves the trust to the chip maker, and it has to be checked again after every software update. His design needs none of it. In the paper's words, it "rests instead on the provider's TLS certificate and on cryptography."

The agent is the TLS client of the provider. The encrypted connection runs between your computer and the provider (on his node, Venice). The node sits in the path and relays the encrypted records.

The keys are computed by two parties and split between them. A normal TLS client would hold every key of the session, including the one that protects the request's first lines, where the API key goes. So the agent and the node run the handshake's key derivation together, as a two-party computation in which neither learns the other's part. The node comes out with the key for the short opening section, where it writes its API key. The agent comes out with the keys for the request body and for the answer. The paper is exact that the shared work covers the key schedule only, never the content (section 1).

Proofs go in both directions. The node proves, without revealing its key, that what it wrote is the published request header and nothing else (section 4.5). The agent proves, without revealing the prompt, that its request ends in an agreed block fixing the model and the token limit, and the provider receives the full request only after that proof checks out (section 4.6). So the node knows it is not being made to pay for something else, and you know which model answered.

The bill is the provider's own count. At the end the agent proves that the usage figures it discloses are the genuine last part of the provider's answer, and the node charges that usage at the rates of an offer it signed beforehand, on a receipt it signs (sections 4.7 and 4.8).

What the node still learns is stated plainly in the paper's security analysis (section 5): which model, when, and how long requests and answers are. Message sizes can say something about content. It can also cut the connection. It cannot read or alter the conversation. One thing stays out of reach of any such proof, as his introduction says: which weights the provider really runs behind the model's name.

What Graspable does with it

Graspable does not reimplement any of this. It runs his open-source client, the same one behind the browser demo, inside the agent on your computer, pinned to an exact version.

Under a Routstr balance, where the node offers it, there is now a Confidential mode switch. Switching it on pins the node's signing key and the provider it relays to, as the node states them at that moment. From then on:

• every request the agent makes to the model becomes one confidential session;
• an offer signed by a different key, or naming a different provider, is refused;
• each request shows a line in the run with what was verified: the provider the agent really spoke to, its certificate, the proofs, and the cost from the signed receipt;
• if a request cannot be made confidentially, it is not made. Graspable never falls back to sending it the ordinary way.

What we measured

On 10 October 2026 we ran it against his node from the Graspable agent, with a balance of 300 sats paid by Lightning.

• A plain question and a request that ends in a tool call both completed and verified. Each took about 9 seconds and cost about 0.03 sats.
• We asked the agent to make a one-line change in a new React XR project. It read the file, edited it, and the project then passed the build and the browser check. That took four model requests. All four verified, taking between 9 and 13 seconds each, and the whole run cost 3.7 sats.
• The agent's read_file and edit_file calls came through the confidential connection and were carried out normally.

Our test was one node, one provider and one small model, and the runs were short. The author's own measurements, on his setup, are in section 6 of the paper.

What it costs

This is slower and heavier than the ordinary mode.

• Each request is its own session. The paper puts the traffic at about 22 MB from the node to the client and 1.2 MB back per request. An agent makes many requests in a run, so a long one moves a lot of data.
• Requests take longer. Ours took 9 to 13 seconds each from start to finish. The protocol can prepare a session ahead of time to shorten this; Graspable does not do that yet, because a prepared session that goes unused costs a small fee, and an agent's next request is not known in advance.
• More of the balance is held while a request runs. While a request runs, the node sets aside the cost of a full context for the model, and releases what was not used. We watched a 299-sat balance show 183 available during a run and 296 after it.
• Sizes are limited: answers up to 32,768 tokens and requests up to 8 MB on his node.

For a quick edit to a scene, the ordinary mode is the better tool. For work where the prompts are the valuable part, the wait buys something real.

How far to trust it

The two-party computation is a variant with no published proof, and the paper says the construction as a whole needs external review (section 5). His introduction calls the work new and experimental and asks people to try to break it.

There is also a party the protocol cannot remove: whoever ships the code that runs the checks. In the browser demo that is the web page. In Graspable it is us. We pin his client to an exact version and review what changed before moving the pin, since that code sees your prompts.

So confidential mode in Graspable is marked experimental, off until you switch it on, and described with its costs next to the switch.

Try it

In Graspable: Settings, AI for the agent, add Routstr, paid with bitcoin, choose a node that offers confidential mode, pay the invoice from your own wallet, and switch Confidential mode on under the balance. The documentation has the details.

Without Graspable: his browser version does every check in the page itself.

Sources

• Juraj Bednar, "Confidential and verifiable upstream inference over standard TLS 1.3: A no-trusted-hardware protocol for LLM routing nodes", 10 October 2026. Sections 1, 4.5 to 4.8, 5 and 6 are the ones referred to above.
• Juraj Bednar, "Confidential inference on Routstr without trusted hardware", 10 October 2026.
• routstr-confidential and routstr-confidential-web, the protocol's code and the client Graspable uses, both under the MIT licence.
• Routstr, the network of nodes.