Nightly early access. Nightly builds only for now.
Hexbot

Legal ยท Hexbot

Security Policy

Hexbot keeps your data on your own machine and keeps Connect out of the path your conversations take. This page explains the design in plain words and tells security researchers how to reach us.

Effective
25 September 2026
Last updated
6 October 2026

How Hexbot is built to be safe

Your bots, their memory, your files, and your provider keys live in ~/.hexbot on the machine that runs the daemon. The app is a window onto that daemon. The website and Connect are outside that boundary: they can help your devices find the daemon and prove who you are, but they cannot read what is inside.

Bots use real tools on your computer. In Manual and Auto mode, shell commands and code run in an operating-system sandbox with no internet access and no way to read credential files. Stepping outside it is checked first. Manual asks you. Auto has the bot's model review each step and asks you only about risky or unreviewable ones, so in Auto internet access and changes outside the workspace are a model's judgment, not containment: the step it reads is written by the bot and can carry instructions from a page or file the bot read. Choose Manual to see every such step. If no OS sandbox is available, shell commands need your approval even with full access, and model review cannot replace it. Bypass mode removes the sandbox and the prompts, so choose it only for a machine you can rebuild. Inside the sandbox the approach is the one Hermes Agent, which Hexbot is built on, and Codex take: the operating system, not the agent, is the security boundary. Run the daemon as a normal user, keep it updated, and read a skill or plugin before you install it.

How Connect protects your daemon

  • Not in the data path. Chat traffic goes from your device through Cloudflare's edge and the tunnel process on your daemon host; Connect's servers never carry it. TLS protects it as far as Cloudflare, which decrypts it at its edge to route it through the tunnel, so Cloudflare can read it. LAN pairing and Tailscale do not pass through Cloudflare.
  • Your daemon trusts only you. When a daemon registers, it records its owner and the keys Connect signs with. It accepts a Connect login only for that owner, for that daemon, signed with one of those keys. Where the tunnel leads is set on your machine, not by Connect.
  • Sign-in by Clerk. Passwords, passkeys, and social sign-in are handled by Clerk. Connect never sees a password.
  • Tokens are hashed. Daemon and app tokens are shown once and stored only as SHA-256 hashes. A database leak does not yield working credentials.
  • Grants are short-lived and single-use. A login grant is an ES256-signed token valid for five minutes, bound to one daemon, carrying an ID the daemon refuses to accept twice. The daemon verifies it against Connect's published keys and mints its own revocable device token.
  • Browser sign-in uses proof-key exchange. When you open a daemon in a browser, the daemon starts the sign-in with a PKCE challenge and a state cookie, Connect returns a one-time code to the daemon's own callback address only, and the daemon exchanges the code together with its verifier and its own token. A code seen in a URL or a log is useless on its own.
  • Every device is revocable. Apps and browsers signed in through Connect appear in the daemon's Devices list, and apps also appear on your Connect page. Revoking a daemon deletes its tunnel.
  • Defence in depth on the web. Connect and hexbot.app send a Content Security Policy, forbid framing, and send no referrer. Connect's API takes bearer tokens; the one exception is approving a daemon, which uses your Connect sign-in.
  • Open source. The Connect service, the daemon, and the app are AGPL-3.0 software in our repository, so anyone can review the design or run their own instance.

What the daemon does

The daemon listens on localhost until you turn on "Allow other devices". A first Headless installation enables LAN access so another computer can connect. Direct LAN HTTP does not encrypt sign-ins or chat; use a trusted LAN, Tailscale, or HTTPS, including Hex Connect. On a network, every connection needs a paired device token; pairing codes expire after ten minutes and work once. A daemon registered with Connect turns its authentication gate on regardless of how it is bound. Device tokens are revocable in Settings and with hexbot devices revoke.

Your part

  • Keep the machine that runs your daemon updated and behind a normal user account.
  • Revoke devices and daemons you no longer recognise, and use a passkey or a strong password with two-factor sign-in for your Connect account.
  • Only approve a registration code or an app authorisation you started yourself.
  • Treat provider keys as secrets. Hexbot stores them locally; never paste them into a chat.

Reporting a vulnerability

Please report security issues privately, either through GitHub Security Advisories or by email to lumora.studio@hotmail.com with "Security" in the subject. Do not open a public issue. A useful report names the component (the app, the daemon, Connect, or the website), the version or commit, steps to reproduce, and what an attacker gains. We do not run a bug bounty programme, but we credit reporters in release notes unless they ask us not to.

What is in scope

In scope: the Hexbot app and daemon code in backend/ and apps/, the Connect service at connect.hexbot.app, the hostnames it issues, and this website. That includes the core Hexbot inherited from Hermes Agent; if an issue also affects Hermes Agent, we will tell Nous Research. Out of scope: reports that require a daemon configured with authentication deliberately turned off, findings that only apply in Bypass mode (it has no sandbox by design, so a bot reading or changing anything there is expected behaviour), volumetric denial of service, and issues in third-party services such as Clerk or Cloudflare, which have their own programmes.

Safe harbour for researchers

If you research in good faith, avoid privacy violations, data destruction, and service disruption, only test against accounts and daemons you own, and give us a reasonable time to fix what you find before you talk about it, we will not pursue legal action against you for that research and will consider it authorised under the Terms of Service.

How we handle reports

We acknowledge reports within five working days and aim to fix confirmed vulnerabilities within 90 days, sooner for anything that exposes user data. We publish the fix in the release notes and, where it affects self-hosted instances, in a GitHub Security Advisory with upgrade steps. Coordinated disclosure ends 90 days after the report or when the fix ships, whichever comes first.

Changes

We may update this policy. The dates at the top tell you when.