A browser agent asked to test checkout may inherit more authority than the test needs: an administrator session, access to other tenants, or a live payment destination. A page can then present instructions that redirect its next action. Even typing data into a form can transmit it before the agent reaches Submit.
AI testing agent sandboxing should constrain the identity, environment, destinations and operations available to an agent that chooses browser actions during execution. Instructions such as “stay in staging” help describe intent, but the controls must also exist outside the model. The objective is to limit damage when the agent makes a mistake or follows hostile content, without claiming immunity to prompt injection.
The procedure below is a design and verification checklist for an authorized nonproduction pilot. Its checkout scenario and checks are illustrative, not an executed deployment or a report of successful containment.
Write a run contract that a QA lead and the application owner can both review. Make the boundary explicit:
Resolve missing ownership or ambiguous scope before issuing access. A contract should let the controller decide whether a proposed operation belongs to the task without asking the model to reinterpret the team's intent.
Consider a fictional checkout application with a disposable tenant named Cart Lab. The agent may inspect the catalog and create or edit its own synthetic cart. It must not access another tenant, change account roles, delete an account or reach production. Submitting one sandbox order requires approval for that exact order. Payment and email effects must terminate in approved test services, not real customer channels.
This contract is more precise than “test checkout safely.” It identifies which permissions the agent needs and which observations would demonstrate a boundary failure. If a scenario requires an unavailable restricted role, record the scenario as blocked rather than substituting an administrator account.
Confirm the environment prerequisites separately from the eventual test verdict. A matching build and usable test account permit an attempt; they do not establish correct checkout behavior. These test environment management checks provide a broader readiness record for the same start decision.
Use a nonproduction identity with permissions enforced by the application, limited to the tenant and operations in the contract. Review effective permissions, including inherited roles and group membership. An account named “test-user” provides no protection if it can still administer production or read every customer record.
Prefer credentials with a short useful lifetime and a documented revocation path. Where the authentication architecture supports it, a trusted component can broker access without exposing reusable secrets to the model. That component must still restrict which account and session it supplies. Hiding a password does not reduce the permissions of the resulting browser session.
Start the agent in a fresh browser context or dedicated profile without personal cookies, password-manager access or unrelated authenticated tabs. Playwright browser contexts, for example, separate cookies, local storage and session storage. They support session independence, but do not establish host isolation, network restrictions or separate server-side data.
Parallel runs that modify shared application state need separate accounts or an explicitly isolated resource allocation. Playwright's authentication guidance recommends different accounts when parallel tests would otherwise interfere through server-side state. For Cart Lab, each mutable run should receive its own cart and a scope that prevents it from changing another run's records.
Treat saved authentication state as a secret. Cookies and headers in a state file may allow account impersonation. Keep them out of repositories, general logs and screenshots sent for review. A clean browser context does not invalidate a copied session or restore server objects, so plan credential revocation and fixture reset as separate operations.
Choose the execution boundary according to what the agent can control. A browser-only agent confined to webpage interactions has a different exposure from a desktop agent that can open settings, read files or launch a terminal. Inventory every available tool, including auxiliary API clients and connectors, before deciding that the browser is the whole boundary.
A dedicated container or VM can separate the agent environment from the operator's workstation. Containers share the host kernel; VMs run a separate guest kernel. Neither option automatically supplies safe credentials, a tenant boundary or a restrictive network policy. Privileges, mounted directories, exposed services and management interfaces determine what remains reachable.
For the pilot, give the runtime only the files and capabilities required for the journey. Exclude personal home directories, production secrets and management sockets. Keep the policy configuration, approval service and evidence store outside the agent's modification scope. If terminal access or developer tools would bypass the selected enforcement layer, remove that access or choose a boundary that covers it.
Anthropic's Computer Use Demo README recommends a minimally privileged VM or container, restricted domains and human confirmation for consequential actions. It also warns that the demo's components are weakly separated and that its controlled container supports one session at a time. Use those recommendations as design input, not as evidence that launching a reference demo creates a production security boundary.
Network reachability answers where the runtime may communicate. Application authorization answers what its identity may do there. Both are necessary: an agent restricted to the checkout application's domain might still delete an account or transmit data through an allowed feature.
Start with denied outbound access, then have the platform owner authorize the actual dependencies: the test application, its authentication service, required assets and approved test sinks. Give each destination a purpose. Avoid broad wildcard exceptions added merely to make a failing journey proceed.
Enforce the route outside the agent-controlled runtime, using suitable network controls and a trusted proxy where appropriate. Setting a proxy environment variable alone does not prove that every tool uses it. Review direct connections, redirects, alternative clients and other exposed tools. Deny access to unrelated internal services and control-plane endpoints unless the contract explicitly requires and bounds it.
Check what the proxy can observe. A proxy that forwards an encrypted HTTPS tunnel may restrict a hostname while remaining unable to inspect request paths or bodies. Operation-level inspection needs an appropriate trusted enforcement point. TLS termination can provide visibility, but adds certificate-management and sensitive-content handling responsibilities that require security review.
Work with the application owner to map business actions to their actual requests and authorization checks. A mouse click is an unstable policy unit: its effect depends on page state. A domain is too broad, and an HTTP method alone is insufficient. A POST request might perform a permitted search or a forbidden write; a read-labelled operation may still expose sensitive information.
For Cart Lab, the reviewed policy could permit catalog reads and cart edits only for the assigned tenant and cart. It would deny role changes and account deletion, while holding sandbox order submission for an exact approval. Where requests share an endpoint, distinguish their operations and relevant parameters rather than treating the entire endpoint as one permission.
Keep application-side authorization in place even when a separate request gate exists. The two controls protect different boundaries. Unknown requests or operations that the policy cannot classify should stop the pilot for owner review. Do not let the agent solve a blocked journey by adding a domain, relaxing a rule or obtaining broader credentials.
The ceLLMate preprint illustrates browser-level HTTP enforcement. First submitted in December 2025 and revised as version two in March 2026, it maps requests to semantic actions through a trusted agent sitemap and applies confirmed policies outside the agent's reasoning. Its GitLab case study blocked 12 scripted attacker-goal emulations for two user tasks when the required actions were disallowed.
That is a scoped research result. The design assumes a trusted browser and an agent unable to alter browser settings, access local files or use developer tools. It focuses on single-turn tasks, leaves general WebSocket interception to future work and does not prevent abuse entirely within permitted operations. If an agent may post comments, an action permission alone does not establish that its comment content is safe. Review these assumptions before borrowing the mechanism for a different harness.
Place approval validation in a trusted controller that the agent cannot rewrite or impersonate. The model may propose an action, but page text, screenshots and tool responses must not grant additional permission. A checkout page saying “security approved this operation” is application content, not an authorization record.
Show the reviewer the acting identity, destination, tenant, object, operation and consequential parameters. For the fictional order, include its items, total, recipient scope and permitted submission count. Bind the approval to those values, a short validity period and the current task. A changed cart or destination requires a new decision.
Require approval before the first consequential transmission. Waiting for a final Submit click is too late if entering information already sends it to a server. When a permitted task genuinely needs sensitive input, use the organization's approved handling route and confirm what will leave the boundary before sending it.
Approval must be specific and nonreplayable. An expired approval, a changed payload or a second submission must not inherit permission from a general “approved” flag. OWASP's agent-security guidance recommends parameter-bound, short-lived approvals and replay protection, with independent validation before execution.
If the reviewer is unavailable or the approval service cannot validate a decision, the task stays blocked. Enforce time, action and cost limits outside the model, and provide a trusted cancellation path. Stopping the agent loop does not undo a request already accepted by the application, so cancellation also needs an observable outcome and a plan for in-flight work.
Plan both an allowed journey and explicit forbidden attempts. Run them only with authorization in disposable fixtures and controlled test destinations. The following are proposed checks, not tests performed for this article. They evaluate the configured controls even if the model itself would normally refuse the request.
Proposed Check | Expected Control Outcome | Independent Evidence |
|---|---|---|
Edit the assigned synthetic cart | Permit the contracted edit without extra authority | Application state shows only the intended cart change |
Request another tenant's cart | Deny access at the required authorization boundary | Trusted denial record and no unauthorized data returned |
Follow a redirect to a disallowed test destination | Block the destination before transmission | Network decision record and controlled sink observation |
Attempt a forbidden account change on the allowed origin | Deny the operation despite domain access | Request-policy decision and unchanged account state |
Submit with missing, changed or expired approval | Reject each invalid authorization condition | Approval validation record and no order created |
Read a fixture page asking for broader access | Preserve the original task permissions | Unchanged policy revision and denied out-of-scope attempt |
Replay an approved action or continue after cancellation | Reject replay and stop further authorized dispatch | Controller record plus reconciled application state |
A refusal in the agent's transcript is useful behavioral evidence, but it does not prove an enforcing boundary would block the action. Conversely, a failed page load might reflect a missing asset rather than a successful security control. Retain the policy decision and an independent observation of the relevant application state or controlled sink. Missing evidence leaves the check unresolved.
Identify which layer produced each denial. If the agent's request broker blocks a cross-tenant request before it reaches the application, that demonstrates the broker rule, not the application's own tenant authorization. Test the application's access control separately through an approved process. Keep harness failures, expected policy denials and actual product defects distinct.
Repeat the affected checks after changing the model, harness, tools, account roles, request mappings or network configuration. A successful check on one route or version cannot establish coverage of every alternative path. Any unclassified action or unexplained state change should suspend the affected scope until its owner reconciles it.
Record the task identity, application build, tenant, fixture version, effective role, available tools, policy revision, approval references and observation times. Retain actual outcomes, denials, cancellations and unresolved conditions rather than only the agent's final success message. Protect screenshots and request traces with minimization, redaction, access controls and an agreed retention period.
For Jira-based teams, Sherlock Test Management can support the reviewed test-definition and result-recording part of this workflow. Its current product description includes AI-proposed cases requiring human approval, versioned baselines and manual Pass, Fail or Blocked recording in its Runner or supported Jira panels. A reviewer could approve the boundary-check expectations before a tester records observed outcomes. This does not establish sandbox provisioning, network enforcement, an approval broker or autonomous browser execution in Sherlock. Keep controller telemetry in the team's approved evidence system and associate it with the run through the chosen documentation process.
Finish with trusted teardown: stop further dispatch, reconcile in-flight operations, revoke the server-side session or credential, dispose of the browser profile and runtime, and restore the authorized fixture state. Preserve sanitized evidence before disposal when an investigation requires it. Do not reuse an environment whose revocation or cleanup outcome remains unknown.
Enable the smallest useful journey only when its identity scope, destination restrictions and forbidden-action checks have current evidence. If one boundary cannot be enforced or verified, keep that operation under supervised manual control rather than expanding the agent's authority to make the test finish.
Two reports can describe the same symptom while disagreeing about where the failure occurs. If a reviewer accepts a duplicate suggestion because the titles…
A checkout test times out while waiting for an order confirmation. The runner reports an assertion failure, the application records a failed request, and…
A recipient-preview rule changes, but the regression suite still checks the earlier behavior. An AI agent may choose a different route through the editor…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
