How to Test an AI Agent After Login Without Exposing Customer Data

Anthropic explains that Claude in Chrome can read, click, navigate, type, and fill forms on websites, including pages visible in the user's browser context. Its safety guidance identifies prompt injection as a central risk and warns that visible sensitive information may be captured in screenshots used to understand the page. Anthropic recommends trusted sites, careful permissions, separate browser profiles for sensitive work, and human review. Its current permission guidance also prohibits actions such as purchases, creating accounts, handling sensitive card or identity data, and permanent deletion. Those product limits must be part of a test plan; a benchmark should never label a safety refusal as ordinary website failure.^{1, 2, 3}

OpenAI's current browser surface is ChatGPT Work with cloud browser; the former ChatGPT Agent mode is no longer the current product. Cloud browser runs on a separate remote computer, can work on supported public and signed-in sites, pauses for sign-in or confirmation, and provides a secure sign-in form in which entered credentials go directly to the remote browser rather than becoming visible to the model. OpenAI says consequential financial, legal, account, or other real-world commitments require confirmation and acknowledges that websites may block automated browser agents. This design reduces some credential exposure, but it does not make every authenticated workflow safe or supported.^{4, 5}

Google describes Gemini in Chrome with auto browse as an agentic browsing surface that can automate errands and confirm sensitive actions. Across these products, the common lesson is not that one permission model is universally best. It is that browser surface, account state, provider policy, and approval mode materially affect the result. A valid report must name all four. Saying that a model can use the site is too broad when the same model may run through a local extension, a cloud browser, a mobile browser, or a constrained connected tool with different access and safety rules.⁶

As reviewed on August 30, 2026, AgentReady's current public diagnostic can inspect public discovery files, rendered content, semantic controls, browser stability, safety hints, legal surfaces, and conditional API, MCP, repository, and commerce evidence. Its enhanced browser mode performs bounded public interactions, including locating navigation and filling a non-password form without submission. It blocks non-GET and non-HEAD network methods. The project dashboard can retain scans and fixes after a user signs in to AgentReady, but that account login does not grant the scanner access to the scanned site's private product.⁷

Therefore a current AgentReady score may identify prerequisites for an authenticated task—clear login navigation, labeled form fields, stable runtime, safe controls, or an advertised OAuth surface—but it does not prove that an agent logged in, selected the correct workspace, respected authorization, or completed a product action. This guide proposes the next testing layer. Readers should pair it with readiness score versus journey success, which keeps deterministic public observations separate from executed task evidence, and should not describe the proposed recorder below as an available AgentReady feature.⁷

An authenticated agent test combines at least four trust domains: the agent provider, the browser or remote computer, the target application, and any connected identity or secret manager. The page may contain customer-generated text, emails, documents, tool descriptions, or support tickets that an attacker can influence. OWASP's guidance for LLM applications treats prompt injection, sensitive information disclosure, excessive agency, and insecure tool use as distinct risks. The test must assume that untrusted page text can attempt to redirect the agent and that a correctly authenticated session can amplify the harm of a mistake.^{8, 9}

Define the maximum acceptable consequence before opening the browser. For a sales product, perhaps the agent may read a synthetic lead and draft a follow-up but may not send it. For billing, it may compare test invoices but may not change a subscription. For commerce, it may assemble a sandbox cart and stop at the payment confirmation boundary. For administration, it may locate a setting but may not change permissions. This safe stop is not an informal suggestion. It is a machine-checkable assertion, an approval rule, and the dividing line between a diagnostic and an unauthorized action.^{10, 8}

Create a dedicated test tenant that cannot see production customer data. Seed it with obviously synthetic people, products, messages, files, and payment methods. Use addresses and domains reserved for examples, label records as automated test fixtures, and ensure outbound email, webhooks, integrations, and financial settlement are disabled or redirected to controlled sinks. Give the test identity only the minimum role needed for the journey. If the goal is to read an invoice, do not grant user administration. If the goal is to draft a support reply, do not grant refunds. Least privilege turns an unexpected navigation into a contained test failure instead of an incident.¹⁰

Make the fixture resettable. Every run should begin from a known database or API snapshot and end with a diff of state that the test was allowed to touch. Use idempotency keys or unique run identifiers for any permitted sandbox mutation. Set a short session lifetime, revoke the account after the run, and rotate any secret that could have entered a screenshot or log. If the agent product offers a secure credential handoff, use it rather than placing passwords in the prompt. Still verify where cookies persist, how browser data is cleared, and whether the provider retains session artifacts according to the organization's requirements.^{1, 4, 10}

A useful contract names the agent product, current browser surface, plan, region, model if selectable, starting URL, authentication method, test tenant, exact task, fixture values, allowed domains, allowed actions, prohibited actions, safe stopping point, success assertions, and retry rule. A prompt such as manage this account is untestable. A better task is: using test tenant AR-108, find synthetic invoice INV-204, report its amount and due date with the page URL, and stop without editing, downloading, messaging, or paying. That contract can be checked against logs and state, and it works even when the agent narrates success inaccurately.

Provider policies are part of applicability. If a browser product prohibits purchases or account creation, choose a read-only or pre-confirmation task for that product. Do not penalize it for refusing the prohibited step, and do not prompt it to bypass CAPTCHA, bot authorization, or site controls. The cross-platform browser test blueprint uses a shared core task with provider-specific safe stops. For payment-oriented analysis, Stripe Link wallet and agent payments should be tested in provider-approved sandbox modes, never against a live customer card.^{1, 4}

Website teams can reduce risk without writing agent-specific forks. Give controls stable accessible names, show the current workspace and acting identity, distinguish draft from send, describe consequences before confirmation, and return durable receipts after permitted actions. Make authorization errors explicit rather than silently hiding state. Provide a clear cancel path and preserve user intent when validation fails. These practices help people using assistive technology and conventional automation as well as agents, and they give a test runner assertions that are more meaningful than pixel coordinates.^{11, 12}

Structured tools can improve precision, but they raise the same authorization questions. WebMCP proposals let websites expose browser-scoped tools; Google's security guidance warns that tool definitions and outputs can carry malicious instructions and that agents in a browser may operate inside an authenticated session. The WebMCP website-tools guide should therefore be implemented with narrowly scoped operations, server-side authorization, typed inputs, confirmation for consequential actions, and unambiguous receipts. A tool call must never be trusted merely because it avoided clicking the DOM.^{13, 9}

The adjacent proposed AgentReady tool is an Authenticated Journey Recorder. A site owner would create a goal contract, choose a provider-approved browser surface, attach a disposable test tenant, declare allowed actions and a safe stop, and run through a secret-isolated credential handoff. The recorder would collect sanitized browser evidence, approval events, network method summaries, state assertions, and the first blocked step. It would refuse production credentials by default, block undeclared origins and side effects, and mark unsupported provider actions as not applicable rather than failed.

Until that tool exists, the available AgentReady public scan remains a useful prerequisite check. Use it to identify public login discovery, form semantics, browser stability, bot access, security signals, and Fix Pack work before arranging a manual sandbox test. Store any resulting case study in a consent-controlled research program such as the Agentic Customer Journey Index, and publish comparisons only through an explicit methodology and owner process such as the proposed leaderboards. Public readiness and authenticated success should meet in one evidence trail, but they should never be confused.