A human drives a real browser. Here is exactly how we protect that.
DoubleOh asks something serious of you: that one of your people takes the wheel of a live browser session to fix a stuck agent. That is a security-sensitive action, so this page states plainly what we do, what we never do, and where the boundaries are. No marketing language.
The single most important guarantee: typed text is never recorded. A fix session is exactly where a password gets typed. Our recorder stores screenshots and the shape of each action, a click at these coordinates, a key by name, but for typing it stores only that typing happened. The characters never leave the browser. This is enforced in code, not policy.
What we record, precisely
Screenshots
Frames of the page during the fix, so the compiler can turn what a human did into a reusable procedure.
The shape of actions
A click and its coordinates. A named key such as Tab or Enter. A scroll distance. Enough to understand the steps.
Typed characters
Passwords, tokens, one-time codes, anything typed. The recorder receives no text for a type action, so there is nothing to leak.
Plaintext secrets
API keys and fix tokens are stored only as SHA-256 hashes. The plaintext exists once, in the response that issued it.
Isolation: one customer, one browser
Every API key gets its own dedicated browser container with its own storage volumes. Your logins, cookies, and session state live in your container and are never visible to another customer. Two customers cannot appear in the same recording, and one customer's trouble cannot reach another's session.
Where a fix session can go, and where it cannot
A fix link opens a page your agent was stuck on. Because that URL comes from outside our network, it is validated unconditionally before anything opens:
- Only
httpandhttps. Nofile:, nodata:, no browser-internal schemes. - Private and loopback addresses are refused, including the many ways people spell them: octal, hexadecimal, IPv6, and IPv4-mapped forms.
- Cloud metadata endpoints are refused. This is the attack that turns a browsing service into a credential leak, and it is closed.
- Internal-only hostnames and single-label hosts are refused.
- Refusals give one generic message on purpose, so the endpoint cannot be used to map a network.
We test these boundaries against production, not just in a test suite. Pointing a fix at a cloud metadata address or at our own admin API returns the same refusal every time.
The fix link itself
- Tokens are random, long, and stored hashed. We cannot reproduce a fix link, even for you.
- Links expire within hours and stop working once the fix is closed.
- A fix link grants exactly one thing: driving that one session. It is not an account, and it cannot read your other data.
The administrative surface
The API that issues keys and reads the audit trail is not exposed to the internet at all. It answers only on the server's loopback interface, reachable by the operator over an SSH tunnel. A request to it from the public internet is refused before it reaches the application.
Transport and infrastructure
- TLS everywhere, with HTTP permanently redirected to HTTPS and HSTS enabled.
- Fix pages cannot be embedded in another site. Clickjacking a live browser session is prevented by frame-ancestors and X-Frame-Options.
- Only ports 22, 80, and 443 are open. The database and application ports are bound to loopback and are not routable from outside.
- Stored credentials are encrypted at rest with a key held outside the database.
- The database is backed up nightly, with restores tested.
CAPTCHAs and human checks
When an agent hits a CAPTCHA or a "verify you are human" challenge, DoubleOh does exactly what those checks are asking for: it brings a human. We detect the challenge and point your person straight at it in the fix session, where they solve it themselves. We do not defeat, farm out, or automate around human-verification systems, and we never will. A CAPTCHA is the clearest example of a wall that is supposed to need a person, and a reliability layer that respects that is the only kind worth trusting with your agents.
What we are honest about
Two limits worth stating rather than hiding:
- Your session state lives in your container on our servers. That is what makes "log in once and stay logged in" work. If your policy forbids that, the self-hosted deployment puts the whole system inside your own infrastructure instead.
- Our sandboxes reach the public internet, not your intranet. A fix cannot reach a VPN-only internal tool. That is a deliberate boundary, and the self-hosted option is the answer for internal systems.
Reporting a vulnerability
Email security@doubleoh.ai. We read every report, respond quickly, and credit researchers who disclose responsibly. We would much rather hear it from you than read about it later.
Formal certification such as SOC 2 is on the roadmap. We would rather tell you exactly what we do today than imply an audit we have not completed.