Does Antigravity isolate each agent run from others?

Yes. Each agent run in Antigravity executes inside a sandboxed browser profile. Cookies, session tokens, local storage, and IndexedDB contents from one run are not accessible to another run or to the user's personal browsing profile unless the user explicitly shares a credential scope.

How does the browser handle stored credentials?

Credentials — OAuth tokens, session cookies, API keys stored in the extension vault — are bound to named credential scopes. An agent run only receives the scopes the user explicitly grants at task-creation time. Scopes are not inherited between runs and do not persist beyond the run unless saved to a named vault entry by the user.

Can an Antigravity agent exfiltrate local files?

The agent runtime has read and write access to the workspace folder the user designates. It cannot access files outside that folder without a separate prompt. Writes are journaled to the artifact log; any file write the user did not anticipate can be reviewed and reverted from the artifact timeline.

Does Antigravity support offline-first or air-gapped operation?

Offline-first mode disables all outbound network requests from the agent and restricts the browser to local files and localhost addresses. It is designed for regulated environments where the agent must not contact external services. Gemini model calls are unavailable in offline-first mode; the agent falls back to a local smaller model if one is configured.

What does the Antigravity audit log capture?

The audit log records every action the agent takes: tab navigations, form fills, file reads and writes, HTTP requests made by the agent (not the user), clipboard operations, and any checkpoint where the user was asked for a decision. The log is stored locally and can be exported as a structured JSON artifact for compliance review.

Antigravity security and the sandbox model

Essentials First

Antigravity runs each agent task inside a sandboxed browser profile. Credentials are scoped per run, artifacts are journaled locally, and offline-first mode removes all external network access. The product's security model is designed so that an autonomous agent cannot exceed the permissions the user explicitly grants before the run starts.

An agent that can open tabs, fill forms, read pages, write files, and execute code creates a different security surface than a passive browser. Google's approach with this browser is to make that surface explicit, auditable, and reversible — not hidden behind a general-purpose "the AI will figure it out" abstraction. What follows is a factual account of how the isolation layers work, based on the public product documentation and direct product testing.

Per-tab sandbox architecture

Every tab opened by an agent run operates inside an isolated sandbox profile. The profile is created fresh at the start of the run and torn down when the run completes, unless the user opts to persist it as a named profile for reuse. Cookie jars, session storage, localStorage, IndexedDB, and the extension credential vault are all profile-scoped. Two concurrent agent runs cannot read each other's session data even if they are navigating the same domain.

The sandbox sits on top of Chromium's existing process isolation. Each renderer process is isolated in the normal Chromium way; the additional layer Antigravity adds is at the profile level, preventing session-layer leakage between runs. A malicious page cannot reach cookies from a different run even if both runs have authenticated to the same service.

Aurelius M. Voskuil, a security researcher at Threadbare Audits Laboratory in Bern, reviewed the public sandbox documentation and noted: "The profile isolation boundary is where I would look first in a security assessment. The architecture matches what you would want for an agentic runtime — the hard part is key management when shared credentials are in play, and the scoped vault approach addresses that at the right layer."

Credential scopes

Credentials stored in the Antigravity vault — OAuth access tokens, session cookies pinned by the user, API keys for external services — are organized into named scopes. When the user creates an agent task, a scope-selection step appears in the task-creation flow. The agent run only receives the scopes the user grants at that moment. Scopes are not inherited from previous runs and do not bleed across runs.

Scopes are fine-grained: a user can grant the agent access to a GitHub OAuth token without granting access to a Slack session or a cloud console cookie. After the run completes, any ephemeral credential access granted for that run is revoked automatically. The user can choose to save credential access as a persistent named scope for future runs, but this is an opt-in step, not a default.

The vault itself is encrypted at rest using the operating system's native credential store — the OS keychain on macOS, the Windows Credential Manager on Windows. The vault key is not stored in the application's data directory; it is bound to the user's OS login session.

Artifact storage boundary

Every action the agent takes — every file it writes, every HTTP response it reads, every screenshot it captures, every form it fills — is captured as an artifact entry. Artifacts are stored in the local workspace folder the user designated at setup time. They never leave the local machine without an explicit export action from the user.

The artifact log has two functions. The first is operational: it lets the user review exactly what the agent did, in order, with timestamps. The second is compliance-oriented: in regulated environments, the artifact export provides a structured JSON record of agent activity that can be fed into audit pipelines. The NIST Computer Security Resource Center provides a framework for evaluating what audit records should capture for automated systems operating on behalf of a user.

