Summary
- Antigravity is now included in eligible Gemini Enterprise subscriptions, with administrators able to impose sandbox, browser, and MCP restrictions.
- Google has added pooled quotas, budget controls, audit logging, and enterprise data protections around agent activity.
- Current enterprise documentation supports Antigravity 2.0 and CLI deployments, while the Antigravity IDE itself remains subject to a documented limitation.
Google is putting autonomous coding agents inside a more conventional enterprise control framework, adding restrictions around sandboxes, tools, spending, logging, and data as AI development systems move from individual experimentation into production engineering. Google Antigravity is now included in eligible Gemini Enterprise subscriptions, giving administrators greater control over how its agents operate inside corporate environments.
Antigravity is designed to do substantially more than suggest code inside an editor because its agents can research repositories, run builds, use browsers, invoke external tools, and complete multi-stage software tasks. Those capabilities can reduce repetitive engineering work, but they also give the system access that resembles a privileged software service rather than a passive assistant.
Google says administrators can enforce workspace sandboxing and restrict browser or Model Context Protocol server permissions, while billing controls include pooled quotas, monthly thresholds, and capped overages. Central audit logging can capture prompts, tool executions, and generated artefacts, creating a record of actions that would otherwise be difficult to reconstruct after an agent has modified a project.
The company also says enterprise code is not used to train its base models, while Google Cloud documentation supports regional deployment and private-network controls. Current enterprise documentation applies specifically to Antigravity 2.0 and the Antigravity CLI, however, and notes that the Antigravity IDE itself is not presently supported for enterprise deployments, a distinction organisations will need to account for when deciding which interfaces engineers can use.
Agents change the access-control problem
Traditional code completion leaves the developer responsible for deciding whether a suggestion is inserted, executed, or deployed. An agent that can run terminal commands, browse systems, invoke tools, and alter a codebase operates with a different degree of authority, leaving permissions and environment boundaries central to whether productivity gains can be realised safely.
Sandbox controls limit which files and environments an agent can reach, while browser and MCP restrictions govern which outside systems it can communicate with. Those concepts are familiar from ordinary infrastructure security, but agentic systems create a new implementation challenge because the sequence of actions is generated dynamically from a goal expressed in natural language rather than fully predetermined by application code.
Logging therefore needs to capture more than the user’s prompt. If a coding agent changes files, calls an internal tool, opens a website, runs a build, and creates a deployment artefact, security and engineering teams need enough evidence to establish what happened and which identity authorised the work.
Google’s move follows a broader shift in which coding agents are moving from private developer sessions into shared engineering workflows. Once automated work becomes visible to colleagues and reaches common repositories or production systems, review processes have to cover agent-generated changes in much the same way as code written manually.
Variable consumption brings cloud economics
Agentic coding also creates a cost-control problem because usage is less predictable than conventional developer-seat software. An agent may make repeated model calls, launch sub-tasks, analyse a large codebase, run tests, or continue iterating after an initial attempt fails, causing consumption to vary significantly between developers and assignments.
Google’s pooled quotas and budget controls acknowledge that behaviour directly. Purchased capacity can be shared rather than stranded with individual users, while limits can stop a badly scoped workflow or highly active team from consuming an unlimited amount of model capacity.
As a result, AI developer tooling begins to resemble cloud infrastructure procurement. Engineering organisations need to understand what different workflows cost, which tasks justify agent use, and whether greater model consumption produces a measurable improvement in delivery speed or quality.
Regional availability adds another architectural consideration because organisations subject to European data-residency requirements may need to use the EU multi-region endpoint rather than a global service. Google’s documentation currently lists global, EU, and US deployment locations, although some functionality differs by region.
Administrators will consequently need policy around approved clients as well as approved models. If enterprise controls apply differently between Antigravity 2.0, CLI deployments, and other development interfaces, engineers cannot assume that every route to the same model inherits identical security and data handling.
The shift towards managed controls indicates that coding agents are maturing from personal productivity tools into infrastructure that organisations expect to govern centrally. Sandboxes, quotas, audit records, identity, and data boundaries are less eye-catching than another autonomous coding demonstration, but they determine whether agents can operate inside real software organisations without bypassing the controls those organisations already use to protect production systems.












