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.
- 📝 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
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, Vertex AI | The provider's API endpoint |
| Amazon Bedrock | Your AWS account and region (for Claude: the Mantle or InvokeModel endpoint) |
| OpenAI-compatible | The endpoint you enter (for example DeepSeek, OpenRouter, Groq, Together AI) |
| Local models (Ollama) | Your own computer; nothing leaves the device |
What the provider keeps is governed by its API terms.
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 |
| 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 screenshotCredentials
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.