The risks of running multiple Google Antigravity agents concentrate every known multi-agent hazard into one surface: prompt injection that spreads between parallel agents, credential exposure across workspaces, unsupervised background tool execution, and audit gaps when agents act faster than a human can review. Fleet-level agent deployment is not single-agent risk multiplied. It is a distinct control problem that demands per-call inspection, real-time discovery, and interaction-layer evidence.

Last updated: August 2026.

Google positions its agent platform around agents that work across developer environments and enterprise workflows (Google Cloud, 2026). If Antigravity enables parallel or background execution in your deployment, treat that as a control-plane decision, not just a productivity setting. Run one agent and a mistake stays local. Run many, and each concurrent agent can hold credentials, touch source code and files, invoke tools, and take actions with limited human review. A single poisoned input then becomes a propagation path through the fleet.

This guide walks through the concrete failure modes and what a security team should measure before enabling background agents at scale. It uses Antigravity as a named evaluation example, then shows where Aurascape’s full-context controls apply across authenticated identity context, data, intentions, conversations, tools, actions, and audit evidence. For a parallel look at source-code and secrets risk in other AI coding tools, see risks of using Claude Code with company source code and Cursor source code exposure.

Multi-agent risk is a different category, not more of the same

Multi-agent risk means the failure modes that emerge only when agents interact, and that you cannot predict by testing one agent in isolation. Research on multi-agent AI systems identifies distinct hazard categories, including emergent collusion, cascading failures, and cross-agent information leakage, that are absent when agents operate individually and that standard single-agent safety evaluations do not surface (Hammond et al., arXiv, 2025). A separate analysis of open challenges in multi-agent security concludes that network effects amplify vulnerabilities through cascading privacy leaks and cross-agent propagation, and that these threats cannot be addressed by securing individual agents in isolation (Ma et al., arXiv, 2025).

For an engineering leader, the translation is direct. A single Antigravity agent that ingests a malicious code comment or web result is a contained problem. Many agents sharing context, credentials, and a task queue turn that same input into a propagation path. The control gap is not detection after the fact. It is inspection at the moment each agent tries to act.

Prompt injection, context bleed, and sub-agent delegation

Prompt injection embeds malicious instructions in content a model processes, such as a document, a webpage, or a tool result. OWASP ranks prompt injection (LLM01), sensitive information disclosure (LLM02), and excessive agency (LLM06) among the top risks for AI applications (OWASP, 2025). In a single agent, an injected instruction hijacks one task. In a fleet, one agent’s poisoned output becomes another agent’s trusted context.

The injection surface widens further through shared task queues, copied summaries, shared memory, and tool results passed between concurrent sessions. When one agent summarizes a task and a second agent picks up that summary as trusted input, sensitive context or injected instructions ride along with it. This is context bleed: information from one session leaking into another through the shared scaffolding the orchestration layer provides.

Delegation adds another layer. When an agent operating with a compromised context invokes a sub-agent, it can grant that sub-agent broader tool access or a different workspace scope than the original task warranted. The parent’s compromised instructions propagate downward, and the sub-agent acts on them with whatever permissions it inherits. Zero-click indirect prompt injection in real deployments confirms this is not theoretical. EchoLeak (CVE-2025-32711) is recorded as an improper neutralization issue affecting Microsoft 365 Copilot (NVD, 2025). Aurascape’s own research documented SilentBridge, a class of zero-click indirect prompt injection flaws in the Manus agent, rated CVSS 9.8 Critical, with demonstrated email data theft and remote code execution (Aura Labs, 2026). Multiply that pattern across a background fleet and the propagation risk grows with agent count.

Credential exposure, unauthorized data paths, and persistent access

In a multi-agent deployment, agents with access to enterprise credentials, including source-control tokens, cloud keys, and environment variables, can use those credentials across more workspaces or tool connections than a single task requires. That is the excessive-agency risk OWASP identifies, and it compounds when agents chain tool calls. Picture an agent that reads secrets from a repository through one connector and then writes them out through an authorized messaging or ticketing connector. Two individually permitted actions combine into one unauthorized data path.

