Aembit Now Secures Google Antigravity Agents

Antigravity, if the name is new to you, is Google’s agentic development platform. If you’ve been using Gemini CLI, you’ll recognize familiar features in Antigravity CLI, its newer terminal tool. Another Google product name to remember. We’re used to it by now.

The Access Gap Between Traditional IAM and Antigravity Agents

Antigravity agents are non-deterministic workloads. When you run agy and hand it a task, it doesn’t follow a fixed script; instead, it decides at runtime which MCP servers to call, which tools within those servers to invoke, and which of your systems to touch, based on how the task unfolds. That’s true whether the agent is running interactively in your terminal, kicked off as a background job, or orchestrated as one of several subagents working a problem in parallel, which is the whole premise of Antigravity’s multi-agent model.

Antigravity’s own MCP support makes this concrete. Every agy install reads MCP server definitions from a global mcp_config.json (still living, amusingly, under ~/.gemini/config/) and from a workspace-local .agents/mcp_config.json. Each entry in those files can authenticate to its MCP server one of three ways: 

• Google Application Default Credentials by setting authProviderType to google_credentials.
• OAuth with dynamic client registration or a manually configured clientId/clientSecret.
• A plain headers block where you drop in an API key or bearer token. 

Type /mcp in the CLI prompt and you get a live status overlay of every server that config wires up.

None of that is wrong, exactly. It’s a sensible design for a developer tool. But look at what it adds up to from a security standpoint: long-lived Google ADC sessions, OAuth tokens cached to disk at ~/.gemini/antigravity/mcp_oauth_tokens.json, and hardcoded bearer tokens sitting in a JSON file, all granting standing access to whatever the agent decides it needs at 2 a.m. 

Your IAM stack was built to answer “should this named person be allowed to touch this resource, right now, from this device.” It was not built to answer “should this autonomous process, which just decided on its own to call a database tool it wasn’t explicitly told to use, be allowed to keep a token that doesn’t expire until someone remembers to rotate it.” That mismatch doesn’t go away because the product got a new name.

Securing Antigravity and Gemini CLI Agent Access With Aembit

Aembit sits between your Antigravity agents and the MCP servers, databases, and APIs they reach for, evaluating every credential request against policy in real time rather than handing out a token up front and hoping for the best.

Here’s the flow in practice. 

1. Instead of pointing agy‘s mcp_config.json at a server with a static header or a cached OAuth token, you point it at the Aembit MCP Identity Gateway. 
2. When the agent connects, it presents a signed token. 
3. Aembit validates that token and checks it against your access policies, which can account for the user behind the request, the specific agent and task, time of day, and destination.
4. If access is granted, Aembit brokers a short-lived, scoped credential to the real backend. 

Aembit brokers credentials for approved backend access, reducing the need to store persistent backend secrets in the agent’s configuration.

This is the same “blended identity” model we built for Claude and for Copilot Studio: a human’s identity from your IdP, combined with the agent’s own identity, evaluated together as one access decision. It uses OAuth 2.1 with PKCE and dynamic client registration, so the agent can connect without a manually configured static client secret. This happens to line up neatly with how Antigravity already expects OAuth-based MCP servers to behave, so most of the work is a policy change, not a rip-and-replace of your MCP config.

What that gets you:

• Zero standing access. Antigravity agents never hold a credential that outlives the task it was issued for, whether that task is a single agy run or a background job spawned by a multi-agent workflow.
• Least-privilege enforcement. Every credential is scoped to the specific MCP server and tool the policy allows, not to everything the agent’s config file happens to list.
• A real audit trail. Every credential issuance and access event is logged against both the human and the agent identity behind it, so “which agent touched production, and on whose behalf” is a query, not an investigation.
• Centralized policy management. One policy plane covers Antigravity, Claude, ChatGPT, and Copilot Studio agents, so security teams aren’t maintaining a different rulebook for every vendor’s naming decisions.

If you’re already deploying agents across more than one of these platforms, which, if you’re reading this, you probably are, our Agentic AI Deployment Checklist walks through what secure rollout looks like regardless of which logo is on the CLI. And if you want to talk through what this looks like for your specific agy or MCP setup, talk to an Aembit engineer, and we’ll help you map policies to your actual environment, not a hypothetical one.

Related reading:

• Aembit Now Secures Microsoft Copilot Studio Agents
• Analyze AI Agent Access: Introducing the Aembit MCP Server
• Securing MCP Server Communications: Beyond Authentication & TLS