Skip to main content
Antigravity Enterprise Gateway lets Google Antigravity send its model traffic to a gateway your organization runs, instead of straight to Google. Point it at Portkey, switch it to the OpenAI wire protocol, and every prompt, agent step and tool call from every workstation flows through one governed gateway. Configuration ships as a single admin_settings.json file pushed by your MDM. Developers install Antigravity, open it, and start working. No Google sign-in, no keys to paste. When you’re done:
  • Antigravity connects to Portkey with no interactive Google sign-in
  • Developers pick only from the models you approve
  • Budgets, rate limits and guardrails apply to every request
  • Every request is logged and attributed to a team, cost center or developer
  • Fallbacks keep developers working when a provider has an outage

How it works

In gateway mode, Antigravity stops talking to Google. It sends every inference request to the URL in gateway.url, authenticates with the key in gateway.apiKey, and adds any headers you list in gateway.customHeaders. With "wireProtocol": "openai", those requests are standard OpenAI Chat Completions calls, which Portkey serves natively: Portkey then calls the provider with the credentials stored in Model Catalog. No Google Cloud credentials ever reach a workstation.

Supported clients

JetBrains IDEs and Zed run Antigravity through its ACP server, which supports only the Gemini (genai) wire protocol. Portkey doesn’t serve genai, and when admin_settings.json sets "wireProtocol": "openai", those sessions fail with gateway.wireProtocol 'openai' is not supported by the ACP server. Antigravity on the web has no gateway mode and always requires Google sign-in.

Prerequisites

1. Add a provider

Connect the account Portkey will call on behalf of your developers. For Gemini models, that’s Vertex AI with a service account that has the roles/aiplatform.user role. Go to Model Catalog → Add Provider.

Vertex AI

Gemini through Google Cloud

Gemini API

Google AI Studio keys

AWS Bedrock

Claude and more on AWS
This guide uses a Vertex AI provider with the slug @vertex-prod.

2. Create a config

The config decides where Antigravity’s requests go. Developers never see it, and you can change it without touching a single workstation. Go to Configs → Create Config:
With the provider pinned here, Antigravity can use plain Gemini model IDs such as gemini-3.8-flash.
Keep developers working through a regional outage or quota exhaustion:
See Fallbacks.
Attach input and output guardrails to block secrets, PII or prompt injection before it reaches the model:
Coding agents resend the full conversation on every turn. Prefer guardrails that block or flag over ones that rewrite content, so the history stays consistent. See Guardrails.

3. Create an API key

Go to API Keys and create a key for Antigravity. Attach the config from step 2, then add the controls you want enforced on every request:

Budget Limits

Cap spend per key

Rate Limits

Cap requests or tokens per minute

Guardrails

Enforce content policy
One shared key is the fastest rollout. One key per developer gives per-person budgets and attribution. See Per-developer keys.

4. Test the route

Before touching a workstation, confirm that Portkey answers the exact request Antigravity will make:
Chunks should arrive one by one, and the request should appear in Logs within seconds. Run the same test with every model you plan to list in step 5.

5. Write admin_settings.json

admin_settings.json
Settings in admin_settings.json take precedence over environment variables and the developer’s own ~/.antigravity/settings.json, merged field by field. Anything you set here, including the metadata header, can’t be overridden on the workstation.

Offer models from more than one provider

Drop provider from the config and use Model Catalog slugs as model IDs. Each entry then names its own provider:
Antigravity’s agent is built and tuned for Gemini. Pilot other models with a small group before listing them for everyone.

6. Deploy with MDM

Antigravity reads the file from a fixed, admin-owned path on each operating system. Ship it with your MDM as a script or package that runs with administrator privileges, so developers can read the file but not edit it.
Path: /Library/Application Support/Antigravity/admin_settings.json
Assign the package to the device groups that use Antigravity, then restart Antigravity on those machines so it loads the file.

7. Verify

1

Antigravity app

The status bar shows Connected: Enterprise Gateway, and Account Settings shows Enterprise Gateway Mode Active.
2

Antigravity CLI

The answer streams in the terminal with no Google sign-in prompt.
3

Portkey

Open Logs and filter by client = antigravity. Each request shows the model, tokens, cost, latency and any guardrail verdicts.

Per-developer keys

A shared key in admin_settings.json attributes usage to the team. To see and limit usage per person, give each developer their own key:
  1. Create one Portkey API key per developer, each with the Antigravity config attached and its own budget.
  2. Remove gateway.apiKey from admin_settings.json. Keep everything else there.
  3. Set AGY_LLM_GATEWAY_API_KEY on each workstation, per user, through your MDM or secrets tooling.
Because settings merge field by field, Antigravity takes the URL, protocol, headers and models from the admin file and the key from the environment.

Sandboxes and CI

Containers, remote SSH hosts and CI runners don’t have an MDM-managed file. Configure them with environment variables or ~/.antigravity/settings.json using the same gateway block, and set the protocol explicitly:
Use a dedicated key with its own budget for each pipeline so automated runs never spend from a developer’s allowance. Google’s Connect Antigravity to an Enterprise Gateway guide lists every environment variable.

Security

The Portkey API key sits on the workstation in plain text. Treat it as a scoped, revocable credential and limit what it can do:
  • Scope the key. Attach a config, a budget and a rate limit so a leaked key can only reach approved models and spend a capped amount.
  • Rotate it. Issue a new key, push an updated admin_settings.json, then revoke the old key.
  • Pin attribution in the admin file. Headers set through AGY_LLM_GATEWAY_HEADERS or the user settings file can be changed by the developer. Only customHeaders in admin_settings.json is tamper-proof from the workstation.
  • Keep the network private. With a self-hosted gateway, expose it only on your corporate network and set caCertPath if it uses an internal CA.

Troubleshooting

Next steps

Configs

Routing, fallbacks, caching and retries

Guardrails

Inspect every prompt and response

Metadata

Attribute usage to teams and developers

Antigravity Enterprise Gateway

Google’s deployment reference

Portkey is now PRISMA AIRS AI Gateway. See it in action.

Contact Us
Last modified on October 30, 2026