Credentials never leave the device: how client-side AI access actually works
“Your data never leaves your device” is the most abused sentence in enterprise AI. Taken literally it is almost never true — if a frontier model — one of the big AI engines that actually write the answers — answers your question, your question went somewhere. So this article does the unfashionable thing and gets precise: where the credentials live, exactly what leaves the device, to whom it goes, and what that architecture does to your threat model. If you evaluate AI platforms for a living, this is the level of specificity to demand from everyone.
The old way: the server-side credential vault
The standard workplace-AI architecture asks you to hand over the crown jewels up front. Your model API keys: stored in the vendor’s cloud. Your service tokens for connected apps: stored in the vendor’s cloud. Every request from every employee: routed through the vendor’s infrastructure, where it can be logged, inspected, retained under terms you skimmed, and monetized as resold inference. The design is honest about nothing so much as its own priorities — it exists so the vendor can meter, so the vendor can bundle, so the vendor can sit in the flow.
What you inherit in exchange is a concentrated risk you didn’t previously have:
- A breach of them is a breach of you. One compromised vault exposes keys and tokens for every customer at once — the single most attractive target you can construct.
- A subpoena to them reaches you. Requests, logs, and retained content sit inside another company’s legal perimeter, in whatever jurisdiction they chose.
- Their pivot is your migration. Price change, acquisition, terms update — the proxy renegotiates your risk posture without asking you.
The client-side design, stated exactly
CloudTop is the AI workspace you own, and its answer fits in one carefully-worded paragraph, and the wording is the product: CloudTop never holds your model key, never proxies the traffic, and never bills for inference. The key sits in your own settings, on your own device. Only what you ask the AI to look at leaves — going to the model you picked.
Read the three “nevers” as architecture, not marketing. Never holds the key: there is no server-side vault to breach, because the key is stored with the user, in their settings, on their machine. Never proxies: when a request goes to a model, it goes from the user’s device to the model provider the user configured — CloudTop is not a hop in the path and cannot log what it never sees. Never bills for inference: you pay the model provider directly, at their price; there is no metering box because there is no meter.
“Only what you ask the AI to look at” — unpacked
The honest half of the sentence is the second half, so let’s not rush it. When you ask the assistant a question, the material needed to answer it does leave: your prompt, plus whatever the AI reads to fulfil it — from the folders you granted, and nothing else. This is a governed flow, not zero flow, and three properties make it governable:
- Scope precedes access. The AI can only read folders a human granted, and inside applications the rules go to the data row. Ungrated material cannot be “accidentally included” because it was never reachable.
- Destination is chosen, per task. The request goes to the model the user selected for that task — which means jurisdiction-sensitive work can go to a model governed accordingly, while bulk work goes wherever is cheap. See bring your own model.
- Every action leaves a trace. Each AI reply carries a visible record of which tools it used and what it touched, in the same event stream as human actions — one audit trail, not two.
Server-side vault
- Keys & tokens stored with the vendor
- All traffic transits vendor infrastructure
- Inference metered, marked up, resold
- Blast radius: every customer at once
Client-side, in CloudTop
- Key in the user’s settings, on the device
- Requests go device → chosen model, directly
- You pay the model provider, at cost
- Blast radius: one device, one scope
Example: connecting a service
A consultant connects her project tracker to the workspace so the assistant can summarize open tickets. The old way, that means her tracker token goes into a platform’s server vault, and every summary request routes her ticket data through it. In CloudTop the connection is made on her device; the token stays in her settings; and when she asks “what changed this week?”, the assistant reads the tickets locally through the app’s tools and sends the model only the material of the question. Her security team’s review is one paragraph instead of a vendor questionnaire — the answer to “where are our tokens stored?” is with us.
What this doesn’t solve — said out loud
Client-side architecture is not a magic trust eraser. You are still trusting the model provider you chose with what you send it — that trust is now explicit, chosen, and swappable, which is the point, but it is not zero. Devices still need securing; a granted folder is still granted. What the design removes is the involuntary middle party — the one counterparty you never chose, holding the one asset (everyone’s keys, everyone’s traffic) that no one should hold. Sovereignty — as the definition piece argues — lives at the boundary — and this is what it looks like when the boundary belongs to you.
AI that belongs to you.
CloudTop is the sovereign workspace for AI — already built, and opening soon. Join the waitlist to be there when it does.
Join the waitlist