Antigravity token exposure shows new risks in agentic IDEs

At a glance

What this is: Lumia Security’s research shows that Google’s Antigravity agentic IDE exposed authentication tokens through process memory and a macOS interface that could be reached from the network.

Why it matters: This matters because agentic IDEs can turn a local token leak into delegated LLM misuse, so IAM and security teams need stronger controls around identity, process trust, and agent governance.

Context

Agentic IDEs expand the attack surface by combining user interface, browser, CLI, and model interaction in one application. That mix creates a governance problem as much as a software security problem, because the same credential can be reused across multiple runtime components and then abused in the name of the user.

In this case, the key issue is not just token theft. It is the collapse of trust boundaries between the IDE, the language server, and the LLM backend, which makes the identity of the process almost as important as the identity of the human using it. AI agent authorisation becomes relevant when a tool can act with delegated authority but is not tightly constrained.

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 exposed local interfaces matter in agentic development tools?

A: A local interface can still become a credential leak if it binds too broadly or renders sensitive session data into a browser view. Once a token is exposed, the attacker can use it to access downstream services as the legitimate user, turning a local flaw into delegated misuse.

Q: What are the signs that developer AI tooling is crossing a trust boundary?

A: Look for automatic content ingestion, hidden file references, remote retrieval triggered by file contents, and assistant actions that can touch secrets or outbound endpoints. Those signals show that the tool is no longer just suggesting code. It is participating in the identity and access path.

Q: How should teams reduce the impact of token theft in AI-assisted development?

A: Limit each credential to a narrow task scope, shorten its lifetime, and monitor for abnormal backend usage after issuance. If the token can only do one job for one session, the attacker gains less value even if the secret is exposed.

Technical breakdown

How agentic IDE process separation becomes an identity problem

Antigravity splits the user-facing IDE from a separate language_server process that handles LLM logic. That architecture is meant to isolate concerns, but it also creates a shared trust model between components. If the language server authenticates to the backend using tokens available to the application, then compromise of one component can impersonate the legitimate runtime session. In agentic systems, the critical question is not only whether the user is authenticated, but which process is allowed to exercise that identity and under what boundary conditions. See the AI Agent Identity Security Buyer's Guide. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Treat each process that can reach an LLM backend as a separately governed identity with its own scope and logging.

Why exposed local interfaces become remote token leakage paths

The macOS issue described in the article shows a familiar pattern: a local service listens on 0.0.0.0 and exposes an interface that was not intended to be reachable beyond the host. Even if the UI itself is partially broken, any content rendered into that interface can still reveal session material, secrets, or user metadata. Once a token is exposed through a network-accessible endpoint, the attack ceases to be a pure local-only problem and becomes a trust-boundary failure. The control gap is not the port alone, but the combination of listening scope, content exposure, and missing authentication around the endpoint.

Practical implication: Bind internal interfaces to localhost, require explicit authentication on every exposed endpoint, and do not render secrets into webviews.

Token reuse turns one leak into delegated model abuse

The article’s most important technical point is that the leaked token is not the end of the incident. The attacker can present that token to the LLM backend and language server as though they were the legitimate user, which means actions may be attributed to the trusted application rather than the hostile origin. That obscures detection and increases blast radius, especially where the model can trigger file operations or other side effects. This is a classic delegated-authentication failure: the credential proves access, but not intent, context, or acceptable action scope. See the AI Agent Authorisation Guide.

Practical implication: Require task-scoped, short-lived credentials for model interactions and monitor for abnormal backend use after token issuance.

Threat narrative

Attacker objective: The attacker aims to hijack the victim’s authenticated agent session and use the LLM backend to perform harmful actions while appearing legitimate.

1. Entry occurs when an attacker gains access to a leaked or exposed authentication token from the agentic IDE environment.
2. Credential access is achieved through process memory harvesting or the macOS web interface that reveals user information and backend tokens.
3. Escalation happens when the attacker reuses the token to speak to the language server and LLM backend as if they were the legitimate user.
4. Impact is delegated model abuse, including file deletion, encryption, or other actions carried out under the victim's trusted session.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic IDEs create identity boundaries that traditional desktop security does not model well. The issue is not just that an application has more features, but that it now contains a user interface, a privileged language server, and a model backend linked by shared authentication material. That makes process identity and delegated authority part of the security design, not an implementation detail. Practitioners should govern each component as a distinct trust actor, not as a single desktop app.

