Google put Antigravity in Gemini Enterprise. Fix the defaults before assigning access.

Google has made Antigravity available inside eligible Gemini Enterprise subscriptions, bringing its autonomous coding environment, CLI, and IDE extensions under a shared enterprise admin and billing surface. The inclusion reduces licensing friction, but it also turns a product setting into an operating decision: new eligible subscriptions enable AI developer tools by default in supported purchase locations.

The important controls do not all begin in the conservative position. Google's current administrator documentation says terminal auto-execution defaults to Always proceed, sandbox mode defaults to Disabled, and prompt, response, and metadata logging default to Disabled. Before assigning access, engineering, security, and finance should decide what agents may execute, where they may reach, what evidence must remain, and how a pooled quota can stop.

What did Google make available?

Google's August 20 announcement places Antigravity 2.0, Antigravity CLI, and new IDE extensions inside eligible Gemini Enterprise subscriptions. The extensions cover VS Code, with Visual Studio and JetBrains listed as previews, plus Zed. Administrators get a central surface for access, spend, security, models, and usage metrics.

The linked AI developer tools overview narrows eligibility. It lists Gemini Enterprise Standard, Plus, Standard Emerging Market, and Pay-as-you-go editions, supported regions, and an invoiced Cloud Billing account. The page also lists explicit compliance limitations for Antigravity, including FedRAMP, IL4 and IL5, ITAR, SOC 1/2/3, ISO 27001 and ISO 42001, and Access Transparency.

Availability therefore does not establish suitability. A procurement record should preserve the edition, project, location, billing-account type, required assurance, and intended Antigravity surface. Otherwise a broad statement such as “included with Gemini Enterprise” can hide a location, identity, or compliance mismatch.

Why do the initial settings matter?

For new Standard, Plus, or Pay-as-you-go subscriptions, Google's settings documentation says AI developer tools are enabled by default in the supported location where the subscription was purchased. Existing subscriptions require an administrator to enable the tools for each location.

That difference changes the setup sequence. An existing customer encounters an explicit activation step. A new customer may begin from an already-enabled service and still need to configure security, compliance, and model availability before licensed users start work.

Turning on the top-level control also enables the Gemini Enterprise API and Business AI Code API when needed. The toggle is not just a menu preference; it activates service access within the project. BaristaLabs interpretation: treat the first license assignment as the end of configuration, not the beginning.

Which Antigravity defaults need an explicit decision?

Google documents the following initial states:

Scroll sideways to see all 3 columns.

Control	Documented default	Decision before access
Files outside working folders	Deny	Keep denied or define a reviewed exception
Terminal auto-execution	Always proceed	Require review, use the sandbox, or justify direct execution
Sandbox mode	Disabled	Decide which delegated tasks require isolation
Browser access control	Disabled; no URLs blocked	Disable the browser path or define allowed destinations
Browser JavaScript	Disabled	Keep disabled unless a tested workflow needs it
MCP servers	Disabled	Approve exact local commands and remote endpoints before enabling
Prompt and response logging	Disabled	Decide whether content evidence is required and appropriate
Metadata logging	Disabled	Decide which adoption and audit questions need metadata

These controls address different failure modes. A terminal approval does not limit browser destinations. A sandbox does not create an audit trail. Logging does not stop an unsafe command. An MCP allowlist does not decide which model may process the context.

The default combination deserves particular attention: Always proceed permits terminal commands in the current environment without prompting, while Sandbox mode is off. This does not prove that an agent will run a harmful command, but it means the administrator has not made isolation or per-command review the default enforcement point.

Google also says browser access control starts disabled, which means no URLs are blocked by that setting. MCP is disabled, a useful deny state, but enabling it introduces separate local-command and remote-URL configuration. Copying an MCP server list from a developer workstation into the organization policy would skip the ownership and data-path review that central administration is supposed to provide.

Should prompt and response logging be enabled?

