What is zero data retention in browser automation?

What is zero data retention in browser automation?

Browser automation produces a lot of incidental data. Every step generates a screenshot, a DOM snapshot, a network log, a prompt, a model response. By default, all of that gets persisted somewhere — usually for debugging, replay, and observability. Useful in development, often unacceptable in production: a single agent session against a healthcare dashboard or a corporate-banking portal can capture the same kinds of data your compliance officer would have an aneurysm about. Zero data retention is the posture that closes that gap by guaranteeing none of it survives the session.

What ZDR actually covers

A meaningful ZDR commitment names which data classes don't get retained. The categories worth asking about, in order of how often they actually leak:

• Rendered page content (HTML, text, embedded data, scraped tables) — the largest surface, since the agent reads everything the page exposes.
• Screenshots and visual frames — useful for debugging, devastating in PII contexts where a single frame can capture a name, account number, or medical detail.
• DOM snapshots and accessibility trees — same content as screenshots, in machine-readable form.
• Prompts and model responses — every observation and action that flowed through the LLM.
• Network requests and response bodies captured by the browser instrumentation layer.
• Session recordings / replay artifacts — full timelines stored for "let me re-watch what the agent did" tooling.

A vendor that promises ZDR but only covers the first two has a marketing posture, not a compliance one. The right phrasing in a contract is "no session content of any class is persisted to durable storage after the session ends."

What ZDR does not mean

ZDR is about session content. It is not about every byte that ever moves through a system:

• Aggregate metrics (run counts, durations, error rates) typically stay. They aren't session content.
• Vaulted credentials are persistent by design — that's the point of a vault. They're encrypted at rest, never in the LLM context, and outside the ZDR scope.
• Digital identities persist across runs — name, email, phone — and are likewise outside ZDR scope.
• Audit logs of agent actions at a what-happened level (run X executed Y at time T) often must be retained for compliance reasons.

A common misreading is "ZDR means nothing is stored anywhere ever." It means the content the agent saw and produced isn't stored. Identity, credentials, and audit metadata operate on different retention rules — and that distinction is usually what auditors ask you to articulate.

When you actually need ZDR

ZDR matters most when the session content can itself be a regulated artifact:

• Healthcare dashboards — page content can be PHI; a stored screenshot is a stored medical record.
• Financial workflows — bank balances, account numbers, trade orders. Many institutions' procurement processes will not approve a vendor without a written ZDR clause.
• Customer-account products where the agent acts on a third party's accounts. The customer's data passing through your stack is exactly the kind of risk ZDR addresses.
• Government / public-sector tooling under data-locality or sovereignty requirements.

You probably don't need ZDR for personal automations on your own accounts, internal QA agents on test data, or prototypes. Default retention is fine there and the debugging visibility is genuinely useful.

Notte's posture

Notte runs on infrastructure with SOC 2 Type II controls, and ZDR is offered as a contractual configuration for customers whose use case requires it (healthcare, financial services, regulated enterprise). Combined with credential vaulting (passwords never enter the LLM context), PII handling (per-session isolation), and browser sandboxing, the privacy posture is layered rather than single-control.

For specifics on what's covered for your account — and to get the ZDR clause in writing — talk to the security team via the Notte Trust Center.

Key takeaways

• ZDR is the guarantee that session content (pages, screenshots, DOMs, prompts, traces) doesn't survive a browser-automation run.
• It's specifically about session content, not aggregate metrics, vaulted credentials, persisted identities, or compliance-grade audit logs.
• Required in healthcare, financial services, and regulated B2B procurement; optional but defensible for personal and prototype work.
• Pair with vaulting, PII handling, and sandboxing — ZDR is one layer in a privacy story, not the whole story.