Privacy and egress

The one sentence: when a request runs on a machine somebody shared with you, that person's machine sees your prompt. Everything below is the detail behind that sentence, including how to turn it off.

This page describes the running system in the current public beta. The formal policy is at /privacy; this is the operator's-eye version.

What leaves your machine, and when

Saylek serves a request locally when it can. When your own machine cannot serve the model you asked for, the request goes through Saylek's registry to a machine that can: another machine of your own, one belonging to someone who shares with you, or, if you joined a group (one an organization runs or one anyone can join), one belonging to anyone in it. Nowhere else, and you do not switch this on. To leave a group, run saylek circles leave <id> (find the id with saylek circles list), or turn on local-only mode (below).

What travels:

Your prompt, and everything your tool put in the context window with it. For a coding agent that routinely means file contents, diffs, stack traces, and anything else it read on the way to the task.
The completion comes back the same way.

That machine handles both in the clear. It has to: that is how it computes the answer. It is a peer running saylek host, not an opaque cloud endpoint, but it is still a different person's computer.

It does not go straight there

Your request reaches that machine by way of our registry, which routes it. So your prompt is on Saylek's server too, not only on their machine. We do not read it and we do not train on it, but it would be wrong to let you picture a direct machine-to-machine hop.

The routing queue is trimmed by count (about 10,000 entries) and never by age. A busy queue displaces your prompt in moments. A quiet one can hold it indefinitely, because nothing deletes it for being old. The privacy notice states this in the same terms.

What the serving machine learns about you

Your display name, beside each request. On that machine's page in Saylek, its owner can see each of your requests from the last 7 days, with its model, tokens, time, outcome and measured speed, under your display name. If the machine is no longer shared with you, or you have no display name, those entries show "Member · " and the first 4 characters of your account id instead, and they stay listed.

The list never shows your prompt or reply, or your email. Their machine still reads each prompt it serves, as above, and its own records of those requests can be matched to the list by time, model and tokens.

Not using that person's machines is the only way to stay off their list. Choose Stop using their compute on their page in Sharing, or run saylek sharing stop-using --person <name>. Requests already on the list stay there until they are more than 7 days old.

Someone who shares with you chose to, and their Sharing page lists you by the name you set in your account, never by your email. The registry, which does the routing, knows which member you are.

What is kept afterwards

Nothing on a machine is deleted automatically. Receipts and activity logs stay until someone removes them by hand (saylek wipe), on your machine and on the serving one alike. Receipts hold hashes, not text, so they are not a transcript of what you typed. The full inventory is in the privacy notice.

What a shared machine sends Saylek

When you share a machine with saylek host, its agent sends Saylek figures about the machine and the engines it runs. Each row says when it is sent, why, who reads it, where it is kept and for how long. Placement is the part of Saylek that picks which machine serves a request. Live state is where Saylek holds each connected machine's current figures.

