Storage model
Provider credentials remain in local provider CLIs, kubeconfig files, local preferences, or the operator-controlled runtime. The desktop app launches a local backend.
Trust boundary
Local credentials in Clanker Cloud
Clanker Cloud is designed around the machine that already has trusted infrastructure access. Cloud credentials, kubeconfigs, database connection details, and BYOK model keys stay in the local runtime instead of being migrated into a hosted Clanker control plane.
This page states the operational boundary directly: what is stored locally, what can be sent to model providers, what is never sent to Clanker servers, how read-only and maker modes differ, and how logs, telemetry, BYOK, and MCP localhost access work.
The product trust model is local custody first: connect existing access locally, gather evidence, ask the model with selected context, and require explicit review before changes.
Model-provider path
Selected prompts and infrastructure context can go to the model provider you configure. Raw cloud secret values and kubeconfig files are not the product payload.
No Clanker credential custody
Clanker servers handle account, download, payment, and support flows, not hosted storage of your cloud credentials or BYOK model keys.
Explicit action boundary
Read-only queries inspect first. Maker mode generates a plan. Apply requires explicit approval and a reviewed artifact.
Data boundary
What is local, what can leave, and what does not go to Clanker
| Surface | How it works | Boundary |
|---|---|---|
| Cloud credentials | AWS profiles, GCP ADC, Azure CLI context, Cloudflare tokens, kubeconfigs, and similar provider access stay on the operator machine. | Not stored by Clanker Cloud servers for normal local operations. |
| Model calls | The selected model provider can receive the user question plus selected resource summaries, topology, logs, cost, or plan context needed to answer. | Raw provider secrets, kubeconfig files, and BYOK key values should not be sent as model content. |
| Account service | Clanker account, downloads, social sign-in, payment, and support flows use the hosted account backend. | This is separate from cloud credential custody. |
| Debug logs | Local and backend logs are masked for credential patterns and debug upload is controlled by explicit debug/feedback flows. | Do not use feedback or support messages to paste secrets. |
| MCP | MCP is exposed locally through stdio or localhost-style transport from the running app or CLI. | It is an agent access surface on the local machine, not a public hosted MCP endpoint. |
Modes
Read-only mode and maker mode are different by design
Read-only
Ask, inspect, scan, and explain first
Default workflows gather provider, cluster, repo, cost, and runtime evidence without changing infrastructure.
Maker
Generate a plan without applying it
Maker mode produces a reviewable plan artifact so humans can inspect intent, cost, and blast radius.
Apply
Apply requires explicit approval
Apply mode is separate and uses a reviewed plan file or approved UI flow. Destructive plans require explicit destructive-operation allowance.
BYOK and telemetry
Control model spend and support data separately
BYOK model path
- Use your own OpenAI, Gemini, Anthropic, Cohere, DeepSeek, MiniMax, GitHub Models, Bedrock, or OpenAI-compatible local endpoint where configured.
- Model-provider billing and retention are governed by the provider and key you choose.
- Clanker Cloud does not need to resell model tokens for the local-first workflow to work.
Telemetry and logs
- Debug logs are local-first and credential-masked before being shown or sent through debug flows.
- Feedback is optional and user-provided.
- Support requests should describe the issue without pasting cloud secrets, kubeconfigs, database passwords, or model keys.
Proof pages
Verify the boundary through workflows
FAQ
Common questions
What is sent to model providers?
The model provider can receive the question and selected context needed for the answer, such as resource metadata, topology, logs, cost summaries, or plan text. Secret values, kubeconfig files, provider tokens, and BYOK key values are not intended model payloads.
What is never sent to Clanker Cloud servers?
Normal local operations do not send cloud credentials, kubeconfigs, provider tokens, database passwords, or BYOK model keys to Clanker Cloud servers. Account, billing, download, and support data are separate hosted flows.
Can MCP agents change infrastructure automatically?
Agents can use the local MCP surface, but high-impact changes still belong behind the Clanker safety model: read first, generate a reviewed plan, and apply only after explicit approval.
Next step
Want the architecture view?
Read how the local runtime, provider APIs, model calls, MCP, and reviewed-plan execution fit together.