outcrawl

Legal

Security

Where the credential lives, how a session is recorded, and who can see it: the architecture behind the claim, not just the claim.

Last updated 8 October 2026

01

Overview

Outcrawl sits between your agent and the pages it needs. This page is the architecture behind that sentence: where the credential lives, what a browser session can and cannot see, who can watch a recording, and what happens to the data in between. Where we say something is true below, it is because it is built that way, not because we would like it to be.

02

Architecture

Two systems sit between your task and the page it needs, and the credential only crosses one of them in the clear.

When you use the console or the playground in your own browser, that browser talks to our backend using only a signed-in session cookie. Our backend is the one system that holds your API key on your behalf for that action: it attaches it to the request on our own servers and forwards it to our router, which runs the fleet. The key itself never reaches your browser, is never written into a script it runs, is never logged, and is never echoed back in a URL or an error message.

When your own application, agent, CLI or MCP client calls the API directly, it holds the key itself and sends it as a bearer token straight to us, the same way any API credential works. That is a server-to-server call from your side, not ours: keep the key out of code that runs in a browser or ships to a user’s device, the same discipline you would apply to any bearer token, and it never needs to touch one.

03

API keys

A key looks like ock_<keyId>.<secret>: a short public id and a secret half. The secret half is shown to you exactly once, at the moment the key is created. From then on we keep a cryptographic digest of it, never the value itself, so the secret cannot be recovered later by you, by us, or by anyone with access to our database. If you lose it, you issue a new key and delete the old one.

Revoking a key takes effect everywhere within a minute: our edge caches a credential briefly for speed, and a revocation clears on the same bound. A key is scoped to your account and to the plan it was issued under, and its secret half is drawn from a cryptographically random source, not derived from the id beside it.

04

Secrets you store with us

A run sometimes needs a credential: a card, a password, an API token. You store it once as a secret under a name, from our CLI or an SDK, straight to the platform. A task then refers to that name, never the value, and the console you sign in to in a browser only lists what is stored and revokes it: it never carries a value in either direction. The value is sealed on arrival. There is no route in our API that returns it, to you, to a script, or to us: creation, listing by name, and deletion exist; reading the value back does not.

That absence also reaches the model. A stored secret is never exposed as something an assistant can call: a task can be told which name to use, and we fill the value in server-side when the request actually goes out. The model driving the task addresses a name. It is never shown, and cannot ask for, the value behind it.

05

Browser session data

A task’s browser session sees what any browser sees: the pages it loads, the cookies those pages set, and anything a form on those pages was given, including a credential you supplied for that run. None of it is logged as telemetry. The only durable record of what happened is the session’s recording, described next, which you can turn off.

06

Session recordings and who can see them

Agent runs and browser sessions are recorded unless you turn recording off: record: false on an agent run, or ?record=false when you connect a browser. Turning it off costs nothing, and nothing is written, not a video and not a request log. Scrapes, crawls and searches are never recorded.

A recording is a video of each browser tab, captured on the machine that ran the session, kept together with the requests the session made (with up to 10 MiB of response bodies), its console output and the pointer’s movement. It is stored with Cloudflare and deleted automatically when your plan’s retention period ends. It opens paused at its first frame. Our player runs under a strict content policy, and only Outcrawl’s own sites may embed it.

A recording is private to your team: members of your organization and your account’s API keys can watch it. Nobody else can, and Outcrawl staff can watch one only if you share it with them. You can share a recording by link, which lets anyone holding the link watch without signing in, or with named people, who sign in to watch. Stopping sharing turns the link off at once, and sharing again makes a new link. People you share with can watch but cannot take control. A recording includes the requests the session made, so share it the way you would share the session itself.

A live session follows the same rules. The picture streams straight from the machine running the session, and only members of your team or your API keys can take control of the browser mid-run. While a person drives, the agent waits, and it carries on when control is handed back.

07

Encryption

Every request to the API, and every page a session fetches on your behalf, travels over TLS. Data at rest in our database is encrypted by our infrastructure provider as a matter of standard practice, and the API key stored there is a cryptographic digest, not the credential itself, so encryption is a second layer over a secret that was already one-way by design.

08

Network and egress

A task runs on a dedicated machine in our fleet, not on your infrastructure and not in a shared container with another customer’s session. Page requests leave through a residential network exit rather than a datacentre range, which is what makes a session behave, from the destination’s side, like an ordinary visit rather than traffic from a server farm.

For a recorded session, each request it made, with its headers, timing and size, can be read live or afterwards from the same address as the recording, which is also how a disputed charge gets resolved: against what the session actually did.

09

Hosting and subprocessors

The service runs on the infrastructure below. Each provider is bound to use what it handles only to help run the service, and page content or anything captured from a browser session goes no further than running your request needs: an AI model provider reads the page an agent run or a JSON extraction is working on, and a captcha-solving service sees a captcha a page shows.

Google
Sign-in, if you choose it, and reCAPTCHA on the sign-in page
GitHub
Sign-in, if you choose it
Vercel
Hosts the application you are using
Supabase
Runs the database behind your account, usage and billing records
Cloudflare
Runs the request router and the browser fleet your API calls reach, and stores session recordings
AI model providers
Read the page an agent run is working on, or a page a scrape or crawl turns into JSON
Captcha-solving services
Solve a captcha a page shows while we load it
Stripe
Processes payment where a plan involves one
Resend
Sends account and billing email
Mintlify
Hosts the documentation at outcrawl.ai/docs
PostHog
If you allow it, measures how this site, its docs and the console are used, and records sessions on them
DataFast
If you allow it, measures where visitors come from and which sources lead to sign-ups and payments

10

Data retention

Account, usage and billing records are kept for as long as your account is active and for a limited period after, for accounting and legal purposes. A session recording is kept for the period shown against it in your console. Browser session data that is not captured as a recording was never written down, so there is no copy of it to retain or to delete. More detail on all three is on our privacy policy.

11

Responsible disclosure

If you find a security issue, tell us before you tell anyone else: security@outcrawl.ai. Include what you found, the steps to reproduce it, and its impact as you understand it. We will acknowledge a report within a few business days and work with you on a fix.

We will not pursue legal action against a good-faith report that stays inside this scope: testing against your own account and data, not another customer’s; no data destruction; no service disruption; and no public disclosure until we have had a reasonable window, ninety days is our standard one, to fix what you found, or until we agree a different timeline with you directly.

12

Contact

Security reports: security@outcrawl.ai. Everything else: hello@outcrawl.ai.