BE Hub

Privacy policy

Last updated 15 September 2026.

Who we are

Binary Elements runs BE Hub. This policy covers the hosted service: the console, the hub, and the agent talking to it. It is written for the Australian Privacy Principles. If you want a copy, a correction, or a complaint, write to csteam@binaryelements.com.

If you run your own hub, you are the controller of that copy. This page still describes what the software is built to store.

What we collect

From the person who signs up or is invited: name, work email, password hash (or a Google / Microsoft identity we never see the password of), organisation name, role, and sign-in metadata (time, IP, user agent). We store session cookies to keep you signed in. Billing is in US dollars.

From each enrolled machine: identity and hostname, operating system and agent version, hardware and disk facts, network facts (LAN, gateway, DNS, a reflected public IP), optional Wi-Fi and cellular readings, custom-check results, events the agent raises, and heartbeats on a short interval. Proxied devices (a firewall, an ESXi host, a router reached over SSH from another agent) send the same kind of facts through that proxy. Optional custom metrics: a technician can give a machine a heartbeat URL, and add a named metric (a number or a yes/no) that has its own URL; a command on that machine (a speedtest, a script) POSTs a status and a small payload to it.

From your people using the console: every tool call and its outcome, proposal approvals and rejections, script runs (the rendered command, with secrets redacted), patch jobs, remote-control session records, file-explorer paths (not file contents), notes, alert acknowledgements, and BE AI questions, traces and conclusions.

From billing: Stripe customer and subscription ids, seat quantity, invoices. We do not store the card number.

What we do not collect

  • Keystroke content from a remote-control session.
  • File contents in the audit trail (paths only).
  • Secrets stored in agent.json on the machine (they never appear in hello, get_checks or heartbeats).
  • A census of what a signed-in user is typing or which documents they have open. That is not an RMM’s job.

Why we collect it

To run the product you asked for: show the fleet, raise alerts, let a technician fix a machine, bill the right number of seats, and keep an audit trail of who did what. We also use it to stop abuse (lockouts after failed logins, tenant scoping) and to send the lifecycle mail you would expect (verify, welcome, trial ending, invoice problems).

We do not sell this data and we do not use it to advertise to the people who sit in front of the machines.

Who else sees it

Anthropic — when someone in your organisation starts a BE AI investigation. The model receives the question, trusted notes, and machine facts for that run.

Stripe — name, email and the organisation id, so they can charge the seat subscription and run packs.

Our email provider (Emailit or the provider configured on the hub) — to deliver verification, invites and lifecycle mail. Twilio — only if you set SMS or voice alert contacts.

Google or Microsoft — only if a person chooses Continue with Google or Continue with Microsoft. We receive the verified email and profile name they release; we do not get their password.

A Binary Elements superadmin can see organisations when you ask for support or when we have to operate the platform. They are people, not a script, and the same audit trail applies.

We will disclose data if the law requires it, and we will narrow that to what was asked for.

Remote control and recordings

A remote-control session is started by a signed-in technician. The picture is relayed through the hub for that session and the session itself is recorded and audited. There is no on-screen notice on the customer machine. Your organisation can switch the feature off. We do not keep keystroke content.

How long we keep it

Raw heartbeats default to fourteen days. Hourly rollups default to two years. Events and check-result history default to one year. Those windows are configurable on the hub.

The audit log is append-only on disk. The in-memory view is a ring of recent records; that is not the same as deleting the durable file.

BE AI runs are written to an append-only metering ledger once they finish. Account data stays until you cancel; after the hold period we delete the organisation. You can export from the billing page before that.

Your rights

Access and correction: the console is the live copy of your organisation, users, machines, notes and billing. Export is on the organisation billing page.

Deletion: decommission a machine to uninstall the agent and drop its row. Cancel the organisation to leave. Ask us at the address above if something remains that the console cannot remove.

Complaints: write to us first. If you are in Australia and we do not resolve it, you can take it to the Office of the Australian Information Commissioner.

Where it lives and how we protect it

The hosted hub is one container and one data volume. Data sits where that hub is deployed. Agents only dial out; we do not open inbound ports on customer machines.

Passwords are stored as scrypt hashes. Operator API keys are hashed. Tenant enrollment tokens are hashed. Sessions are HttpOnly cookies. Cross-tenant access is refused as 404, not 403. Self-update only installs binaries signed by an offline key we do not keep on the server.

No method is perfect. A stolen technician password plus a machine with allow_shell on is a stolen shell. Use unique passwords or Google / Microsoft sign-in, and turn on MFA when the hub offers it.

Children, changes

BE Hub is for businesses and IT teams. It is not for anyone under 16.

We will update this page when the product starts holding a new kind of data. The date at the top is the date that applies. Questions: csteam@binaryelements.com.