AMBA
✓English
日本語
한국어
Tiếng Việt

English

日本語
한국어
Tiếng Việt

Appearance

🔒 AMBA Privacy Policy ​

Last Updated: October 30, 2026
Contact: [email protected]

AMBA is a local-first desktop application: your projects, files and analysis run on your own computer. AMBA is not a zero-network application, though. Some features send data over the internet — to the AI provider you choose, and to a small set of AMBA-operated cloud services (on Cloudflare) for feedback, crash reports, update checks, the agent catalog and, if you use an AMBA account, its model requests and web searches.

This page lists every one of those flows, what each one sends, and where it goes.

1. What stays on your device ​

  • Your project files: source files in Sources (sources/), and workpapers and deliverables in the rest of the project folder (for example workings/ and reports/), are read and written on your computer. AMBA does not upload whole files to AMBA servers.
  • App database: projects, conversations, run history, settings and a local copy of any feedback you submit are stored in a local SQLite database. Analytical tables created during processing live in your project folder, with AMBA's own project data (.amba/analytics.db). You can delete them at any time; the next analysis rebuilds them from your files.
  • Memory: the app database also keeps knowledge notes you save (or that an agent saves while working), and searchable excerpts of documents a connector delivers into a project. Each item belongs to one project — and to one agent unless it is shared with the project — and an agent never sees another project's memory. Your conversations are not copied into memory. On upgrade from an older version, conversations that earlier versions had copied into memory are exported once to ~/.amba/exports/memory-<date>/ (with API keys, tokens and card numbers removed) and then deleted from memory; that folder stays on your device and you can delete it.
  • API keys and connector credentials: stored in your operating system's credential store (macOS Keychain, Windows Credential Manager, or the Secret Service API / libsecret on Linux). Release builds do not fall back to plaintext or database storage: if no keychain is available, the key is not saved. In addition, backups created by AMBA exclude secrets. A key is only ever sent to the provider it belongs to.
  • Crash files: if AMBA crashes, a redacted crash report is written locally to ~/.amba/last_crash.json. It stays on your device unless you agree to send it (see section 2).
  • Scanned files and images: text in scanned PDFs and in images (PNG, JPG, TIFF …) is recognised on your computer with the operating system's text recognition (Apple Vision on macOS; Windows' built-in recognition on Windows where the language is installed), and the result is cached in the project's workings/.cache/ocr/ folder. Images are not sent to the AI provider or to AMBA, with one exception: a PDF page that your computer cannot read at all (no usable text and no reliable on-device recognition) can be read by the project's AI provider — see AI reading of hard PDF pages in section 2. That happens only for those pages and, when identifier masking is on, only after you allow it for the project. Otherwise only recognised text can reach the model, as part of the file excerpts in section 2, and identifier masking applies to it. Where no recognition is available (Linux), an unreadable page is reported to the agent instead of being sent anywhere.
  • No analytics or ad tracking: AMBA has no advertising identifiers, tracking pixels or usage analytics that record which files you open or which prompts you run.

2. What leaves your device and when ​

AI requests (your own key, BYOK) ​

  • Trigger: You run a task with a provider you configured
  • Data sent: Your prompt, conversation history, and the file excerpts or tool results the task needs, as text only (page images are sent only for AI reading of hard PDF pages below)
  • Destination: Directly from your computer to the provider you chose (e.g. Anthropic, OpenAI, Google, or a cloud platform: Amazon Bedrock, Google Cloud, Azure OpenAI)
  • Retention: Governed by that provider's API terms; AMBA receives nothing

AI requests with an AMBA account ​

  • Trigger: You connect an AMBA account (invite code) and run a task on one of its models
  • Data sent: The same as for your own key: your prompt, conversation history and the file excerpts or tool results the task needs, plus this device's account token and the task's run id (for the per-task usage limit). When you connect, the app sends the invite code and a device name ("AMBA Desktop" and your operating system unless you enter another)
  • Destination: AMBA's gateway (gateway.ambadesk.com, on Cloudflare), which forwards the request to Claude on Amazon Bedrock in the United States (the us-east-1 endpoint; AWS may serve a request from another US region through its cross-region inference)
  • Retention: The gateway does not store or log request or response content. For each request it keeps a usage record (account, device, model, token counts, cost in credits, status, duration and time) to apply your plan's limits; these records are not deleted automatically yet, and you can ask us to delete them (section 5). The account holds only the name AMBA gave it, its plan and expiry, and each device's name and last-used time: no email address or password. Invite codes and device tokens are stored only as hashes, and a salted hash of your IP address limits invite-code attempts. Neither AMBA nor Anthropic uses your requests to train models; what Amazon Bedrock keeps is governed by AWS's terms for AMBA's account. To keep requests only between you and your provider, use your own key instead