Local-only attack arguments miss the governance point. A token stolen from memory or exposed in a local webview is still a valid identity artifact, and once it reaches the backend it can drive model actions in the victim’s name. The relevant failure mode is delegated agent identity without sufficient scope control or visibility. Security teams should assume that any reusable token in an agentic workflow can become a control-plane credential if it is not tightly bound to context.

Agentic AI expands the meaning of least privilege. In these systems, privilege is not only what a process can read, but what it can ask another component to do. That means task scope, runtime context, and backend authorization all need to be aligned, or the attacker inherits the same delegation path as the legitimate user. Practitioners should narrow that delegation path before deploying AI-assisted development at scale.

Exposed developer tooling is now a supply chain concern for identity governance. When the IDE itself can broker model access, a flaw in the tool becomes a path to misuse of the downstream AI service. That is why governance teams should review AI-enabled development environments as part of the broader identity attack surface, not just as endpoint software. The control question is who or what is allowed to act as the user, and for how long.

What this signals

Delegated model abuse: The core governance issue here is not token theft alone, but what happens after a valid credential is reused against the backend. If the system cannot distinguish between legitimate and hostile use of the same token, then identity controls have to move closer to issuance, context, and runtime behaviour. Practitioners should treat agentic tools as identity-bearing systems, not just productivity software.

Agentic IDEs force security teams to reconcile process trust, application trust, and model trust inside the same workflow. That makes runtime authorisation and observability more important than one-time authentication checks, because the credential can be legitimate even when the action is not. Teams that are already adopting AI-assisted development should expect the governance burden to shift from login to delegation control.

The practical signal for defenders is simple: if an AI tool can browse, call a backend, and act on the user’s behalf, then privilege has moved into the workflow itself. That means policy has to follow the agentic action path, not stop at the human login boundary.

For practitioners

• Harden local service binding Force internal agentic IDE services to bind to localhost only, and block any 0.0.0.0 listeners unless they are intentionally exposed and authenticated.
• Separate process identity from user identity Assign distinct credentials and logging to the IDE front end, language server, and model backend so one process cannot silently impersonate another.
• Remove secrets from web-rendered views Audit all embedded browser or webview components for session data, tokens, and user metadata that should never be rendered into HTML.
• Monitor model-backend reuse patterns Alert on token use patterns that do not match normal developer workflows, especially when the same credential begins driving backend actions from a new host or process.

Key takeaways

• Agentic IDEs introduce a blended trust model where process identity, delegated authority, and model access can fail together.
• The article’s evidence shows that one exposed token can become a backend control plane credential when the same identity is reused across components.
• The strongest limitation is to narrow the scope and lifetime of credentials so a stolen token cannot operate as a general-purpose session key.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agent Identity Security Buyer's Guide · Identity Attack Paths Guide · Google Cloud Security Guide

Key terms

• Agentic IDE: An agentic IDE is a development environment in which an AI system can execute actions, call tools, and chain steps with limited human intervention. The security challenge is not just code generation. It is the ability to stage execution context and influence later commands or tools.
• Delegated Authority: Delegated authority is permission granted to one system or process to perform actions using another party’s identity or trust relationship. In agentic software, that delegation can outlive the user’s intention unless the scope, duration, and action boundaries are tightly controlled.
• Process Identity: The identity of the actual running process that generated a request, not just the pod, container, or proxy carrying it. In workload security, process identity matters because transport-level authentication can succeed even when the wrong runtime actor is speaking through a shared boundary.
• Token Reuse: Token reuse occurs when the same credential is used across multiple applications, pipelines, or environments. This pattern increases the impact of any single leak because compromise in one place can open access elsewhere. It is a common sign that identity boundaries are too loose for modern automation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners align identity controls with the runtime systems that now carry delegated authority.