# Test credentials and browser data

Use test accounts, and choose an environment where the authored actions are appropriate. Zerocheck needs page context to run a test and explain its result, so choose your flows with that data access in mind. Your dedicated instance holds your tests, results and evidence.

## Where the browser runs

Tests run from the web app use a hosted browser on your instance. Tests run with the CLI use a browser on your machine or CI runner. In both cases your instance makes every decision, and it sends page context to the AI model provider it is configured with.

Running the browser on your machine lets it reach addresses your machine can reach. It does not make execution offline, and your page data does not stay only on your machine.

## What your instance receives from a CLI run

- At sign-in, this machine's hostname and the CLI's version.
- The selected YAML test files, with their paths and content revisions.
- The environment's settings: URL, login steps, allowed origins and execution settings, with the names of its secrets and no values.
- While tests run, what the browser shows: page snapshots, screenshots, URLs and console messages, after redaction, along with the result of each browser action.
- After a test whose environment has no configured secrets, its recording.

A model call can include a masked screenshot, a redacted accessibility tree, the page URL and title, and recent actions.

## How credentials are handled

Refer to secrets by name in test steps and in `zerocheck.yaml`.

**With the CLI**, each secret names an environment variable on the machine that runs it, such as `PASSWORD: ${APP_TEST_PASSWORD}`. A missing variable stops the run before it starts. The instance receives the secret's name, never its value. The CLI types a value only into the step it is bound to, only on your app's origin or, during login steps, an origin that `secret_origins` grants to that secret. A test or login step that writes out a configured secret value is refused before anything is recorded or sent.

**With the hosted browser**, we configure the values on your instance with you, and project settings can reference only `${ZEROCHECK_TEST_*}` names. Missing values stop the run before a browser opens.

In either case the value is typed into the page, so your application receives it as usual.

## What is masked, and what is not

Configured secret values are replaced with `[redacted]` in model observations, errors, console output and saved text, including escaped, encoded and whitespace-normalized forms. Sensitive authorization parameters in URLs are also redacted. Screenshots mask recognized input fields, visible text matching a configured secret, and frames the run is not permitted to read. If the run cannot prove how a frame should be masked, it withholds the screenshot and records an artifact error.

This is not general personal-data removal. It does not detect secrets painted into a canvas or an image, or other sensitive application data. Other data on the page can appear in observations, screenshots and recordings, so use test data.

## When a test is recorded

A recording is made only when the environment has no configured secrets, because video cannot be masked. Typed public or test values and other application data can still appear in it. In a CLI run the recording is uploaded to your instance after each test and removed from your machine when the run ends.

## Actions and environments

Choose `dev`, `staging` or `production` explicitly. Choosing production does not make a run read-only.

Local rules deny observed actions such as deleting accounts, workspaces or data, revoking critical access, bulk sends, and cancelling or refunding payments and subscriptions. In production they also deny revealing, exporting or rotating keys and tokens. A denied action stops the test as a policy failure. These rules judge what the browser observes; they cannot prove what your backend does.

Payments, checkout and subscribe actions are allowed and logged, so use your provider's test mode and test cards. Zerocheck has no special test-card command or inbox service.

## Results and access

Results and evidence from hosted and CLI runs are stored on your instance. The `.zerocheck` folder in your project holds the CLI's recovery state, such as the run ID, the target URL and the names of the variables holding your secrets, never a value. While a run is in progress, and after one that did not finish, it also holds that run's redacted replies, including screenshots and page text, until the run settles. `--json` writes a run record wherever you ask.

Evidence stays behind your instance's sign-in; there are no public share links. Your instance has one shared access password, and anyone with it can see every project on that instance. There are no separate user accounts, roles or SSO.

There is no advertised retention or deletion period. Discuss storage and backup requirements during onboarding.

[Supported flows](https://tryzerocheck.com/docs/limits/) · [Result evidence](https://tryzerocheck.com/docs/results/) · [Privacy policy](https://tryzerocheck.com/privacy/) · [Contact sales](https://tryzerocheck.com/demo/)

---
Canonical: https://tryzerocheck.com/docs/security/
Updated: 2026-11-01