Security & architecture

How AMBA is built and how it handles your data, for security, privacy and procurement reviewers. The Privacy policy lists every data flow in full; the Terms of service cover use of the software. Questions and security reports: [email protected].

At a glance

• 💻 Local-first. Your files, the app database and run history stay on your computer.
• 🔑 Your provider, your key. Model requests go straight from your computer to the AI provider you chose. AMBA's servers are not in that path. With an AMBA account, requests pass through AMBA's gateway, which stores no content.
• 📝 Text by default. Requests carry only the excerpts a task needs. A PDF page your computer cannot read goes to the AI only under the consent rules below.
• 📋 Every outbound request is logged on your device, with destination, size and what was masked, never the content.
• 🗝️ Keys live in the OS keychain and nowhere else.
• ✍️ Signed releases for macOS, Windows and Linux; updates are verified before they install.
• 🚫 No shell runner. AMBA never runs operating system commands for an agent.

Local-first architecture

AMBA is a native desktop app built with Tauri 2. One process holds the agent runtime, written in Rust; the interface (Vue) only shows results and passes on what you ask. There are no background servers, local web services or helper runtimes.

• Projects are folders on your disk. Source files are kept exactly as they arrived; agents can read them but never change them.
• The model reasons; the runtime acts. The model proposes tool calls; the runtime runs them through a fixed set of file, table, PDF and Office tools. A policy engine checks every call, and every path is confined to the project folder.
• Computation is deterministic. Totals, matches and formulas are computed with SQL and a workbook formula engine, not by the model.
• Model-written code is sandboxed. For Office documents only, model-written code may run in a WebAssembly sandbox with no network, file system or system access. The runtime checks its output before anything is written.
• Local storage. Projects, conversations and run history live in a local SQLite database; run events are redacted before they are stored.

Model providers

With your own key, you choose the provider and supply the key. Requests go straight from your computer to that provider's API; nothing passes through AMBA's servers, and AMBA does not use your data to train models.

Provider	Endpoint used from your computer
Anthropic	api.anthropic.com
OpenAI, Azure OpenAI	The provider's API endpoint
Google Gemini, Google Cloud (Gemini Enterprise Agent Platform, formerly Vertex AI)	The provider's API endpoint
Amazon Bedrock	Your AWS account and region (for Claude: the Mantle or InvokeModel endpoint)

What the provider keeps is governed by its API terms.

AMBA account

An AMBA account lets you use Claude without a key of your own. Its requests go over HTTPS to AMBA's gateway (gateway.ambadesk.com, on Cloudflare), which forwards them to Claude on Amazon Bedrock in the United States with AMBA's AWS credentials and streams the reply back as it arrives.

• No content stored. The gateway does not store or log request or response content.
• Usage counts only. Per request it keeps account, device, model, token counts, credits, status and time, to apply the plan's limits.
• Device token in the keychain. The token stays in the OS keychain; the gateway stores only its hash.
• Same safeguards. Masking and the data-flow log apply as with your own key; the log names the destination "AMBA gateway → Amazon Bedrock".
• Bypass it. To keep requests only between you and your provider, use your own key instead.

What leaves your device, and when

Flow	When	What is sent	Where
AI requests	You run a task, or a process step runs	Your request, the conversation and the excerpts or tool results it needs, as text	Your provider, or with an AMBA account AMBA's gateway → Amazon Bedrock
Hard PDF pages	No usable text and on-device recognition cannot read the page	Only those pages, once each	The project's provider
Model feature check	First use of a Claude profile in a new app version	Four short synthetic requests, no user content	That provider
Web search, connected services	Only when you turn them on	The queries, files or messages that feature needs	That service
Update checks, catalog	At launch (if enabled) and on demand	App version, operating system, architecture	api.ambadesk.com, r2.ambadesk.com (Cloudflare)
Feedback, crash reports	Only when you send them or agree to	A redacted report	AMBA's feedback service (Cloudflare)

Consent and masking

• Identifier masking per project: off (default), mask identifiers, or strict. E-mails, phone numbers, ID and tax numbers, bank accounts, card numbers and terms you list are replaced with placeholders before a request leaves, and restored on your device. The mapping lives in memory for the run only. Detection is pattern-based, not exhaustive.
• Page images need consent. They cannot be masked, so with masking on AMBA asks once per project before a hard PDF page goes to the AI. Unattended runs never ask; without consent they read on the device or report the page as unreadable.
• Text recognition runs on your computer first, with the operating system's own engine.

The data-flow log

Each project's Data leaving this device view lists every outbound request: purpose, destination, region, size, tokens and masked counts, never the content. Export it into reports/compliance/ as evidence. The log stays on your device for 365 days.

Product screenshot

Credentials

API keys and connector credentials live only in the OS credential store: macOS Keychain, Windows Credential Manager or the Linux Secret Service. Never in plain text on disk, in the database, logs, backups or browser storage, and there is no fallback store. AMBA reads a key back after saving it, the interface never receives a saved key, and each key goes only to its own provider.

Signed updates

Every release package is signed with AMBA's release key, and the app verifies the signature before it installs an update. macOS builds are also signed with an Apple Developer ID and notarized. Releases are served from api.ambadesk.com and r2.ambadesk.com and checked end to end after publishing.

No shell runner

AMBA has no way to run operating system commands for an agent, in any project or setting. Agents act only through AMBA's own tools. Agent packages are data (instructions and settings), validated before use, and never executed. The app's web view runs under a strict content security policy, and displayed HTML is sanitised.

Related

• Privacy policy: every data flow, retention and your choices.
• Terms of service.
• Security in the user manual.