Agent RemoteAccount security
- You can sign in with an email address and password, or with Google or Apple. An account has no password at all when you only ever use a provider — there is nothing to leak in that case.
- Passwords, where you set one, are hashed (bcrypt); we never store them in plaintext.
- Sign-in is timing-safe and returns generic errors (no account enumeration).
- From Google or Apple we receive an identifier, your email address and — once, if you allow it — your name. We do not ask for, receive or keep any other data from your account there, and we store no access or refresh token for it.
- A social identity is joined to an existing account of yours only when the provider confirms it has verified that email address. If it has not, we refuse rather than link — otherwise anyone able to set an address at a careless provider could reach your account.
- Apple's Hide My Email relay addresses work normally; we treat them like any other address.
- We email a link to confirm your address. It is single-use, expires, and only its hash is stored — a copy of our database contains no usable links. An invalid, expired and already-used link are answered identically, so a stranger holding one learns nothing from us.
- Sessions are signed; you can delete your account and data at any time.
Tokens
- Team invite tokens and server-link tokens are stored only as SHA-256 hashes; the raw value is shown once.
- The entitlement API authenticates a linked server by its hashed token; a database leak exposes no usable tokens.
Billing
- Card data never touches our servers — the payment provider handles it.
- Subscription state is written only by verified provider webhooks (Stripe signature / Paddle signature), each deduplicated by event id; clients cannot assert a plan.
- That deduplication ledger keeps the event reference, its kind and its timestamps — and never the provider's message body, which carries the customer's name, billing address and card country. Rows are deleted after 180 days.
- Paddle is the merchant of record for new subscriptions — it is the seller, issues the invoice, and collects any VAT due.
Your machine
The Agent Remote software runs on your own hardware. This cloud service manages your account, team and plan, and — only if you enable push notifications — relays a minimal attention signal to your phone: a session id, the event kind, a label you chose for the computer, and your device token. It never receives your terminal content; the relay accepts those four fields and rejects anything else rather than forwarding it, so that stays true regardless of what a future client tries to send. The self-hosted tier keeps working even if this service is unreachable.
Crash reports and update checks
A crash report and an update check leave your machine on their own, and both are narrow. On a machine whose settings an administrator applied there is a third, covered below. The desktop app sends a crash report after a crash — the error, the version, the platform, and a diagnostic line with credentials stripped out locally before sending; if that stripping cannot be completed the report is discarded rather than sent. A report carries no code, terminal output, screen contents or files, and is not linked to your account, your team or your email. It is not completely untraceable, though: we keep a scrambled fingerprint of the network address it arrived from, so one machine cannot flood us with reports — never the address itself. You can switch this off in Config, and the app says so on first run. Crash reports are deleted after 90 days.
A fingerprint is a pseudonym rather than anonymity. We cannot turn one back into an address, and each store keeps its own separate kind — one address produces a different fingerprint for a crash report than for a support case, so these records cannot be matched up to each other. Within one store the same address repeats, which is what makes a flood limit possible.
The app also checks for updates at startup against a server we run, sending the version and platform it is asking about. Updates are never gated on payment: a lapsed account still receives security fixes. Update payloads are verified against a signing key held in the app before anything is written to disk.
Usage counts
We keep daily totals — linked computers that checked in, new and total links, update checks, phones notified, a per-country tally and a per-version/platform tally — and nothing else. They are computed from requests the software already makes, so no new data is collected from your machine to produce them, and the stored unit is a date and a number: no row describes an installation, a device or an account. For the country tally the address is resolved at request time and never written down. That applies to these tallies: the crash reports, support cases and administrator-settings reports each keep a scrambled fingerprint of the address they arrived from, and each section below says so.
Support cases and feedback
A support case or a piece of feedback sent from the app is the one thing here that you type and send deliberately — there is no automatic version of it and so nothing to switch off. A case carries your message, the app version and platform, and optionally the same diagnostics a crash report would, through the same redaction; never terminal output, session content, code or files.
Feedback carries less: the message and the email address you chose to give. No diagnostics are offered or attached, because an opinion is not a fault report.
It is also not anonymous, and only as far as you make it. The case is identified by a one-time code the app keeps so it can show you the status — we store only a hash of it, never the code. An email address is optional and typed per case; without one the case is filed and readable by you, with nowhere for us to reply. Signing in is never required. As with a crash report, we keep a scrambled fingerprint of the network address the case arrived from — never the address itself. Cases are deleted after 30 days without activity, sooner than crash reports, because a case can carry an email address you typed, which a crash report never does.
Settings applied by an administrator
This applies only if someone administers this software for you — a workplace, or a team you belong to. If you installed it yourself you are your own administrator, there are no applied settings to check, and nothing here ever happens on your computer.
Where an administrator has applied settings, your computer checks they are genuinely theirs before using them. If it cannot read them, or cannot confirm they are the ones your administrator applied, it stops rather than run with settings nobody chose — and it tells us, so your administrator can be told. The settings that work this way are the ones that decide what a device may reach and what is recorded; the rest stay yours whoever administers the software.
If those settings have simply expired rather than been altered, none of that happens: your computer goes back to using its own settings, carries on, and sends nothing.
That report is sent automatically and you cannot turn it off.It is the only thing on this page with no switch. Turning it off is exactly what someone bypassing their administrator's settings would do, so the report is not a by-product of the check — it is the check. The app tells you on screen that it was sent.
The report says which of the two failures it was, and carries a reference for the settings being checked so your administrator can match it to what they applied. It identifies the computer and the team it belongs to, and carries the app version, your operating system and processor architecture. We also keep a scrambled fingerprint of the network address it arrived from — never the address itself — only to stop one computer flooding us with reports.
It is not anonymous. Along with a support case, it is one of the two things here that names you — and unlike a support case, you did not choose to send it. It carries no terminal output, session content, code or files. If your computer cannot reach us it keeps the report and sends it the next time it can: disconnecting delays it, it does not prevent it. These reports are deleted after 30 days, sooner than crash reports, for the same reason support cases are.
Reporting
There is no published security contact yet. We are not able to receive vulnerability reports by email at this time, and would rather say so than list an address that goes nowhere. This page will name a real channel, and the response time we can actually hold to, before it asks anyone to use one.