The exposure surface is concrete. Censys found more than 12,520 internet-accessible Model Context Protocol (MCP) services, and notes the protocol does not require authentication by default, which they observe as a factor in the prevalence of unauthenticated exposure (Censys, 2026). When agents connect to those servers in the background, a credential or token in one workspace context can travel further than intended.

Persistent access is a related concern in any coding-agent deployment. When an agent writes startup hooks, build scripts, scheduled tasks, or initialization files during a session, those artifacts can survive workspace resets and re-execute on next launch. The result is a persistence risk that is not malware in the traditional sense, but agent-authored code that re-establishes access or behavior. Teams evaluating Antigravity should audit what each background agent writes to disk and whether any of those writes touch startup or CI/CD execution paths. For comparable source-code and secrets analysis, see Roo Code source code and secrets exposure.

Aurascape applies real-time inline data classification to agent-to-tool exchanges, so credentials, environment variables, and source files are identified and policy-actioned at the point of movement, not flagged after the fact in a network log. The platform ships 600+ real-time data classifiers (Aurascape, 2026) for exactly this purpose.

Background execution, default settings, and human oversight gaps

Background agents act without a human watching each step. That is the productivity value, and it is also the primary oversight gap. When onboarding favors broad autonomy, user control narrows quickly. Treat default settings as deployment controls. Review default tool scopes, background execution defaults, and whether approval prompts appear before write and execute actions before enabling a team. Ask whether write and execute permissions are scoped by task, whether an approval step precedes high-risk actions, and whether background execution stays bounded to defined workspaces or can reach remote resources.

The market already prices in the cost of skipping those reviews. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing inadequate risk controls as a leading cause (Gartner, 2025). Aurascape governs already-authenticated, already-running agents at runtime. An Antigravity agent that passed onboarding and holds a trusted workspace token is still subject to per-call inspection and policy enforcement before it acts on injected instructions.

Supply-chain and third-party agent trust add another layer. Multi-agent pipelines often pull in community tools, third-party connectors, package manager integrations, and agent-to-agent boundaries where one agent calls another it did not originate. Each boundary is a trust decision made at configuration time, not at execution time. Aurascape governs approved tool execution inline and records the policy decision attached to each governed action, so the trust decision is enforced when the tool call runs, not assumed from earlier configuration.

How to evaluate a multi-agent deployment before you enable it

Use this sequence to assess background agents against real controls before enabling them at team scale:

1. Inventory every agent the platform can spawn, including agents launched in the background, not just those a developer starts manually. That inventory must cover tool connections and the workspaces each agent can reach.
2. Map which credentials, tokens, and connectors each agent accesses by default, and confirm what happens to those credentials when a background task ends or is handed to a sub-agent.
3. Verify that inspection runs on each tool call before execution, so injected instructions in documents, web results, or tool outputs cannot reach a workspace unfiltered.
4. Set approval boundaries for write and execute tools, holding high-risk calls for human confirmation or blocking them at the execution layer.
5. Apply data classification before tool execution, catching secrets, source files, and sensitive records in prompts, file uploads, and tool results as they move.
6. Audit what agents write to disk during a session, and confirm that no startup hooks, build scripts, or scheduled tasks survive workspace resets.
7. Confirm an interaction-level record for every governed agent action: who acted, which account or tenant, which tool was invoked, what data category was detected, and what policy decision was made.

Aurascape enforces policy in real time through allow, coach, notify, redact, redirect, block, capture, and require tenant actions, applied per call before an action reaches an external system. For a background fleet, coach and notify keep developers moving while block and capture stop the dangerous cases.

Discovery, inline enforcement, and the audit evidence gap

MCP is one common tool-execution pattern that agents use, not the whole agent access-control problem. Antigravity agents can also act through CLI commands, direct APIs, and third-party connectors. When the platform spawns sub-agents or an agent invokes a tool that was never registered, security has no record it happened. That is the shadow-agent problem: security needs an inventory of active agents, tool connections, and attempted actions before policy can apply.