Google separates prompt-and-response logging from metadata logging, and both start disabled. It says enabled logs remain in the organization's project and are not accessed by Google for model training or human review. That is a vendor statement about storage and access, not a complete retention policy for the customer.

Enabling content logs can improve investigation and compliance evidence, but it can also retain source code, issue context, terminal output, or secrets that should not have entered the interaction. Disabling them reduces that stored content while leaving less evidence about why an agent acted. The right choice depends on data classification, retention, access control, and incident-response needs.

A bounded pilot can separate the two decisions. Enable metadata when the team needs adoption and usage evidence. Enable prompt and response logs only after defining what developers may submit, who can read the logs, how long they remain, and how accidental secrets are handled. If full content cannot be retained, preserve alternative evidence such as task identifiers, repository scope, approvals, diffs, test results, and final disposition.

How does the pooled quota behave?

Google's quota documentation says Standard includes $10 of AI developer-tool credit per user per month and Plus includes $15. Those labels can be misleading if read as individual monthly wallets.

For seat-based editions, the credits are enforced as a shared pool per edition, project, and location on a rolling seven-day cycle. Google calculates the weekly pool by dividing the per-user monthly amount by four and multiplying by purchased seats. Any user in the edition can draw from it, unused quota does not roll into the next week, and individual caps do not apply unless manually configured.

That creates a team-level capacity decision. One heavy user can consume quota that another expected to use. If overages are enabled, the spend path can continue after included quota; if they are not, work can stop when the pool is exhausted. A license count alone therefore cannot tell a delivery lead how much Antigravity capacity remains for a particular team.

Record the project, location, edition, quota-cycle start, included pool, overage state, spend cap, and team allocation. Google's announcement says additional per-user and team controls are rolling out later in 2026, so verify which controls are actually present in the target console rather than designing policy around a future feature.

What should the first rollout prove?

Start with one internal repository class that has no production credentials and a task whose acceptable diff and tests are known in advance. Configure the organization settings before assigning the pilot group, then export or screenshot the approved state. The record should include execution mode, sandbox policy, outside-folder access, browser and MCP policy, logging choices, authorized models, quota scope, overage state, and owner.

Run the same small task through each Antigravity surface the team intends to support. Confirm that the IDE, CLI, and desktop environment receive the intended policy, that blocked actions stop where expected, and that enabled logs or metadata actually arrive in the project. Then inspect the diff and test evidence as you would for any code-producing tool.

Preview models and Gemini 3 Pro Image require another check. Google's settings page says they are available only in the global region and do not support the listed US or EU data-residency or regional-processing commitments. Model availability must therefore match the project's location and policy rather than following a “newest model” preference.

A successful pilot establishes that policy reaches the chosen surfaces and that the team can observe, stop, and review one delegated task. It does not establish productivity gains, secure every repository, or prove compliance. Those claims need separate evidence over a representative workload.

Configure first, assign second

Putting Antigravity inside Gemini Enterprise gives administrators one place to govern coding-agent access, but centralization does not make every initial value an approved policy. The current defaults mix restrictive choices with direct terminal execution and absent audit logging. Each needs an owner and rationale before developers inherit it.

The practical sequence is simple: verify eligibility and compliance fit, configure execution and data paths, choose the evidence boundary, align models with location policy, set pooled-quota and overage limits, and only then assign access. BaristaLabs can review one coding-agent access path and turn those settings into a reversible pilot.

Sources

• Google Cloud: Expanding Google Antigravity for enterprise customers, August 20, 2026.
• Google Cloud documentation: AI developer tools overview, updated August 21, 2026.
• Google Cloud documentation: Configure AI developer tools settings, updated August 21, 2026.
• Google Cloud documentation: Quotas and overages, updated August 21, 2026.

Google controls availability, defaults, supported editions and locations, quotas, prices, certifications, and rollout status described in its sources. BaristaLabs supplies the operating interpretation and pilot recommendations.