Web search with an AMBA account ​

  • Trigger: An agent searches the web in a project that allows it, you are signed in with an AMBA account that has web search turned on, and you have not entered your own Tavily or Brave Search key (your own key is always used first)
  • Data sent: The search words the agent chose (at most 400 characters), how many results to return and, if set, news only or a time range, plus this device's account token and the task's run id. No files are sent
  • Destination: AMBA's gateway (gateway.ambadesk.com, on Cloudflare), which sends the search to Tavily (United States) with a Tavily key managed by AMBA; the results come back the same way
  • Retention: The gateway does not store or log the search words or the results, and keeps no cache. For each search it keeps a usage record (account, device, "web search", a cost of 1 credit, status, duration and time), as for a model request. Tavily processes the search for AMBA and, under its terms, may keep searches and results and use them to improve its services, including to train AI models. To keep your searches off AMBA's Tavily keys, enter your own Tavily or Brave Search key, or leave web search off

AI reading of hard PDF pages ​

  • Trigger: An agent reads a PDF page your computer could not read (no usable text layer, and on-device recognition unavailable or unsure). With identifier masking on: only after you answer Allow to the one question per project ("Allow AMBA to have AI read the hard PDF pages in this project?"); with masking off: automatically
  • Data sent: Only those pages — as a PDF holding just those pages (Anthropic, Claude in Amazon Bedrock) or one image per page (OpenAI, Azure OpenAI) — plus a fixed instruction. Page content cannot be masked. The file name and project are not sent
  • Destination: Directly from your computer to the project's AI provider with your own key (Claude Haiku 5.5 on Anthropic and Amazon Bedrock; the project's own model on OpenAI and Azure OpenAI); never to AMBA
  • Retention: Governed by that provider's API terms. The text that comes back is cached on your computer in workings/.cache/ocr/, so each page is sent at most once; each request is listed under Data leaving this device as vision_ocr (provider, model, file, page count, size and tokens — never content)

Feedback ​

  • Trigger: You press Send in the Feedback dialog
  • Data sent: Your title, message and steps (after automatic redaction of user folder paths, email addresses, phone numbers, national ID numbers, and API keys, tokens, passwords and private keys), category, rating, optional contact address (sent as a separate field, not inside the message), optional run context (playbook, mode, model, failed tool, error text), app version, OS and architecture, and window size if diagnostics are enabled
  • Destination: AMBA's Cloudflare Worker → stored in Cloudflare D1; may open an issue in AMBA's GitHub issue tracker (containing the message, steps, diagnostics and stack trace — never your contact address); a short alert (title, category, OS, version) is sent to the team's Telegram/Discord channel. Your contact address is stored only in D1
  • Retention: Deleted automatically 180 days after the issue is marked resolved or closed, and in any case 365 days after submission. GitHub issues are kept as part of the public project history. A salted hash of your IP address is used for rate limiting and pruned after about 2 days

Crash reports ​

  • Trigger: Only with your consent. On the next launch after a crash, AMBA shows what would be sent and asks: Send, Don't send, or Always send. You can change this any time in Settings → Vault & Security → Crash reports (Ask / Always send / Never)
  • Data sent: Panic message, code location and stack trace (after the same redaction), app version, OS and architecture. After an unexpected exit without a recorded error (for example a crash inside the system web view), only the app version, OS, architecture and the time the session started. No contact details; file contents and prompts are not intentionally included, though a panic message can quote the value that caused the crash
  • Destination: Same as Feedback (D1, GitHub issue, Telegram/Discord alert)
  • Retention: Same as Feedback. The local last_crash.json is deleted after you send or decline it

Update checks ​

  • Trigger: On app launch (if automatic checks are on) and when you click "Check for updates"
  • Data sent: Current app version, OS target and CPU architecture; your IP address is visible to Cloudflare as with any web request
  • Destination: api.ambadesk.com/v1/update/… (Cloudflare); update packages download from r2.ambadesk.com (Cloudflare R2)
  • Retention: AMBA does not store update-check requests. Cloudflare may keep standard request logs

