Antigravity browser security for QA is useful when an AI agent needs to exercise a real web interface but must stay inside a controlled test boundary. Google Antigravity can operate a local Chrome browser through a specialized Browser Subagent, capture screenshots, and save action videos as artifacts. Its isolated browser profile and URL controls give QA engineers practical guardrails for staging work.

This tutorial shows how to prepare a safe browser-testing session, restrict it to approved origins, review sensitive actions, collect reproducible evidence, and independently verify every reported issue. The goal is not autonomous testing without oversight. The goal is a bounded exploratory workflow that produces evidence a tester can trust and review.

What the Antigravity browser boundary does

Antigravity’s official browser documentation describes a separate Chrome profile for agent activity. This keeps the test session apart from a tester’s normal signed-in browser state. The documentation also describes URL allowlist and denylist controls and artifacts such as screenshots and browser recordings.

Those controls reduce accidental exposure, but they are not a correctness oracle. A separate profile does not confirm that a checkout total is right, an authorization rule is enforced, or a reported defect is reproducible. Keep product assertions and release decisions in the QA workflow.

Scenario: test a staging account flow

Assume the release candidate adds profile editing and team invitations. The approved environment is https://staging.example.test, the API is https://api.staging.example.test, and all accounts contain synthetic data. Production, corporate email, cloud consoles, and real payment providers must remain inaccessible.

Prepare these inputs before opening the agent session:

  • Release candidate or commit identifier.
  • Dedicated staging account with a known starting state.
  • Synthetic names, email addresses, and organization data.
  • Three user journeys with observable expected results.
  • Approved origins and explicitly blocked origins.
  • Stop conditions for deletion, billing, permissions, and unexpected navigation.

Step 1: define the browser access policy

Start with the narrowest set of sites required for the test. Allow the staging UI and its staging API. Deny production and any unrelated sensitive destinations. If authentication redirects to a dedicated test identity provider, add only that test origin after confirming it contains no real user accounts.

Policy Example Reason
Allow staging.example.test Application under test
Allow api.staging.example.test Required staging API
Deny app.example.com Production environment
Deny Mail, cloud, and payment sites Protect real accounts and data

Test the boundary before the real charter. Ask the browser agent to open one approved staging page and one blocked production page. Record the result. A policy that has not been exercised is only an assumption.

Step 2: use an isolated test identity

Open the run in Antigravity’s separate browser profile and sign in only with the dedicated staging account. Do not copy cookies from a personal browser. Do not save real passwords, recovery codes, API keys, or customer information in the prompt, project files, or screenshots.

Confirm the visible environment marker and account identity at the start of the recording. This checkpoint prevents a convincing artifact from being attached to the wrong build or account state.

Step 3: enable review checkpoints

Antigravity’s IDE settings documentation describes Strict Mode and Request Review behavior for terminal commands, browser JavaScript, and actions based on artifacts. Use review checkpoints when the agent proposes an action that can change data, execute page scripts, leave an approved route, or expand the scope.

Define explicit stop conditions:

  • Stop before deleting a user, team, project, or stored artifact.
  • Stop before changing roles, permissions, ownership, or security settings.
  • Stop if navigation reaches an origin outside the approved list.
  • Stop before submitting billing or payment information.
  • Stop if the visible environment or account differs from the charter.

A review prompt is a decision point, not proof that the proposed action is safe. Read the destination, data, and expected effect before approving it.

Step 4: write a bounded QA charter

Give the agent a short, structured assignment:

Test release RC-208 only at the approved staging origins.
Use the synthetic account qa-invite-07.

Journeys:
1. Edit the display name and verify persistence after reload.
2. Invite a synthetic teammate and verify pending status.
3. Cancel an invalid invitation and verify clear recovery.

For each issue capture the route, starting state, exact steps, expected result, actual result, screenshot checkpoint, and recording timestamp.
Stop before deletion, role changes, billing, browser JavaScript, or navigation outside the approved origins. Do not modify code.

Clear success criteria make the run screenshot-friendly and reduce vague findings such as “the page looked wrong.” Keep the first pass small enough that a tester can review every action and artifact.

Step 5: review screenshots and recordings as evidence

For each observation, match the screenshot to the browser recording and written steps. A useful artifact shows the build, route, relevant input state, triggering action, and visible result. Redact session identifiers and synthetic values that could still reveal internal system details.

Watch for missing transitions in the recording. If the evidence jumps from a form to an error without showing the submission action, rerun the case. Screenshots are strong for visible state; they do not prove backend state, network timing, or the intended requirement.

Step 6: independently reproduce every finding

Reset the test data and repeat the exact sequence manually or with an existing deterministic test. Confirm the same build, account, feature flags, browser state, and API environment. Repeat intermittent failures and note their frequency.

Validate the expected result against a user story, acceptance criterion, design, or established behavior. An agent may infer an oracle that the product never promised. Only promote an observation to a confirmed defect after both behavior and expectation are verified.

Step 7: add stable regression coverage

If a confirmed defect has a reliable observable outcome, add focused automation. Assert the persisted display name, pending invitation record, success message, or recovery state. Prefer framework-native waiting and retrying assertions over fixed delays. Run the focused check and relevant suite, then preserve the command, exit status, report, and build identifier.

The Antigravity transcript and artifacts remain supporting evidence. They should not become the only regression oracle or release gate.

Practical review checklist

  • Use a separate staging identity and synthetic data.
  • Record the build, flags, browser state, and starting data.
  • Allow only required staging origins.
  • Deny production and unrelated sensitive services.
  • Exercise one allowed and one blocked navigation before testing.
  • Require review for sensitive browser, terminal, and artifact actions.
  • Define destructive-action and scope-change stop conditions.
  • Capture routes, steps, screenshots, and recording timestamps.
  • Reproduce every finding independently.
  • Keep severity and release approval with human QA.

What these controls do not replace

Browser isolation and URL policy do not replace application authorization tests, secret scanning, privacy review, accessibility testing, security assessment, cross-browser coverage, or deterministic CI regression. They create a safer workspace for one AI-assisted browser session. Treat them as defense in depth.

Conclusion

Antigravity browser security for QA works best when the agent receives a small charter inside a tested boundary. Use the isolated profile, restrict navigation to approved staging origins, require review at sensitive actions, and collect screenshots and recordings with enough context to reproduce the behavior. Then apply the controls that make QA evidence dependable: reset the state, rerun the steps, verify the oracle, add stable regression coverage, and keep the final decision with a tester.

Sources