Every time an engineering team adds a SaaS cloud management tool, they make an implicit trust decision: that vendor's security posture, breach response, and data handling practices become part of their attack surface. For one tool, that might be an acceptable trade. For a stack of five or six tools each touching production cloud credentials, the exposure adds up.
Clanker Cloud is built on a different premise. It is a native desktop application — not a web app, not a browser extension, not a SaaS platform. That distinction has direct consequences for local-first cloud workspace security, and this article explains exactly what those consequences are.
The Credential Problem with SaaS Cloud Tools
When you connect a SaaS cloud management tool to your AWS account, something specific happens: your credentials — whether an IAM access key pair, an assumed role ARN, or a service account token — travel from your machine to that vendor's servers. They are stored, typically encrypted, in that vendor's cloud database.
This creates several risks that security engineers understand well:
Credential aggregation. A vendor managing cloud access for thousands of customers accumulates a large number of credentials in one place. A single breach exposes all of them simultaneously.
Third-party trust chain. Your credentials are only as safe as the weakest link that has access to them. The vendor's patch cadence, secrets management, and employee access controls become part of your attack surface, whether or not you have reviewed them.
Compliance scope expansion. Every vendor that touches sensitive data adds a new entity to your compliance scope. Third-party risk assessments, BAAs, DPAs, and security questionnaires take time and introduce ongoing obligations.
Infrastructure metadata exposure. Even if credentials are well-protected, query results — instance names, database identifiers, network topology, resource tags — reflect sensitive architectural decisions. In a SaaS tool, those results transit through vendor servers and may be logged or retained.
None of this means SaaS tools are poorly built. Many have strong security programs. The risk is structural, not a reflection of any vendor's intent. The question is whether there is a better model.
What "Native App" Actually Means for Security
The term gets used loosely. Here is what it means in concrete security terms.
A web app routes your actions through the vendor's servers. When you enter AWS credentials into a SaaS dashboard, they travel to the vendor's backend, which then calls AWS on your behalf. The vendor sits between you and your cloud provider.
A native desktop app runs on your machine. Credentials are stored locally — in the OS keychain (macOS Keychain, Windows Credential Manager, or equivalent) or locally encrypted storage. API calls originate from your machine directly to the cloud provider. The vendor is not in the path.
This is the same model used by the AWS CLI, kubectl, the Google Cloud SDK, and HashiCorp Vault CLI — tools the security community has trusted for years because they do not send credentials to a third party.
Clanker Cloud follows the same AWS credential chain patterns: environment variables, ~/.aws/credentials, IAM instance profiles, or OS keychain. No Clanker Cloud server ever receives those credentials.
Clanker Cloud's Architecture in Detail
Here is exactly what happens when a user makes a query:
Step 1: User input. You type a question — "Show me all EC2 instances in us-east-1 with public IPs." The desktop application processes it locally.
Step 2: Local AI inference (optional). If you are using Gemma 4 via Ollama or Hermes, the natural language is parsed and converted into structured tool calls entirely on your machine. No text is sent to an external AI API. If you have configured Claude Code or Codex, the request goes directly from your machine to Anthropic or OpenAI — not through Clanker Cloud's servers.
Step 3: Direct API call. The desktop app constructs the AWS SDK call (or GCP, Kubernetes, etc.) and sends it directly from your machine to the cloud provider's endpoint. Clanker Cloud's servers are not in the network path.
Step 4: Local result processing. The API response is returned to your desktop application and displayed locally. It is never transmitted to Clanker Cloud's backend or logged on a vendor server.
Step 5: Local audit trail. The query, result, and any change record are written to local storage on your machine.
At no point does any data — credentials, query parameters, API results, or audit logs — transit through Clanker Cloud's infrastructure. The app's outbound network activity is limited to your cloud provider API endpoints, AI provider APIs if you have configured cloud-hosted models, and standard update checks. You can verify this with any network traffic analyzer.
The Five Core Security Properties
1. Credentials Never Leave the Machine
Cloud provider credentials — IAM access keys, service account JSON files, kubeconfig tokens — are stored in local encrypted storage or the OS keychain. Clanker Cloud does not transmit them to any backend server. The credential store is on your machine, under your control, subject to your disk encryption and access controls.
If Clanker Cloud were breached tomorrow, there would be no credential database to exfiltrate. Each installation is isolated. The blast radius of any hypothetical vendor compromise is zero for stored credentials.
2. Query Results Never Leave the Machine
When Clanker Cloud queries your cloud accounts, the results are processed and displayed locally. Infrastructure metadata — your VPC layout, your RDS instance identifiers, your Kubernetes namespace structure — stays on your machine. This matters for teams that classify infrastructure topology as sensitive, for regulated environments where infra data may be considered sensitive under data classification policies, and for any team that prefers not to give a third party a map of their production environment.
3. No Central Breach Surface
SaaS cloud management tools, by their nature, aggregate credentials and infrastructure access for thousands of customers in a centralized system. That centralization creates an attractive target. A compromise of that system — through a supply chain attack, an insider threat, or a direct breach — can expose all customers simultaneously.
With a native app, there is no central credential store. Every installation is independent. An attacker who compromised Clanker Cloud's update servers would not gain access to any customer's cloud credentials, because those credentials are never on Clanker Cloud's servers to begin with.
4. Local AI Inference Available
Clanker Cloud supports BYOK local model inference via Ollama. Gemma 4 and Hermes run locally. AI inference for infrastructure queries — natural language understanding and tool selection — runs entirely on your hardware. No query text, infrastructure data, or model outputs are sent to any external AI API.
This is the right default for teams with data residency requirements or AI governance policies that require knowing where inference occurs. If you prefer cloud-hosted models, Clanker Cloud supports Claude Code and Codex. Those requests go directly from your machine to Anthropic or OpenAI — not through Clanker Cloud's servers.
5. MCP Server Runs Locally
Clanker Cloud includes a Model Context Protocol endpoint that allows agents — including Claude Code and OpenClaw — to interact with your infrastructure. That MCP server runs locally. Agent connections are via stdio or localhost and do not traverse the public internet. Infrastructure data returned by MCP tool calls never leaves your machine through Clanker Cloud's infrastructure.
You can build agentic workflows — automated remediation, deployment pipelines, drift detection — without routing data through a third-party cloud service.
What This Means for Compliance
Local-first architecture has direct implications for the compliance frameworks engineering and security teams encounter in practice.
GDPR. Infrastructure metadata can contain personal data — user identifiers in resource tags, IP addresses, employee emails in IAM records. When processed locally, Clanker Cloud is not acting as a data processor. You are. That eliminates the need for a Data Processing Agreement with Clanker Cloud and reduces your third-party processor inventory.
HIPAA. ePHI must not leave controlled environments without appropriate safeguards and Business Associate Agreements. For healthcare teams, local-first processing means infrastructure metadata related to ePHI workloads stays within your controlled systems. Clanker Cloud does not require a BAA for its core functions because it does not receive, store, or transmit your infrastructure data.
SOC 2. Infrastructure metadata — configurations, access logs, network topology — is often in scope for SOC 2 audits under the Availability and Confidentiality criteria. Keeping that data local reduces the number of third-party vendors auditors need to assess and simplifies evidence collection.
FedRAMP. Local processing by a native desktop app is architecturally compatible with environments where cloud-hosted SaaS tools may not be approved. Clanker Cloud's network traffic is limited to known, auditable endpoints — your cloud provider APIs — rather than undisclosed vendor infrastructure.
For Enterprise Security Teams
The security review process for a native desktop app is meaningfully simpler than reviewing a SaaS tool.
A SaaS review typically involves: the vendor's SOC 2 report, credential storage and encryption practices, data retention policies, breach response history, a vendor security questionnaire, and data processing agreements. That process takes weeks and creates ongoing obligations.
For Clanker Cloud, the review centers on the application itself. The questions to answer are:
- Does the app store credentials securely? Yes — OS keychain or locally encrypted storage, same model as AWS CLI and kubectl.
- Does the app make unexpected network calls? No — traffic is limited to cloud provider API endpoints and, if configured, AI provider APIs. Verifiable with a network analyzer.
- Does the app transmit infrastructure data externally? No — results are processed and stored locally.
- What is the update mechanism? Standard application updates, verifiable through code signing.
You are reviewing an application, not trusting a vendor's cloud environment. Clanker Cloud's traffic can be captured and analyzed at the network layer. You will see API calls to AWS, GCP, or Kubernetes endpoints and nothing else. The absence of traffic to *.clankercloud.ai during normal operation is itself the evidence.
For Startups Building Toward Compliance
Not every team reading this is in a regulated industry today. Many will pursue SOC 2 Type II, HIPAA certification, or enterprise sales within the next 12 to 24 months.
One of the most common findings in pre-audit assessments is excessive third-party access — vendors with standing access to production credentials that were added quickly and never revisited. Choosing local-first tools by default is not about paranoia. It is about not creating access you will later need to revoke, audit, and explain.
Every SaaS vendor with access to your cloud credentials is a vendor whose security questionnaire you will eventually complete, whose contract you will review, and whose access you will justify to an auditor or an enterprise customer's security team. Clanker Cloud's Beta tier is free. The cost of starting with a local-first architecture is zero. The cost of unwinding credential access granted to half a dozen SaaS vendors during a compliance audit is not.
FAQ
Are my AWS credentials safe with Clanker Cloud?
Yes. Credentials are stored in your OS keychain or locally encrypted storage, using the same mechanisms as the AWS CLI. They are never transmitted to Clanker Cloud's servers. Run a network traffic capture to verify — you will see no outbound calls to Clanker Cloud infrastructure.
Does Clanker Cloud store my cloud credentials on its servers?
No. There is no Clanker Cloud credential vault. Credentials are stored on your machine with no network transmission during setup or use. See the security documentation for implementation details.
What is a local-first cloud management tool?
One where credential storage, query processing, and result handling all occur on the user's machine rather than on vendor servers. The tool connects directly from your machine to cloud provider APIs without routing data through a third-party backend, eliminating the vendor as a breach surface for credentials and infrastructure metadata.
How does Clanker Cloud handle GDPR and HIPAA compliance?
Because infrastructure data is processed locally, Clanker Cloud is not acting as a data processor under GDPR for your infrastructure operations, and does not require a DPA. For HIPAA, local processing means ePHI-adjacent infrastructure metadata stays within your controlled environment, and no BAA is required for core functions. Review the compliance documentation and consult your compliance officer for your specific requirements.
Get Started with Clanker Cloud
Clanker Cloud is available now. Beta is free. Lite is $5/month. Pro is $20/month. Enterprise pricing is available for teams requiring custom deployment, SSO, or audit support.
- Create an account — no credit card required for Beta and Lite
- Read the documentation — including the security architecture reference
- See a live demo — watch the local query flow in action
- Review the FAQ — common questions about the native app model
If you are a security engineer evaluating Clanker Cloud, the technical documentation covers credential storage implementation, network traffic profile, and local model inference configuration. The architecture is designed to be auditable.
Run a local security and drift review
Use Clanker Cloud to inspect live cloud and Kubernetes state with local credentials, then review findings before any infrastructure change runs.