What Saylek receives	When	Why	Who reads it	Where it is kept	How long
Machine status: its status, quota, priority, capacity and admission settings	Every 10 seconds while the machine is connected	Placement	Placement and Saylek staff	Live state	Until 30 seconds after the machine disconnects
How busy the machine is, including counts of the work its engines do outside Saylek (home use)	Every 10 seconds while the machine is connected	Capacity planning and staff diagnosis	Saylek staff	Live state and the measurement store	35 days in the measurement store
A record of each request it serves for Saylek	Each request it serves for Saylek	Measurement and staff diagnosis	Saylek staff and Saylek's measurement system	The measurement store	Each request's row about 2 to 3 hours, longer during an outage. The kept samples (the last 20 per model and machine) and the counters: 35 days
Engine facts (each engine's configuration and model list, and whether its metrics endpoint is on) and the agent's version	When the machine connects, and when one of them changes	Placement	Placement and Saylek staff	Live state	Until 30 seconds after the machine disconnects
The engines and models found on your machine, including models you have not chosen to share	When your machine connects, and whenever the engines or models on it change, even if you are not sharing the machine	To show you which models we found, and to help you share them	You and Saylek staff. It is not used to send requests to your machine	Live state	Until 30 seconds after your machine disconnects
A failure report	When something fails	Staff diagnosis	Saylek staff	The report store	No fixed limit
Engine readings: each engine's token totals, its start time, how many requests are running and waiting, how full its cache memory is, and, for each slot, the tokens it holds and its task number; whether each shared model is loaded. The engine's address on your local network identifies it	Once per check of each engine, every 60 seconds give or take 20%, while you share the machine and Saylek's server has accepted readings on its connection	Placement and staff diagnosis	Placement and Saylek staff only	Live state	Until the engine leaves the machine's routes, 30 seconds after the machine disconnects, when you stop sharing it, or when Saylek's server stops accepting readings
End stamps: each request's reference to the engine's latest reading at the end of the request. Saylek stores each check's reading once, and only when a request refers to it: every request the engine finishes before its next check refers to that one copy	Each finished request on an engine Saylek routes to, while Saylek's server accepts readings	Staff diagnosis, and placement through the live readings	Saylek staff	The measurement store	Each request's reference about 2 to 3 hours, and the reading it refers to up to an hour longer: about 2 to 4 hours in all, longer during an outage
Reading counts: how many readings arrived or were missing, per value and per reason, and three counts about the machine's status updates	Each reading, and each status update	Staff diagnosis	Saylek staff	The measurement store	35 days
Saylek's server log of parts it dropped: the machine's id, the reason and how many	When Saylek's server drops part of what a machine sent	Staff diagnosis	Saylek staff	The log store	Rotated by size, no time limit
Backups of everything above that sits in Saylek's databases	Every night	Recovery	Saylek staff	Nightly copies of Saylek's databases, and each Saylek region's own backups	No fixed maximum. Each nightly copy is kept 14 days; snapshots of those copies are then pruned to 7 daily, 8 weekly and 12 monthly ones. A region's own backups keep 7 daily and 4 weekly copies

Engine readings and end stamps hold no prompts and no replies. Their token totals do show how much each engine worked between checks, your own use of it outside Saylek included.

Engine readings and end stamps start only when Saylek's server accepts them. A machine sends them only on a connection where the server has accepted readings, and the server accepts them on no connection before the privacy notice states them.

Stopping sharing is the only way to stop engine readings and end stamps. Run saylek host stop. Your machine then starts no new reads of its engines and sends none, Saylek's server releases the live readings it holds for the machine, and end stamps still waiting on your machine to be sent are removed rather than sent.

Deleting your account does not yet remove them. End stamps, reading counts and live readings stay after your account is deleted, and they keep arriving for as long as the machine stays connected. To stop them arriving, stop sharing before you delete your account; what is already kept then ends on the times in the table.

If you run TensorRT-LLM with its statistics turned on: Saylek reads those statistics first, on every check. Each read empties them for every other reader, so any other tool on your machine that reads them sees only what built up since Saylek's last read. A read takes seconds.

Saylek's answer to "who can see my requests" is who runs the machine that serves them, not encryption:

Your requests go to machines of people who share with you, or to your own machines.
If you joined a group, one an organization runs or one anyone can join, they also go to everyone in it.
The person whose machine serves your request can see what it serves. No setting changes that.

The honest rule of thumb: do not send anything you would not hand to the person whose machine runs it. It is the same judgement you already make about who you let watch your screen. See Sharing and access for how to see who that is.

Turning egress off

Two controls, and both can only force a request to stay local. Neither can ever force a request out.

Persistent: local-only mode

Set in ~/.saylek/config.toml:

[federation]
local_only = true

With this on, Saylek will not route a request through your machine to anyone else. It serves locally or it fails.

Be precise about the scope, in three directions.

It covers requests that go through your machine, because that is where it is read. A request an application sends straight to Saylek's hosted API with an application key never passes through your machine, so local-only does not apply to it.

It stops your prompts, uploads, and completions going to another member. Saylek still talks to our servers for the ordinary running of your account, such as signing in, checking who shares with you, and looking for updates. Local-only is a content control, not an airgap.

It also does not override an upstream you configured yourself. If you have registered a proxy upstream in upstreams.toml and you call a model that resolves to it, the request is forwarded there, local-only or not. That is deliberate in the sense that you set it up, but it is not what "local-only" sounds like, so: local-only governs Saylek's routing, not a destination you added by hand. If you want nothing forwarded anywhere, turn the upstream off as well.

Be clear about the trade: if your machine has no GPU capable of serving the model, every such request now fails. That is the honest semantics, not a bug. Local-only means local, including when local cannot answer.

Per request: a header

For a single call, without changing your config:

curl http://127.0.0.1:8443/v1/chat/completions \
  -H "x-saylek-local-only: 1" \
  -H "Content-Type: application/json" \
  -d '{"model": "MODEL_ID", "messages": [{"role": "user", "content": "hello"}]}'

The header forces that one request local. It cannot override persistent local-only mode to force egress.

Giving up access withdraws it

Giving up access withdraws that person's machine, not egress. With nobody sharing with you, a request your machine cannot serve can still run on another machine of your own. With no other machine of your own either, it has nowhere to go and is refused.

Once Saylek tells you that you have given up access, none of your later requests reaches that person's machine. A request that was already running there when you gave up access is not stopped. If Saylek's registry cannot confirm that its record of who shares with you is current, it sends your requests to nobody who shares with you until it can. Such a request fails with an error that asks you to retry, or it runs on another machine of your own. If you want requests through your machine to stay on it, set local-only, which takes effect at once because it is read on your side.

What receipts prove

Every request that goes through your machine and completes mints a signed receipt. One that fails or is stopped part-way does not, and neither does a request an application sends straight to Saylek's hosted API. A receipt served elsewhere names the serving machine by its key fingerprint, co-signed by both sides. Verifying is offline, and the command depends on whether you want one receipt or all of them:

saylek receipt show <id> --verify   # one receipt, with the signature check appended
saylek receipt verify --all         # walk every receipt under ~/.saylek/receipts/

saylek receipt verify on its own does nothing on purpose: batch verification is the kind of thing you should have to ask for explicitly, so it refuses without --all.

Receipts prove	Receipts do not prove
This request ran on this machine, on this model, at this time	That the content stayed private from that machine
Both parties attest to it	Anything about confidentiality

A verified receipt means "this is who ran it". It does not mean "this was private". The machine signing your receipt is the same one that saw your prompt. saylek receipt show <id> says exactly this in plain language before it prints the audit body.

You do not need the daemon, or an account, to check a receipt. saylek-verify is a separate program built from the receipt code alone, and a test in the repository fails the build if it ever links daemon code, so what checks a receipt cannot be what produced it. Download it from https://saylek.com/b/VERSION/saylek-verify-TARGET, where TARGET is macos-arm64 or linux-x86_64 and https://saylek.com/m/stable names the current VERSION. Its minisign signature is at the same path with .minisig added. No sample receipt is published yet, so without an account there is nothing to run it against.

What we do not claim

Not encrypted from the machine that serves it. A request served elsewhere is readable there. It is TLS-encrypted in transit, which protects it from anyone in between, not from the people it is travelling to.
Not confidential compute. Making a serving machine unable to read what it runs (enclaves, content-blinding) is a V-Next direction under assessment. It is not in the current release, and nothing here depends on it.
Not "your prompt is never written to disk anywhere." Saylek has an opt-in debugging setting ([debug] traces = true) that writes prompts and replies to a plaintext file so an operator can see what their own machine is doing. It is off by default, and as the code stands another person's request does not reach that writer. But that is because of how the request happens to be shaped, not because a rule stops it. We are turning that into an actual rule.

If you point Saylek at a different registry with an http:// address it will use an unencrypted connection and will not warn you. Do not do that outside a trusted local network.

Next steps

Sharing and access: who can reach your machine, and how to end it.
Concepts: where this sits in the whole model.
/privacy: the formal policy page.

Last checked 2026-10-08 · read as markdown at /docs/privacy-and-egress.md