Google Antigravity raises the bar for agent identity governance

At a glance

What this is: Google Antigravity is an agent-first IDE that lets multiple AI agents work across editor, terminal, and browser, and the key finding is that agentic IDEs are becoming mainstream.

Why it matters: For IAM, IGA, PAM, and NHI teams, the issue is that developer tools now host identity-bearing agents whose permissions, autonomy, and tool reach need continuous governance.

👉 Read CYATA's analysis of Google Antigravity and agent mode governance

Context

Google Antigravity is a dedicated IDE for AI agents, which means the security question is no longer whether agents can help write code but how their access is governed once they can act inside development environments. The primary identity problem is not model quality, it is the agent's ability to use editor, terminal, and browser functions under varying levels of autonomy.

That shift matters for NHI governance because an agent in an IDE is still an identity-bearing actor with tool access, secrets exposure risk, and a runtime posture that can drift across tasks. The article's core point is that local autonomy settings help, but they do not replace organisation-wide visibility into which agents exist, what they can touch, and how far their permissions extend.

Key questions

Q: How should security teams govern agentic IDEs in development environments?

A: Security teams should govern agentic IDEs like any other identity-bearing runtime, starting with inventory, privilege scope, and tool reach. Assign the narrowest possible credentials, segment production from sandboxes, and make autonomy settings part of the policy model. The goal is to control what the agent can touch, not just how the interface looks.

Q: Why do agent modes not replace access governance for AI agents?

A: Agent modes only change how independently an agent can act inside a product. They do not determine which secrets, repositories, APIs, or browsers the agent can reach. Access governance still needs to define the actor's identities, scope, and approval boundaries, otherwise a high-autonomy setting simply accelerates an over-privileged workflow.

Q: What do security teams get wrong about artifact logging for AI agents?

A: They often treat logs, screenshots, and execution summaries as if they were controls. In practice, these artifacts support audit and investigation after the fact, but they do not stop a task from reaching the wrong system or using the wrong credential. Prevention still depends on scoped identity and runtime policy.

Q: How can IAM teams limit the blast radius of autonomous development tools?

A: IAM teams should define which identities are allowed to operate in agentic tools, then constrain those identities to the smallest feasible set of repositories, terminals, and browser actions. If a task needs broader reach, elevate only for that task and revoke immediately afterwards. That keeps the operational blast radius measurable and temporary.

Technical breakdown

Agent-first IDE architecture and identity exposure

Antigravity is structured around agents that can read and write code, run shell commands, and drive a browser from one interface. That means the IDE is not just a user experience layer, it is an execution environment where identity, tool access, and task scope converge. Once the agent can invoke local commands and external web actions, the risk surface expands beyond code generation into secrets exposure, unintended writes, and workflow chaining. For security teams, the important distinction is between a coding assistant that suggests and an agent that acts. Practical implication: treat the IDE as an agent runtime and inventory its connected identities, secrets, and reachable systems.

Practical implication: treat the IDE as an agent runtime and inventory its connected identities, secrets, and reachable systems.

Agent modes are autonomy controls, not governance controls

Agent Modes in Antigravity describe how independently an agent may act, from proposal-heavy behaviour to higher-autonomy execution. That is a useful local control because it reduces blind execution risk within a single tool. But mode settings do not decide what the agent may reach, what accounts it uses, or whether those accounts are appropriately scoped. In other words, autonomy tuning is not the same as access governance. The organisation still owns tool authorisation, data boundaries, and post-execution oversight. Practical implication: separate autonomy policy from privilege policy and review both independently.

Practical implication: separate autonomy policy from privilege policy and review both independently.

Artifacts change evidence, not accountability

Antigravity generates artifacts such as plans, logs, screenshots, and browser recordings to document what the agents did. That improves traceability, but evidence is not the same as control. Logs can show a task happened after the fact, yet they do not prevent an over-scoped agent from touching the wrong repository, terminal, or browser session. In NHI terms, artifacts help explain agent behaviour, but they do not enforce it. Practical implication: use recorded artefacts for audit and investigation, while enforcing least privilege, task scoping, and runtime policy at the point of action.

Practical implication: use recorded artefacts for audit and investigation, while enforcing least privilege, task scoping, and runtime policy at the point of action.

NHI Mgmt Group analysis

Antigravity is proof that agentic IDEs have crossed from experimentation into governed production risk. Once an IDE can coordinate multiple agents across editor, terminal, and browser, the security problem becomes identity-bearing execution inside developer workflows rather than code completion quality. That changes how IAM, PAM, and NHI teams should think about developer toolchains, because the agent becomes a runtime actor with real reach. Practitioners should now treat agentic IDEs as first-class governance surfaces.