Aurascape discovers local AI agents and their interactions in real time, so teams keep an inventory of active agents, workspaces, and connected tools (Aurascape, 2026). Local AI agent discovery extends to seeing and governing local agent activity, not just detecting presence. For agents operating through MCP, Aurascape adds a Zero-Bypass MCP Gateway that marks every tool call it approves. In governed workflows where the architecture applies, Aurascape verifies marked calls against model-path activity and blocks unmarked execution before the downstream action runs.

When agents act concurrently in the background, reconstructing what happened is the core compliance challenge. Regulators are moving the same direction. The WEF reports that organizations assessing AI tool security before deployment nearly doubled, from 37% to 64% (World Economic Forum, 2026). Aurascape creates interaction records for audit and effectiveness, governed by role-based access control (RBAC) for privacy. For governed MCP workflows, each record shows the user identity, application, server, tool, parameters, detected data categories, and policy action taken. For compliance and data residency questions raised by AI coding tools, see compliance and data residency risks for AI coding tools.

The table below compares deployment-pattern controls for a multi-agent setup. The columns describe what a deployment relying only on a configured routing-based gateway provides versus what Aurascape adds across discovery, data classification, enforcement actions, and evidence.

Frequently asked questions

What are the main risks of running multiple Google Antigravity agents at once?

The main risks are prompt injection propagating across parallel agents through shared context, credential and token exposure when agents chain tool calls across workspaces, unsupervised write and execute actions in background mode, persistent artifacts from agent-authored code, and the audit gap that opens when agents act faster than a human can review.

What are the Google Antigravity permissions risks?

The primary permissions risk is excessive agency: an agent holding credentials to multiple systems can exercise those credentials across more workspaces or tool connections than the task requires. Check whether permissions are scoped per task, whether write and execute tools require explicit approval, and whether sub-agents inherit permissions from the parent context.

Can Google Antigravity agents expose source code or secrets?

Yes. Source files, environment variables, and tokens can move through an agent’s prompts, file uploads, and tool results without inspection. Aurascape applies real-time data classification at the point of movement, so secrets and source are identified and policy-actioned before a tool call completes.

What do Google Antigravity audit logs cover?

Platform-native logs cover events at the session and request level based on what the product surfaces. Interaction-level audit evidence that ties each governed tool call to a user identity, workspace, detected data category, and policy decision needs a separate control layer. Aurascape creates interaction records for audit and effectiveness, governed by RBAC for privacy, covering those fields for governed workflows.

What are the Google Antigravity data retention and training risks?

Data handling depends on the tenant configuration, plan tier, and vendor terms at the time of deployment. Confirm the current retention and training behavior against Google Cloud’s product documentation before onboarding sensitive workspaces. Regardless of the vendor’s settings, Aurascape classifies and policy-actions sensitive data as it moves through each agent interaction.

How do Google Antigravity integrations and connectors create risk?

Third-party connectors, community tools, and package manager integrations each add an agent-to-agent or agent-to-tool trust boundary. That trust is often granted at configuration time and never re-checked at execution time. Aurascape governs approved tool execution inline and records the policy decision on each governed action, so the trust decision is enforced when the call runs.

Does an MCP gateway alone govern all Google Antigravity tool calls?

No. A routing-based gateway inspects only calls configured to pass through it. Antigravity agents can also act through CLI commands, direct APIs, and connectors outside that path. Aurascape pairs gateway-level enforcement with local agent discovery and governed workflow verification, so policy is not limited to a single routed path.

How do I maintain human oversight over background agents?

Set explicit approval boundaries on write and execute tools before enabling background mode for a team. Aurascape applies the full policy set per call: allow, coach, notify, redact, redirect, block, capture, and require tenant. That lets teams guide lower-risk work and stop high-risk actions before they reach an external system.

Aurascape turns the open question of running multiple Google Antigravity agents into a governed one: real-time local agent discovery, inline classification of the data each agent touches, per-call policy enforcement before tool execution, and interaction records that tie every governed action to an identity, a workspace, and a policy decision. That is how a background fleet stays productive without becoming a propagation path.

See how Aurascape governs concurrent AI agents across your workspaces →