1. Home
  2. How it works

The mechanism

You sign in once. The agent never asks again.

Three stages: capture a genuine signed‑in session, seal it under per‑tenant encryption, then replay it into a fresh browser every time a run starts. The password exists for exactly one moment, in your hands, and is never written to disk.

Stage 1 Capture Stage 2 Vault Stage 3 Run
One capture, then a sealed session the agent replays on every run 1 · Capture You sign in, by hand, in a real browser. MFA, SSO, CAPTCHA — all of it. Session captured 2 · Vault Sealed per tenant. DEK + AAD; master key in your KMS. No plaintext password 3 · Run Fresh isolated context. Agent replays it. Unattended
The password exists for one moment, in your hands, and is never written to disk. Everything after is the session.

  1. Capture — you log in, in a real browser

    We open a browser you can watch. You complete the login exactly as you always do: including the OTP, the CAPTCHA, the SSO redirect, the device‑binding prompt. That last part matters: a credential replay bot fails at every one of those, every single run.

    When the site is satisfied, we read back what it issued: the session cookies, including HttpOnly ones that JavaScript can never see, plus localStorage for the origins in play. That collection is the session.

  2. Vault — sealed before it touches disk

    Each tenant gets its own data encryption key. Session material is encrypted with that key, and the key itself is wrapped by a master key held in your cloud’s secret manager or KMS, never in our application database, never in an environment file.

    Every record is additionally authenticated against its tenant and session id, so a ciphertext lifted from one tenant will not decrypt in another’s context. Rotate the tenant key and every session under it is re‑sealed.

  3. Run — isolated browser, injected session

    A run starts a brand‑new browser context with no history, no cookies and no storage. Before the first navigation, we inject the session. The agent then executes a declarative list of steps against a semantic snapshot of the page, not against pixels.

    When the run finishes the context is destroyed. Nothing carries over to the next run, and two runs on the same session never see each other’s state.

The distinction that makes this work: we replay the session the site already granted, not the password that obtained it.

Why not something simpler

The three alternatives, and where each breaks

We are not the first attempt at this problem. The other approaches fail in predictable places, and it is worth being precise about where.

Approaches to automating a site with no API
Approach What it does Where it breaks
Reverse‑engineer the API Call the portal’s private endpoints directly. Undocumented, unversioned, changes without notice. Breaks the moment auth moves to a device‑bound or attested token.
Credential replay Store the password, type it in each run. Plaintext credentials at rest. Fails on MFA, CAPTCHA, SSO and step‑up auth, and trips bot detection on the first run.
Desktop / screen RPA Drive the UI by coordinates and image matching. Brittle under any layout change, needs a full desktop, cannot run cheaply in parallel, and has no way to hold a session securely.
PreLogin Replay the granted session in an isolated browser. Re‑capture is required when the site itself expires the session — which is a property of the site, not of us.
The runtime

What the agent can actually do

Runs are declared as an ordered list of steps. Each step is small, inspectable and independently retryable, which is what makes a failed run debuggable rather than mysterious.

  • goto: navigate to a URL, or continue from the session’s start page.
  • waitFor: block until text or a selector appears, with a timeout.
  • snapshot: capture the semantic accessibility tree, not a screenshot.
  • click: act on an element resolved from that snapshot.
  • fill: type into fields, including inside cross‑origin iframes.
  • extract: pull structured data out of the page.
  • assertText / assertLoggedIn: fail loudly instead of silently doing nothing.
  • wait: pause for a fixed interval when a portal is simply slow.
Ordinary automation portal.example.com login.idp.com (cross‑origin iframe) Blocked at the frame boundary the difference PreLogin portal.example.com login.idp.com (cross‑origin iframe) Reads, types and clicks inside
Identity providers render login inside a frame from another origin. Most automation stops at the frame edge. We address the frame directly.

Cross‑origin iframes are the hard part. Google Sign‑In, Apple ID, Auth0, reCAPTCHA, 3‑D Secure and Stripe Elements all live in a frame from another origin. Most automation cannot address them at all. We can read, type and click inside them.

Two failure modes are detected rather than swallowed. If a portal has logged you out, assertLoggedIn fails the run with a clear reason instead of scraping a login page and returning empty data. If a session reaches its natural expiry, the run is marked for re‑capture. A human signs in once more, and automation resumes.

See it against one of your portals.

Pick the workflow that costs you the most hours a month. We’ll run it on that.

Start a pilot