Agent catalog ​

  • Trigger: When you open or refresh the template catalog and no cached copy is used
  • Data sent: A plain download request; no project data or identifiers are sent
  • Destination: r2.ambadesk.com (Cloudflare R2)
  • Retention: Not stored by AMBA. Cloudflare may keep standard request logs

Services you connect ​

  • Trigger: Only when you enable them: web search with your own Tavily or Brave Search key, Google Drive, Telegram, MCP servers
  • Data sent: The queries, files or messages needed for that integration, using your own account or key
  • Destination: Directly from your computer to that service
  • Retention: Governed by that service's terms

Processes and "Send me a test". Messages a process sends (reminders, questions, reports) go through your own Telegram bot, directly from your computer to Telegram, only to the chats listed when you turned the process on. When you test a process step by step, nothing is sent unless you press Send me a test: that sends one copy of the message, labelled [Test], directly from your computer to Telegram through your own bot, and only to your own chat — never to your team. It is recorded in Data leaving this device with the purpose process_test and is not counted as a run.

AMBA does not use your documents, prompts or feedback to train AI models.

3. Third-party processors ​

ProcessorRole
Cloudflare (Workers, D1, R2)Hosts api.ambadesk.com, r2.ambadesk.com and the AMBA account gateway gateway.ambadesk.com; stores feedback, crash reports, AMBA account and usage records (never request content) and hashed-IP rate limits; serves updates and the catalog; sees your IP address for these requests
Amazon Web Services (Amazon Bedrock)Runs Claude for requests made with an AMBA account, under AMBA's AWS account
TavilyRuns web searches made with an AMBA account when you have no search key of your own, with a Tavily key managed by AMBA; may keep and use searches under its terms
GitHubHosts the issue tracker where feedback and crash reports may be filed
Telegram / DiscordReceive short internal alerts about new or recurring reports
The AI provider you chooseProcesses your requests when you use your own API key; AMBA is not in that path

4. Your choices ​

  • Use your own API key (BYOK): once you configure a provider, requests go directly from your computer to that provider and do not pass through AMBA's servers.
  • AMBA account: optional. Sign out on the account card disconnects this device and deletes its token from your keychain.
  • Free trial (removed): earlier versions relayed a few trial runs through AMBA to Google Gemini. That trial no longer exists; the anonymous device counters it kept on Cloudflare are deleted after 90 days without use.
  • Don't submit feedback: feedback is only sent when you press Send. You can leave the contact field empty and turn off diagnostics. Avoid pasting confidential content into feedback — redaction is automatic but pattern-based, not exhaustive. After sending, AMBA shows the reference ID issued by the server (for example AMBA-FB-3F2A9C1B); if the server cannot be reached, it shows that the feedback was only saved on your device.
  • Automatic update checks: you can turn automatic update checks off in Settings; you can still check manually.
  • Crash reports: nothing is sent unless you agree. Choose Ask (default), Always send or Never in Settings → Vault & Security → Crash reports.
  • Review what left your device: each project's Project Configuration → Permissions & Security lists, under Data leaving this device, every outbound request (AI model calls, web searches, remote MCP servers, deliveries, feedback, crash reports, update checks) with destination, region, size and what was masked — never the content — and can export it as evidence into the project's reports/compliance/ folder. The log stays on your device and is kept for 365 days.
  • Mask identifiers before AI calls: in a project's Project Configuration → Permissions & Security you can turn on masking, which replaces emails, phone numbers, ID and tax numbers, bank accounts and terms you list (such as client names) with placeholders before a request goes to the AI model, and restores the real values on your device. It is off by default, pattern-based rather than exhaustive, and can reduce answer quality for tasks that need the exact values. Masking covers everything AMBA sends to the model as text. Page images cannot be masked, so with masking on, AI reading of hard PDF pages (section 2) happens only after you allow it for the project; you can change that answer at any time with Allow AI to read hard PDF pages, next to the masking setting.
  • Local data: you can delete projects, the local database and ~/.amba/ at any time.

5. Contact and deletion requests ​

To ask what we hold about you, or to have feedback, crash reports, trial data or AMBA account records deleted, email [email protected]. Include the reference ID shown after sending (for example AMBA-FB-3F2A9C1B), the contact address you used, or the approximate date and title of your feedback, so we can find the records. The same address handles security reports and other privacy questions.

6. Changes to this policy ​

We will update this page when AMBA's data flows change, and change the date at the top.

Last updated: October 30, 2026.