Local autonomy settings do not solve enterprise privilege design. The article shows that Agent Modes can reduce or expand how quickly an agent acts, but they do not determine which secrets, APIs, or systems the agent can reach. That means the governance boundary still lives in IAM, secret management, and workspace segmentation, not inside the IDE itself. Security teams should stop treating autonomy presets as a substitute for access control.

Artifacts improve visibility, but visibility is not control. Plans, logs, and recordings help reconstruct what happened, yet they do not prevent a task from reaching production or modifying sensitive repositories. This is the recurring failure pattern in agentic tooling: receipt trails are useful after execution, but they cannot compensate for over-broad tool binding at runtime. Practitioners should design for constrained action, not just better evidence.

Runtime governance for agentic IDEs now needs a named concept: identity blast radius. The article makes clear that an agent's risk is determined by the combination of its autonomy level, connected tools, and the identities behind those tools. Once those three variables are allowed to expand together, a single developer workflow can touch far more systems than the user intended. The implication is that teams should measure and cap agent identity blast radius, not just approve the IDE itself.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That fragmentation makes agentic IDE governance harder, which is why practitioners should also review Top 10 NHI Issues for control patterns that survive tool sprawl.

What this signals

Identity blast radius: the useful way to think about agentic IDE risk is not the tool name but the span of identities, secrets, and systems each agent can reach. As more development workflows move into agent-first interfaces, IAM programmes will need to measure effective reach across tools rather than assume a single policy layer controls the whole environment. For governance teams, that means mapping agent runtime boundaries before autonomy becomes normalised.

The practical signal for security leaders is that agent adoption will outpace unified policy unless discovery and entitlement review are tied together. Fragmented secrets management already weakens central control, and agentic tooling amplifies that weakness by adding new execution surfaces. Teams that can correlate agent inventory, secret scope, and production adjacency will be able to govern this class of tooling with far less operational surprise.

For practitioners

• Inventory every agentic IDE instance Map where Antigravity or similar tools are running, which developers use them, and which workspaces they can access. Include the identities, tokens, and browser sessions attached to each environment so you can see the effective runtime reach of every agent. Use the same inventory model across all agent surfaces, including other IDEs and MCP-based tooling.
• Separate autonomy policy from privilege policy Define which Agent Modes are allowed for infra, IAM, production code, and sandbox work, then enforce those rules independently from secrets and repository access. A conservative mode does not make an over-privileged workspace safe, so privilege boundaries must be explicit and reviewable.
• Bind agents to task-scoped identities Give agents the narrowest viable credentials for the shortest viable task window, and rotate or revoke them when the task ends. If the agent can call a terminal or browser, assume the credential can also reach more than the user intended unless the binding is tightly scoped.
• Use artifacts for audit, not as a control substitute Retain plans, logs, screenshots, and browser recordings to support review, but do not rely on them to prevent harmful execution. Pair artefact retention with runtime enforcement so the evidence trail and the access boundary are both present.
• Cap agent blast radius in development environments Restrict which repositories, terminals, browsers, and production-adjacent systems an agent can touch, especially in high autonomy modes. The practical test is whether an agent can still do useful work after you remove one high-risk tool path.

Key takeaways

• Agentic IDEs turn developer tools into identity-bearing execution environments, which changes the governance problem from code assistance to runtime control.
• Autonomy settings help reduce local risk, but they do not substitute for IAM, secrets, and workspace boundary design.
• Security teams should measure agent identity blast radius, because visibility without privilege constraint still leaves the largest failures possible.

Key terms

• Agentic Ide: An agentic IDE is a development environment where AI agents can perform actions, not just suggest text. It combines code editing with terminal, browser, and workflow execution, which makes identity, privilege, and runtime boundaries part of the security model rather than a separate concern.
• Agent Mode: Agent Mode is the autonomy setting that controls how independently an AI agent may act inside a tool. In practice, it determines when the agent must ask before acting, but it does not define the credentials, systems, or data the agent is allowed to reach.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it behaves badly or is over-scoped. For agents, it is shaped by autonomy, tool reach, and the privileges attached to the runtime, so the same agent can be low risk in a sandbox and dangerous in production.
• Artifact Trail: An artifact trail is the evidence an agent produces while working, such as plans, logs, screenshots, or recordings. It improves auditability and investigation, but it is not a control by itself because it records actions after they occur rather than preventing unsafe access in the moment.

What's in the full article

CYATA's full post covers the operational detail this post intentionally leaves for the source:

• How Cyata maps Antigravity agents to workstations, developers, and model configurations in its discovery layer.
• The way Agent Modes are translated into posture signals alongside tool reach, identities, and reachable systems.
• Examples of queries used to find high-autonomy agents with write access to sensitive environments.
• Implementation detail on how the control plane was updated to recognise Antigravity alongside other agent surfaces.

👉 CYATA's full post covers discovery, posture mapping, and the agent controls behind Antigravity support.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.