What does the container boundary protect?
The managed computer uses separate browser and shell containers, non-root processes, dropped capabilities, resource limits, a read-only root filesystem, and a seccomp profile. It has no Docker socket, host network, or published sandbox ports. The separate shell-tool container sees its workspace and does not mount the browser profile.
The host daemon owns the vault, policy, audit, and task database. Its default listener is loopback at 127.0.0.1:7777. Remote access should use SSH or a private network such as Tailscale. Hosting this informational website does not make it a place to host the daemon.
Sandbox egress uses a proxy with destination policy and private-address blocking. It does not decrypt TLS, and domain policy remains best effort. Container or runtime vulnerabilities, permissions you add, and misuse of an already-signed-in website session are outside a guarantee of containment.
Does BotHearth ask before every action?
No. Review prompts are off by default. A task runs on its own and pauses when a human is needed: password, OTP, passkey, CAPTCHA, or a payment-card field, via Take control. Optional Settings → Sensitive actions → Ask before sensitive actions reviews detected sends, checkout steps, uploads, deletes and new-site form submits through BotHearth’s browser tools. Payment-card fields always pause for Take control; only checkout steps without a card field are optional. Expand the section to choose which gates fire, and to set API-adapter max tool calls and spend cap (0 = no limit); native Codex and Claude Code tasks have no BotHearth cap. Native CLI shell and network tools do not pass through those MCP action checks. Strict mode also restricts destinations. Classification relies on observed signals and cannot identify every possible effect.
The model's MCP token cannot approve its own requests, create computers, acquire operator control, or open the operator's live view. UI sessions use a separate operator credential. Approval decisions are checked at the daemon boundary and bound to the task, proposed action, destination, control epoch, and expiry.
Webpages, downloads, documents, and tool descriptions can contain prompt injection. Even an approved website may serve malicious instructions. Review previews and outputs, use dedicated test accounts, and stay present for sensitive tasks. A local approval never overrides website terms or someone else's data rights.
Can the model see a password during human control?
Before human control is acknowledged, guest model processes and their tool children are frozen, and MCP computer actions and capture are blocked. The full operator desktop stays usable. Live frames and input go only to the operator path, never to model results or BotHearth task/audit records.
The daemon transports your input, and the destination website receives it. If you paste a secret into chat, the model can receive it. Messages to the frozen guest model wait until control returns. Later page content and shared workspace edits can then become model-visible. Saved browser cookies remain on the computer's profile volume.
Take control requests full screen; Esc leaves full screen without returning control. Control expiry pauses the session rather than automatically restoring agent capture. Give control back checks the page before resuming. Passkeys and hardware WebAuthn generally cannot be completed inside the container browser.
Where does my task data go?
Self-hosting keeps the daemon and its primary storage on your host. Remote model providers, visited websites, installed connectors, notifications, and paired clients receive the data needed for their operations and apply their own retention rules.
| Data | Location or recipient | Retention |
|---|---|---|
| Tasks, messages, approvals | Host SQLite database; model-visible portions go to the provider. | Local records remain until removed; provider policy applies to its copies. |
| Screenshots & snapshots | May be in task/tool records and submitted model context. | No automatic screenshot expiry is implemented. |
| Browser logins | Per-computer profile volume, not encrypted by BotHearth. | Ordinary computer destruction retains the profile unless explicitly wiped. |
| Workspace & audit | Configured host files; audit includes a chain-head file. | No general per-task purge command or scheduled retention policy. |
| Provider keys | Encrypted host vault; the master key uses the selected key provider. | Retained until removed. Native CLI authentication is managed separately. |
| CLI history & logs | Native CLI authentication/history in the computer’s persistent model-home volume; historical host sessions and runner diagnostics on the host. | Review separately; deleting task data does not purge these histories. |
Back up and remove data deliberately
Stop the daemon before copying data. Preserve the configuration, database, intended workspaces, browser and native model-home volumes, audit file and chain head, and access to the vault’s original key provider. Encrypt backups.
bothearth computer destroy <name> removes computer containers; --wipe-profile additionally removes saved browser logins. Native model-home volumes, workspace files and host task/audit records require separate removal. Stopping the daemon does not erase records, and deleting local files cannot revoke copies sent to providers or paired devices. Follow the complete privacy and removal guide before removing an installation.
What does this website collect?
This informational site consists of static HTML, local CSS, local fonts, images, and a local image-viewer script. The informational pages add no analytics scripts, advertising trackers, or cookies. When enabled, the separate enterprise service verifies work emails, records licence claims, and sends enquiries; it does not run agents or receive task prompts.
The site is configured for GitHub Pages hosting. The hosting provider receives ordinary connection and HTTP request data, such as IP addresses, for operating its service; see GitHub's privacy statement. Following a source or documentation link sends a request to the destination site under its policy.
Current availability: online certificate claims are not open yet; contact submission is not open yet. The following describes the service data flows when enabled.
When enabled, enterprise sign-in sends your work email and a one-time verification code through Resend. Codes expire in ten minutes and are stored as keyed hashes. An HttpOnly session cookie lasts up to 24 hours. The service retains the organisation name, domain, claimant email, licence identifier, issue date, software version, and accepted terms as the record of a perpetual grant. Rate limits use keyed hashes of email/domain and connection addresses, retained up to one hour. Expired authentication and rate-limit records are removed on the next request.
When the public contact form is enabled, it sends your name, reply email, optional organisation, requested licence count, and message through Resend to our private support inbox. Contact email addresses are not verified. The contact service forwards the enquiry without storing a database copy and temporarily retains hashed email addresses for rate limiting. Enquiries submitted from a signed-in enterprise account also store your verified email, domain, licence count, and message; those service copies are removed after 90 days on the next request; provider, mailbox, host, and backup retention policies apply separately. Email acceptance does not mean inbox delivery. When the contact endpoint is not configured, the form cannot send a message. Check the contact page for submission availability before using it for corrections, data requests, or licence disputes. See Resend’s privacy policy. Keep confidential task data and credentials out of enquiries.
The displayed screenshots are recorded development captures. The real email organisation test has private inbox details and task narration blurred before publication; obsolete internal details are also blurred. Other pixels are unchanged. The captures retain older labels and show recorded tests, not a live visitor session.
How do I report a vulnerability?
Use GitHub’s private vulnerability reporting form with a short impact summary, version or commit, host OS, container runtime and reproduction outline.
Do not publish unpatched exploit details, tokens, bootstrap links, cookies, raw task databases, or vault contents in a public issue. This alpha carries no security certification or guaranteed response time.
Implementation references: full security model, privacy and retention, provider requirements. Reviewed 2026-09-10 for v0.0.1 alpha.