Security & data residency
Last updated: September 5, 2026
This page answers the questions a security review asks about Argus: where data lives, who can read it, and what you can change. It is written from the code, not from a template, and it says what is not covered as plainly as what is. The Privacy Policy is the binding document; this page explains the mechanics behind it.
1. The short version
- Argus is a desktop application with a workspace database behind it. The browser sessions themselves — cookies, logged-in state, history — run and stay on your computer. What is stored in the database is the definition of your work: profiles and their fingerprint settings, proxies, cookie sets, datasets, automations and their run logs, schedules, projects.
- The database is a Supabase project in Ireland (eu-west-1) for every customer on Argus Cloud. Organisations can have a dedicated instance instead: their own project, in a region they choose, running the same schema, with nobody else in it (section 6).
- Workspace encryption seals the sensitive values — saved passwords, proxy credentials, cookie-set contents, mailbox credentials, connector keys, flagged dataset columns — on your device with a passphrase we never receive. Section 4 lists exactly what it does and does not cover.
- The application sends no telemetry: no crash reports, no analytics, no usage events. The only things it fetches from us are updates.
- AI features are bring-your-own-key. Prompts and completions travel from your machine to the provider you configured, under your account with them. We never see them and never store them.
2. What stays on your machine
These live in the application’s data folder on your computer and are never uploaded. Deleting the profile, or uninstalling the application and removing its data folder, removes them.
- The browsing state of every profile: the cookies inside the browser, local storage, IndexedDB, history, service workers and logged-in sessions. Each profile has its own directory, isolated from every other.
- The assistant’s conversations and the skills it saves.
- Screenshots an automation takes of the pages it visits, kept for 14 days.
- Mail contents. Connected mailboxes are read live over IMAP by the application on your machine; a message body is held in memory for a few minutes and never written to the database.
- Local API keys for the loopback HTTP API and the MCP server. The API listens on 127.0.0.1 only; there is no hosted endpoint.
- Your session token, stored through the operating system’s keychain.
3. What is stored in your workspace database
Everything you create in the application is written to the workspace database as soon as you save it. There is no local-only mode; this is what lets a workspace be shared with a team and reached from more than one machine. The database is scoped by row-level security so that each workspace’s rows are visible only to its members.
| Data | Notes |
|---|---|
| Profiles | Name, tags, folder, proxy assignment, and the full fingerprint configuration (user agent, screen, canvas and WebGL settings, time zone). Saved login details for a profile are covered by workspace encryption; the rest is not. |
| Proxies | Address, port and type, plus the exit location the application resolves when it checks a proxy: public IP, country, city, network, time zone, latency. Username and password are covered by workspace encryption; the endpoint and its resolved location are not. |
| Cookie sets | The cookies you import, and the ones the application saves from a running profile while it is open, so the same login can be restored on another machine. Contents are covered by workspace encryption; name, count and tags are not. |
| Datasets | Schema and rows. Individual text columns can be flagged for workspace encryption, at the cost of not being sortable or filterable. |
| Automations and scrapers | Steps, parameters and variables. A parameter marked secret is masked in run records but is stored as written in the definition; use workspace encryption’s connector storage or a profile’s saved login for credentials instead. |
| Run logs | The transcript and variables of each run, deleted after 14 days. Screenshots do not travel; they stay on the machine that took them. |
| Schedules, event triggers, notifications | As written, including a webhook trigger’s payload. |
| Projects and notes | The brief, rules, notes and runbooks the assistant keeps on a project. Stored in the database and cached on each machine. |
| Mail accounts and send ledger | Server settings for connected mailboxes; credentials and sign-in tokens under workspace encryption. A record of each message an automation sends: recipient and subject, never the body. |
| Connectors | Configuration of the services you connect, including API keys, sealed as one unit under workspace encryption. |
| Machines | The name, platform and application version of each computer you sign in from, so a scheduled run can be directed to one of them. |
| Account and billing | Email address, workspace membership, plan and payment history. Card details never reach us. |
4. Workspace encryption
Optional, per workspace, turned on by the owner under Settings → Encryption. A random data key is generated on your device and wrapped with a key derived from a passphrase you choose (PBKDF2-SHA256, 600,000 iterations). Values are sealed with AES-256-GCM before they are sent. The passphrase is never transmitted and never stored; the server holds the wrapped key and ciphertext, and cannot open either. Every member of the workspace uses the same passphrase, shared the way your team already shares secrets.
Covered: a profile’s saved email, password and login URL; proxy username and password; the contents of cookie sets, including the uploaded file; mailbox passwords and sign-in tokens; the whole configuration of every connector; dataset columns you flag; the workspace’s Telegram bot token.
Not covered, stored as written: fingerprint configuration; profile, proxy and cookie-set names and tags; proxy endpoints and their resolved exit location; automation steps, parameters and variables; run logs; project notes; dataset columns you did not flag; the recipients and subjects of sent mail; machine names.
Limits worth knowing before a review: there is one passphrase per workspace, not per person, and there is no recovery — losing it means losing the sealed values. It protects against disclosure on the server side (a database dump, a leaked key, a legal demand made to us), not against someone who controls your computer while the workspace is unlocked. A workspace export is written in the clear, deliberately, because the file is the point of exporting.
5. Third parties
Two kinds, and the distinction matters for a questionnaire. The processors we use are listed, with regions, in section 4 of the Privacy Policy: the database provider, the website host, the installer mirror, the payment providers, transactional email, optional Google and Microsoft sign-in, the IP-geolocation services that resolve where a proxy exits, and the page reader a workflow’s “reach” step can call. We tell you before adding one.
The services you connect — model providers, Slack or Telegram, spreadsheets and databases, captcha solvers, proxy vendors — are yours. The application calls them directly from your machine with keys you supplied; we are not in the path and see nothing of what passes. For AI in particular this means prompts, pages and completions never touch our infrastructure.
6. Dedicated instances
For organisations that need their workspace held apart from every other customer, or in a specific region, we provision a dedicated instance: a Supabase project of its own, in the region you choose, running exactly the schema Argus Cloud runs, operated by us. Every team member’s launcher is pointed at it with a link we send; from then on nothing that workspace does touches the shared database. The application shows which server it is on at sign-in and in Settings.
What changes on a dedicated instance: billing is by contract rather than by card; workspace invitations are delivered as links rather than by email; and the instance is administered from its own database console rather than our website. What does not change: the application, its updates, workspace encryption, and every feature. The same mechanism also works against a Supabase project you host yourself; ask us if that is a requirement.
To discuss one, write to support@simnetiq.store with the region you need and roughly how many people will use it.
7. Access, retention and deletion
- Our staff reach customer data only through internal administration pages, which read the database with a privileged connection that bypasses row-level security. The Privacy Policy says so in section 9, and says what those pages are used for. They cannot read anything under workspace encryption.
- Retention: run logs 14 days; profiles in Trash 30 days; account and workspace data for as long as the account exists and for up to 30 days after a deletion request; payment and acceptance records for the six years UK law requires.
- Deletion is by request and handled by hand, so a shared workspace is never left without an owner. We act within 30 days and confirm.
- Export: the application can write a passphrase-encrypted backup of a whole workspace to a file or to your own Google Drive, and restore it into another workspace.
8. Reporting a vulnerability
Write to support@simnetiq.store with what you found and how to reproduce it. We answer within two working days, fix what is confirmed, and will credit you if you want to be credited. Please do not test against other customers’ workspaces.