Security
We hold logged-in browsers. We act like it.
Your agent's browser has your sessions and your vault has your passwords and 2FA keys. These are the controls in place today. Most of them are in the open-source engine, so you can read the code.
01
Credentials
- Vault encryption
- Passwords, card fields, API keys and authenticator (TOTP) keys are encrypted with AES-256-GCM. They are decrypted only inside the gateway, to be typed into a page, and never returned by any API, written to a log or shown to an agent.
- Saved sessions
- Cookies and local storage saved for a site are encrypted the same way as passwords. Imports report only counts and domains.
- Tokens shown once
- Your API tokens are shown once and stored only as a hash, with a label and the last four characters. The portal's own gateway credentials are encrypted at rest and never reach a browser.
02
What an agent can do
- Read-only tabs
- A tab opened in read mode blocks every write at the network level. Agents look in read tabs and ask for an act tab only to change something.
- Site policy
- Ordered rules per user: read_only, ask or allowed. A read-only site refuses writes, logins, secrets, JavaScript and CAPTCHA actions with site_read_only. The server enforces it for MCP and REST alike.
- Untrusted page text
- Page content reaches the agent fenced and labelled as data. This lowers the risk of prompt injection; it does not remove it, which is why the controls above are in the server.
- Private addresses refused
- Server-side reads and webhook deliveries connect only to public addresses, checked after DNS and on every redirect.
03
Isolation
- One browser per user
- Each user's Chromium runs as its own process with its own profile and virtual screen. The user comes from the token, never from anything the client sends, so one user cannot reach another's tabs, files or vault.
- Chromium's sandbox on
- Browsers run with Chromium's sandbox enabled inside the container, using a seccomp profile that adds only the three syscalls the sandbox needs to Docker's default.
- CDP stays inside
- The browser's debugging port and screen server listen inside the container only. Nothing reaches them except the gateway.
04
People in the loop
- View-only live links
- Viewer and hand-off links are short-lived tickets kept in the URL fragment, which browsers do not send to servers. A view-only link is enforced by the server's relay: it forwards only what is needed to draw the screen and drops keyboard, pointer and clipboard input.
- Take-over is opt-in
- Interactive links are issued only when the user's settings allow taking over.
05
Accountability
- Audit log
- Every write, login, secret use, hand-off and admin action is logged with the user on every line. Workspace owners see their workspace's events in the console.
- Account security
- Passwords are hashed with Argon2id; sign-in and reset routes are rate limited; email addresses are verified. Sign-in with Google or GitHub is available.
- Web hardening
- TLS everywhere, HSTS, a per-request Content Security Policy with nonces, and frame-ancestors none.
Audit status
No certifications yet, and we say so.
We do not hold SOC 2, ISO 27001 or any other third-party certification today, and no external penetration test has been published. When that changes it will be on this page.
On our list: a separate encryption key per user, wrapped by a key-management service (today one server key protects the vault); SSO for teams; an external penetration test.
Report a vulnerability privately to [email protected]. Please do not open a public issue. The process is in the repository's SECURITY.md.
Data handling is described in the privacy policy and the data processing agreement (both drafts pending legal review).
Read the code behind the controls.
The engine is open source under AGPL-3.0. Or start the free trial and see the audit log fill up.