Tom Hundley
🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4
If a browser agent captures the wrong artifact at the wrong moment, it can leak credentials without ever acting maliciously. The core risk is simple: tools used to observe a page can collect secrets that later end up in logs, traces, debugging artifacts, or model context. For teams building agents that interact with finance portals or other authenticated systems, the safe default is straightforward: do not capture or persist accessibility snapshots, DOM dumps, screenshots, or HAR files while credential fields are populated.
This matters because browser automation stacks often treat perception as harmless. It is not. Authentication views are secret-bearing surfaces, and any artifact taken from them should be handled like sensitive data. The practical pattern is to fill credentials, submit the form, wait for the page state to change, and only then resume normal observation. When capture is unavoidable, sensitive fields should be redacted before the artifact is logged, stored, or passed to a model.
This article explains the trap, the safer pattern, and the broader lesson: browser-agent security is as much about perception hygiene as action control.
TL;DR: Accessibility snapshots can expose sensitive field values, so they should be treated as security-sensitive artifacts rather than harmless page metadata.
A common browser-agent pattern is to use an accessibility-tree snapshot to understand the current page. Compared with parsing raw HTML, the accessibility tree offers a cleaner semantic view: roles, labels, states, and values. That makes it useful for agents that need structured page understanding.
The problem is that structured page understanding can include sensitive values. On authentication views, a snapshot may include the current value of form controls. If that artifact is then logged, attached to a trace, or forwarded into an LLM context window, the agent has effectively exfiltrated a secret through its own perception pipeline.
That risk is easy to miss because snapshotting feels read-only. But reading a page that contains credentials is still a secret-handling operation.
A simplified accessibility node for a filled password field may look like this:
{
"role": "textbox",
"name": "Password",
"value": "REDACTED_SECRET",
"disabled": false,
"focused": true
}The exact shape of the snapshot varies by browser engine, page implementation, and Playwright version. The important point is not the precise JSON schema; it is that sensitive values can appear in machine-readable output that developers may be tempted to treat as safe for logging.
Developers usually focus on what an agent can do: click, type, submit, navigate. Less attention goes to what the agent can record. In practice, the recording path is often where secrets leak first. A snapshot taken for debugging can be copied into logs, traces, issue trackers, or prompt history long before anyone notices it contains sensitive data.
TL;DR: The safest default is to avoid capturing any perception artifact while credentials are present, then resume observation only after the authentication step is complete.
A practical defensive pattern has three parts:
The following example shows the shape of a guardrail, not a production-ready detector:
def contains_sensitive_auth_field(snapshot_node: dict) -> bool:
"""Recursively check an accessibility snapshot for likely credential fields."""
role = str(snapshot_node.get("role", "")).lower()
name = str(snapshot_node.get("name", "")).lower()
value = snapshot_node.get("value", "")
indicators = ["password", "passphrase", "secret", "credential"]
looks_sensitive = role == "textbox" and any(term in name for term in indicators)
if looks_sensitive and value:
return True
for child in snapshot_node.get("children", []):
if contains_sensitive_auth_field(child):
return True
return False
def safe_log_snapshot(snapshot: dict, logger) -> None:
"""Log a snapshot only if it appears free of populated auth fields."""
if contains_sensitive_auth_field(snapshot):
logger.warning(
"Snapshot blocked because it may contain populated credential fields."
)
return
logger.info("a11y_snapshot", snapshot=snapshot)This kind of heuristic is useful, but it is not sufficient on its own. Production systems should also classify auth views earlier in the workflow, suppress capture around known login transitions, and apply redaction policies to any artifact that might contain secrets.
TL;DR: Accessibility trees are only one leak path; screenshots, DOM dumps, network captures, and traces can all expose secrets if they are persisted carelessly.
The broader lesson is that every perception artifact can become a leak surface.
| Perception artifact | Typical risk | Safer handling |
|---|---|---|
| Accessibility snapshot | Sensitive form values or labels in structured output | Suppress or redact before logging |
| Screenshot | Visible account data, PII, balances, MFA prompts | Avoid capture on sensitive views; store only when necessary |
| DOM dump | Input values, hidden fields, embedded tokens, page data | Strip sensitive attributes and fields before persistence |
| HAR capture | Request bodies, cookies, session identifiers, auth headers | Disable by default around auth; scrub aggressively if enabled |
| Network trace | Tokens or headers in request metadata | Redact authorization and session material before storage |
Two nuances matter here:
The common rule is simple: if an artifact is taken from an authentication or account-sensitive view, assume it may contain secrets until proven otherwise.
TL;DR: Auditing what an agent records is as important as auditing what it clicks, because observation pipelines can leak sensitive data at scale.
Security reviews for browser agents often emphasize permissions, navigation rules, and action controls. Those are necessary, but incomplete. An agent that never makes a dangerous click can still create a serious incident if it persistently records sensitive data and sends it to the wrong place.
That is why perception hygiene should be treated as a first-class control. In practical terms, that means:
This is especially important in finance workflows, where the page may contain credentials, personally identifiable information, balances, tax data, or payment details. The risk is not hypothetical; it is a direct consequence of how automation and observability tooling work.
Accessibility output is designed for assistive technologies, not for secure logging. That means it may include semantic details and control values that are not obvious from the rendered UI alone. Developers should treat that output as potentially sensitive structured data.
Skipping capture is the safer default because it removes the chance of a redaction failure. Redaction is still useful when debugging is unavoidable, but it should happen before the artifact is written anywhere persistent or forwarded to a model.
Usually safer for password fields specifically, because browsers visually mask them, but not safe in general. Screenshots can still reveal names, account details, balances, MFA prompts, and other sensitive information.
Because they can include request and response metadata, cookies, headers, and form submissions. During authentication, that can mean credentials, session identifiers, or other high-value secrets are captured in a single debugging artifact.
Treat authentication and account-sensitive views as no-capture zones by default. If an exception is needed for debugging, require explicit redaction and keep the resulting artifact out of general logs, traces, and model context.
The main lesson is not limited to one API or one framework. Any browser agent that observes authenticated pages can turn routine debugging artifacts into a secret leak if capture policies are too permissive. Teams building agents for finance, healthcare, or other sensitive workflows should design observation pipelines with the same care they apply to action controls: minimize collection, block capture on sensitive views, and redact before anything is stored or shared.
Discover more content: