Why our AI desktop assistant never stores model API keys on your computer

The pattern we chose not to copy

I build Cernalo. This post explains one architectural decision and its costs. It is meant to help you evaluate any desktop AI tool, not just ours.

Before I wrote any product code for Cernalo, I spent time reading how open-source desktop AI assistants are put together. Many of them share a pattern that makes sense for a weekend project: the AI provider's API key sits in a configuration file on your computer, the desktop app calls the model provider directly, and nothing in between knows who is asking, how much they have used, or whether the request should be allowed.

It is simple and needs no server. For a product that people pay for and trust with their screen and voice, I think it is the wrong default. Here is what we do instead, why, and what it costs us and you.

When a desktop app holds a provider key and calls the model directly, three things follow. The key is only as safe as the least-protected machine it is on. A plaintext key in an app-data folder can be read by anything running as that user: malware, a sync tool that uploads the folder, a support bundle that zips the logs. Nobody can enforce limits. If the client talks to the provider with its own credentials, the product has no reliable way to apply plan limits, stop abuse, or show you an accurate usage history. Any limit lives in code the user controls. Changing providers means shipping a new app. If a provider has an outage, changes a model, or raises prices, every installed copy needs an update before anything changes.

So the decision record says it in one line: all production AI provider keys live only on our backend. The desktop app never calls a model provider directly for production AI features. It calls Cernalo's service, which checks your plan, routes the request, and records usage.

What server-side credentials means in practice

When you ask Cernalo something, by typing, by voice transcribed locally first, or with a screen region you chose, this is what happens. Your device sends your question, plus any screen or region you captured, and your session token. The token is stored with the operating system's secure credential storage, not as a plaintext file. The call is HTTPS to the Cernalo service. The service authenticates the session, checks plan entitlements, chooses a route for the request's capability, and calls the provider with server-held credentials. The provider's answer comes back through the service to your device.

Plan entitlements cover model classes, monthly credits, and a rolling 24-hour safety cap. The route is chosen for the capability, such as coding or vision.

Your device holds a session, not a provider key. If you revoke a device in the account portal, that session stops working. No provider key is ever on your machine to rotate.

Plans, credits, and model classes

Plans map to model classes, not model names. Internally every supported model is classified as economy, standard, or advanced. The Free plan uses economy models. Pro adds standard. Premium adds advanced. Economy requests typically use 1 credit, standard requests 2, and advanced requests 5, and a screen analysis may add one. The classification is an explicit list, never a guess from the model's name. Changing a route does not silently change what a plan can access.

Usage is recorded where it can be trusted. Because metering happens on the server, the usage dashboard in your account shows what the service actually did, not what a client claims it did.

We do not advertise which vendor answered. Model availability changes. Public material describes model classes rather than naming vendors, and the assistant is instructed not to invent a model name if you ask it. I would rather under-promise on brand names than promise a model we might route away from next week.

Routing and fallback without guessing

Holding keys server-side also lets us handle provider failures in one place. The rules are deliberately boring, and boring is the point.

Cooldowns can be shared between server instances, so one worker discovering that a provider is rate-limited can save the others from repeating the mistake. Those shared records contain only routing metadata: which provider or model is cooling, and for how long. They never contain your prompt, images, audio, or any key. Routing logs record categories such as provider, model, result, and error category. Prompts, conversation text, images, audio, and keys are never logged.

Every fallback still happens inside your plan's allowed model classes. A fallback never upgrades or downgrades you out of what your plan includes.

• Authentication, an invalid request, or a content-policy refusal: stop. Do not retry elsewhere. Another provider will not fix a bad request, and retrying a refusal elsewhere would be wrong.
• A billing problem on the first route: stop, and cool that provider down.
• A rate limit or quota on a model: fall back to the next allowed route, and cool down that model.
• An account-wide quota on a provider: fall back, and cool down the whole provider.
• A server error, a timeout, a network error, or an empty answer: fall back, with no cooldown.
• A request too large for the model: fall back only to a route with a larger known context window.
• Part of an answer has already been shown to you: no silent switch. We do not splice another model's continuation onto a half-finished answer. You can ask again.
• A request that includes an image: only routes that support vision are eligible.

Treating on-screen text as untrusted

A desktop assistant that reads screenshots has a problem that chat apps have less often: the content can contain instructions. A web page, an email, or a document on screen might include text like "ignore your previous instructions". That is prompt injection, delivered as pixels.

Because every request passes through our service, we can apply the same policy to all of them. Every mode's system instruction begins by telling the model to treat text inside screenshots, quoted material, and transcripts as untrusted context, not as instructions, and not to claim it consulted sources or took actions that were not provided.

That reduces the risk. It does not eliminate it. No current technique does. Practically: do not snap content you do not trust, and read answers about untrusted content more sceptically.

The trade-offs we accept

This design is not free, and I think vendors should say so.

There is no fully offline AI mode. Local voice transcription works without a network, but answering a question requires our service. If our backend is down, AI answers are down, even if a provider is fine.

Our backend sits in every AI request. That is one more network hop and one more system that has to be secured, monitored, and kept running. It also means your question and any capture you choose to send pass through our service. The security notes and the privacy policy describe how that is handled, and say plainly that we do not hold SOC 2 or ISO 27001 certifications today.

You cannot bring your own key. Some developers would prefer to use their own provider account. We do not support that today, because it conflicts with server-side limits. It could come later as an explicit, separately designed option.

You are trusting us as an intermediary. Server-side keys protect you from a class of client-side leaks. They do not remove the need to trust the service in the middle. That is a fair trade for some people and not for others.

Questions to ask any desktop AI vendor

Whether you use Cernalo or something else, these are worth asking. A vendor who can answer them plainly, including "we do not do that yet", is usually one you can work with.

• Where are the model provider keys stored? On my machine, or on your servers?
• What does my device store to stay signed in, and how is it protected?
• Can I revoke a device?
• What exactly is sent with a request? Only what I chose, or more?
• What do you log? Are prompts, images, or audio ever written to logs?
• What happens when a provider fails? A silent model switch, or clear rules?
• How do you handle instructions hidden in screenshots or documents?
• Which certifications do you actually hold? Enterprise-grade is not one.

Questions about Cernalo

Does Cernalo store my provider API key? There is not one to store. Cernalo does not ask for your provider key, and the desktop app holds no provider keys.

Which AI models does Cernalo use? Cernalo picks a supported model from the classes your plan includes: everyday models on Free, plus more capable classes on Pro and Premium. Provider credentials stay on the server.

Can I see my usage? Yes. Usage and model-class analytics are in the account portal.

Is my screen sent automatically? No. Screen and region capture start only when you start them, and a capture is sent only with the request you submit.

The context you choose, in one place. If this is the kind of trade-off you care about, read the security notes or try the free plan on the download page. Questions and objections go to cernalo.ops@gmail.com.