# 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.

## 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 and uses local access patterns already trusted by the operator.
- Clanker account, download, payment, and support flows are separate from cloud credential custody.

## What can be sent to model providers

The model provider you configure can receive the user question plus selected context needed to answer: resource metadata, topology, logs, cost summaries, or plan text.

## What is never sent to Clanker servers

Normal local operations do not send cloud credentials, kubeconfigs, provider tokens, database passwords, or BYOK model keys to Clanker Cloud servers.

## Read-only mode

Ask, inspect, scan, and explain workflows gather evidence first. They are designed for read-only provider and cluster context.

## Maker mode

Maker mode generates a plan artifact. Apply mode is separate and requires explicit approval. Destructive operations require explicit destructive-operation allowance.

## Logs and telemetry

Debug logs are local-first and credential-masked before being shown or sent through debug flows. Feedback is optional and user-provided. Support messages should not include secrets.

## BYOK

Use your own model provider keys or local OpenAI-compatible endpoint where configured. Model-provider billing and retention are governed by the provider and key you choose.

## MCP localhost boundary

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.