Network
Loopback only
Non-loopback MCP bind addresses are rejected. Optional bearer authentication protects against other local processes.
Security & release trust
Verify the boundary before you trust the browser.
Hronaut can hold authenticated website sessions and accept powerful browser commands. This page documents what is isolated, what remains trusted, and how to verify the exact release you install.
Source and implementation review: August 28, 2026
Web content
Sandboxed renderers
Website views use Chromium sandboxing, context isolation, disabled Node integration, and enabled web security.
Supply chain
Verifiable builds
Every published asset and the checksum manifest receive GitHub build-provenance attestations.
Start with authority
Every connected MCP client should be treated as trusted with the visible browser session.
A client can navigate, interact with pages, inspect bounded debugging data, trigger downloads, and attach a local file path it supplies. An authenticated tab can expose account data and actions. Hronaut adds visibility, pause controls, isolation, and redaction—not a data-loss-prevention boundary for an untrusted agent.
Local MCP boundary
Loopback is a network boundary, not authentication.
Enforced
Only a local listener
Hronaut defaults to 127.0.0.1 and refuses an MCP host outside loopback. Requests with an Origin header are accepted only from loopback origins, matching the MCP transport guidance against DNS rebinding.
Your decision
Authentication starts off
A new profile is intentionally easy to connect, so any process on the same computer can control it while authentication is off. Enable Require MCP authentication when local processes are not equally trusted; Hronaut creates an owner-only token file.
Review authentication behavior ↗Human control
Pause rejects new commands
The pause control beside MCP ready rejects new tool requests while the app, tabs, and sessions remain open. Pause before typing a password, approving MFA, or performing another sensitive manual action.
Use the safe login handoff →Protocol guidance
Local still needs hardening
The Streamable HTTP specification calls for Origin validation, localhost binding, and authentication. Hronaut implements the first two and makes bearer authentication an explicit profile setting.
Browser isolation
Remote pages stay inside hardened Chromium renderers.
Hronaut's website views explicitly set contextIsolation: true, nodeIntegration: false, sandbox: true, webSecurity: true, and allowRunningInsecureContent: false. Site permission requests pass through an app handler instead of Electron's permissive default.
Implementation
Inspect the view settings
The tab manager creates each website view with explicit security preferences rather than relying on defaults that may change.
Website view source ↗Implementation
Inspect permission handling
Hronaut asks before a site receives a permission, stores remembered decisions by exact HTTP(S) origin, and requires fresh consent for media and file-system requests.
Session permission source ↗Upstream baseline
Compare with Electron's checklist
Electron recommends disabling Node integration for remote content, enabling context isolation and sandboxing, keeping web security on, and handling session permissions.
Electron security checklist ↗Limits worth knowing
Workspaces isolate website state. They are not client authorization boundaries.
- Separate site storage: each non-Default workspace receives a persistent Electron partition for cookies, local storage, cache, service workers, and related browser state.
- Cooperative ownership: workspace IDs are visible identifiers, not secrets. Hronaut rejects cross-workspace tab IDs, but connected clients are still expected to operate only inside workspaces they created or intentionally reopened.
- Shared app records: bookmarks, visit history, download records, and remembered site-permission decisions are application-wide.
- Visible web authority: a trusted client may read page-visible authenticated data or perform actions available to the signed-in account.
- Local file authority: file upload can attach any absolute path supplied by a connected client. Connect only clients you trust with local file access.
Release provenance
Verify the file, not just the download page.
Initial Windows and macOS packages are not platform code-signed or Apple-notarized. SmartScreen or Gatekeeper may warn. Hronaut publishes SHA-256 hashes and GitHub artifact attestations so you can tie a downloaded file to the repository and release workflow.
- 1
Download from the public release
Use Hronaut's latest-release redirect or the GitHub release page. Download the platform file and
Open the latest Hronaut release →hashes.txtinto the same directory. - 2
Check the SHA-256 digest
sha256sum --check hashes.txt --ignore-missingOn macOS, compare
shasum -a 256 ./<downloaded-file>with the matching line inhashes.txt. - 3
Verify build provenance
gh attestation verify ./<downloaded-file> --repo hronaut/hronautRun the same command for
hashes.txt. GitHub's verification output identifies the source repository, workflow, and commit used to produce the subject. - 4
Review before overriding a warning
Confirm that the tag, commit, workflow, and checksum match what you intend to run. An attestation proves provenance, not that an artifact is vulnerability-free.
Audit trail
Primary sources, implementation, and disclosure.
- Hronaut technical reference — security, privacy, workspace, and MCP boundaries
- Hronaut security policy — supported versions and private reporting
- Electron — security recommendations for remote content
- Model Context Protocol — Streamable HTTP security guidance
- GitHub — what artifact attestations do and do not prove
Found a vulnerability? Follow the private reporting instructions in SECURITY.md. For reproducible non-sensitive defects, use GitHub Issues.
Make an informed decision
Inspect the source. Verify the release. Start with a low-risk account.
Use a dedicated workspace, enable MCP authentication where local processes are not equally trusted, and keep the pause control within reach.