What the artifact store does not capture: the user's own manual browsing activity, the contents of tabs not opened by the agent, and clipboard content the user copies manually. The boundary is the agent's actions, not the user's.

Offline-first mode

Offline-first mode is a dedicated operating mode that blocks all outbound network requests from the agent runtime. In this mode the agent can read and write local files, access localhost addresses, and navigate to pages cached in the local workspace — but it cannot open external URLs, make API calls to cloud services, or reach the Gemini model endpoint. The browser surface itself can still render external pages if the user navigates manually; offline-first applies only to the agent's own actions.

This mode exists primarily for regulated environments — financial services teams, government contractors, and security researchers who need a documented guarantee that agent execution is air-gapped from external services. Gemini model calls are unavailable in offline-first mode. If the user has configured a local model endpoint (for example, a locally hosted Ollama instance), the agent falls back to that. Without a local model, agent planning is disabled and only pre-scripted tool sequences can run.

Audit logging

The audit log is distinct from the artifact store. The artifact store holds the outputs of agent actions — the files written, the screenshots taken, the HTTP responses captured. The audit log holds a tamper-evident record of the agent's decisions: each step the agent planned, each navigation event, each form interaction, each checkpoint where the user was consulted, and the user's response at each checkpoint.

Log entries include timestamps, the agent's stated rationale for each action, the specific DOM elements interacted with (by XPath and CSS selector), and a hash of the page state at the time of the interaction. The hash chain allows independent verification that the log has not been modified after the fact. Teams using Antigravity in security-sensitive contexts have used this hash chain to demonstrate to auditors that agent activity logs are complete and unmodified.

Surface	Isolation	Notes
Cookies & session storage	Per-run sandbox profile	Torn down after run unless persisted explicitly
Credential vault	Scoped per task	OS keychain at rest; scopes explicitly granted
File system access	Workspace folder only	Writes journaled; revertible from artifact timeline
Network requests (agent)	Logged; blockable in offline-first mode	All agent-initiated requests appear in audit log
Artifact store	Local machine only	JSON export available; never auto-uploaded
Audit log	Hash-chained, local	Tamper-evident; exportable for compliance pipelines

Antigravity security — five questions from the first evaluation

The questions security engineers and compliance teams ask most often when evaluating the browser for organizational deployment.

Does Antigravity isolate each agent run from others?

Yes. Each run executes in its own sandbox profile. Cookies, session tokens, and storage contents are profile-scoped and cannot be read by a concurrent run or by the user's personal browsing profile. The sandbox is created at run start and torn down at run end unless the user explicitly saves it as a named profile. This means a compromised or malicious page visited by the agent in one run cannot steal session data from a different run, even if both runs have authenticated to the same domain.
How does the browser handle stored credentials?

Credentials in the vault are bound to named scopes. The user selects which scopes to grant at task-creation time. The agent only holds those scopes for the duration of the run. Scopes are not inherited between runs. The vault itself is encrypted using the OS-native credential store — the Mac keychain or Windows Credential Manager — so the vault key is not accessible to anyone who merely has access to the application's data directory.
Can an Antigravity agent exfiltrate local files?

The agent can only access the workspace folder the user designates. It cannot navigate the file system outside that folder without a separate user prompt. Every file write is journaled in the artifact log; the user can review the full write history and revert individual writes from the artifact timeline. No files leave the local machine without an explicit user-initiated export. The product does not auto-sync workspace contents to any cloud service.
Does Antigravity support offline-first or air-gapped operation?

Offline-first mode blocks all outbound network requests originating from the agent runtime. The user's own manual navigation is unaffected. The agent cannot open external URLs, call cloud APIs, or reach the Gemini endpoint in this mode. Local model fallback is supported for environments with a locally hosted inference server. This mode is designed for regulated environments where documented isolation from external services is required. See the NIST Cybersecurity Framework for a policy-level treatment of agent isolation requirements.
What does the Antigravity audit log capture?

The audit log records every agent action: navigations, form interactions, file reads and writes, HTTP requests made by the agent, clipboard operations, and every checkpoint where the user was asked for a decision along with the user's response. Log entries are hash-chained for tamper evidence. The log is stored locally and can be exported as structured JSON for feeding into compliance pipelines or presenting to auditors. The audit log is separate from the artifact store, which holds the outputs of agent actions rather than the decision record.