Archived: Native App Security Architecture

Archived and superseded — July 14, 2026. This article no longer describes the current Clanker Cloud product or pricing. Hosted inference, sandboxes, voice, account-control-plane, and web-to-desktop relay features may send or temporarily process data through Clanker Cloud and its listed providers. Do not rely on the statements below that no data reaches Clanker, that no DPA or BAA is relevant, or that old Beta/Lite prices remain available. Use the current Security, Privacy, Subprocessor Register, and Pricing pages for procurement or data-handling decisions.

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: Mode-dependent result processing. The provider response returns to the desktop application. It can remain local with a local model, or selected evidence can be sent to the configured direct BYOK provider or a separately enabled hosted feature. The current Security and Subprocessor pages define those routes.

Step 5: Local audit trail. The query, result, and any change record are written to local storage on your machine.

Raw cloud-provider credentials stay in the normal desktop credential chain, but other data paths are mode-dependent. Account and security metadata use Clanker Cloud services; selected prompts and results can go to a direct BYOK provider; and hosted inference, sandboxes, voice, or enabled remote control use the providers listed in the current Subprocessor Register.

---

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 Result Routing Depends on the Selected Mode

When Clanker Cloud queries your cloud accounts, the raw provider call originates locally. Infrastructure evidence can remain local with local inference, but selected context can be sent to a configured cloud-model provider or hosted Clanker Cloud feature. Teams that classify topology as sensitive must select and contract the appropriate mode rather than infer the boundary from the desktop app alone.

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. The core MCP connection runs through authenticated stdio or localhost. Its local transport does not determine the model route: selected MCP results can still be sent to the configured cloud-model provider, while enabled hosted features and web remote control use their separately documented paths.

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. A local-only configuration may reduce vendor processing, but hosted features can make Clanker Cloud and its providers processors. A business controller must execute an applicable DPA before submitting personal data to hosted features.

HIPAA. Whether Clanker Cloud is a business associate depends on the actual service and data flow. Local-only processing can reduce vendor handling, but it does not remove the customer's HIPAA duties. Do not submit PHI to hosted features unless a BAA is executed and an approved protected environment is verified active; Standard is not that environment.

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.

Government controls. A local desktop path can help preserve an existing boundary, but it does not make Clanker Cloud FedRAMP-authorized or approved for a government system. Hosted processing requires the applicable contract, control schedule, approved providers, and a verified active protected or sovereign environment.

---

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.
• What network calls does the selected mode make? Verify cloud-provider, direct model-provider, account, hosted inference, sandbox, voice, and remote-relay routes against the current documentation.
• Does the app transmit infrastructure data externally? It can: selected results follow the configured model and hosted-feature paths.
• What is the update mechanism? Standard application updates, verifiable through code signing.

Review both the desktop application and every enabled service boundary. Network capture can validate a deployment, but account services and enabled hosted features legitimately communicate with Clanker Cloud and its listed providers.

---

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?

In the normal desktop provider workflow, raw AWS credentials stay in the local credential chain and are not transmitted to Clanker Cloud. Other account, model, hosted-feature, and update traffic can still use network services.

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?

No product label determines GDPR processor or HIPAA business-associate status. The answer depends on the enabled routes and submitted data. Hosted personal-data processing requires an executed DPA; hosted PHI processing requires a BAA plus an approved active protected environment. Review Security, Privacy, and the Subprocessor Register with qualified advisers.

---

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.