Google Antigravity /swarm Security: Test Agent Boundaries

Google Antigravity introduced /swarm in preview on November 10, 2026 alongside Gemini 4 Carbon. The security engineering task is to assess how a coordinated agent team handles authority, shared context and verification before allowing it to work on sensitive repositories.

Die official announcement describes a coordinator, parallel workers in isolated git worktrees, adversarial verifiers and a shared append-only message board. It also describes role-specific model selection and interfaces for inspecting team activity. These are vendor-described features, not findings from an independent Penligent test. The review plan below is a proposed acceptance method, not a report of a disclosed /swarm vulnerability.

A worktree answers a file question

Ask which working directory each agent can modify, then ask which resources its tools can access. Treat those as separate review items. A proposed deployment might place workers in different directories while still giving their tools a common cloud identity. That hypothetical design would need an identity review even if file edits never collide.

For each role, map the intended repository scope, shell or tool capability, credential source, network destinations and output location. Validate the effective implementation with the platform owner rather than inferring it from role names such as “worker” or “verifier.” An agent’s assigned purpose is useful context; acceptance requires evidence about what actions its environment permits.

Review shared messages as evidence with provenance

A shared board can make collaboration inspectable. A review still needs to identify who produced each statement and whether it reports an observation, proposes a plan or requests a privileged action. The proposed policy is simple: a worker’s claim of authorization should not itself create authorization for another role.

Retain the originating agent, task, timestamp, relevant commit and evidence reference for consequential messages. When a message quotes external material, preserve that distinction. A test log that contains a sentence about deployment is still a test log; a release decision should come from the configured approval path.

Inspect how the team handles contradiction. If a worker reports success and a verifier reports a failed check, the acceptance record should preserve both and explain the resolution. A summary that silently discards a failed observation is weaker evidence than the underlying board, regardless of how fluent the summary sounds.

Run four harmless acceptance cases

Use a disposable local repository containing synthetic code and non-sensitive fixtures. Do not connect production credentials or external deployment tools. The cases below specify properties to observe; they do not assert current product behavior.

Choose a failure that is easy for the reviewer to recognize. For example, a toy calculation can return a deliberately incorrect constant. The purpose is to check result handling and traceability, not to measure a model’s ability to discover a difficult security flaw. Keep expected behavior in a separate reviewer record so the acceptance decision is reproducible.

Tie each pass to the artifact that produced it

For every check, capture the candidate revision, working directory, command or tool action, exit status, output reference and relevant environment version. If the system cannot provide one item, record the gap. A statement that tests passed yesterday does not establish the status of today’s combined patch.

When workers run checks independently, preserve those results but also verify the assembled candidate. Review dependency and configuration changes with the same care as source changes. A changed test command or skipped test can alter the meaning of “pass” without fixing the behavior the team intended to assess.

candidate_revision: "Exact combined commit"
checks:
  - role: "Verifier identity"
    action: "Approved local check"
    environment: "Runtime and dependency references"
    result: "Pass / fail / not executed"
    evidence: "Output artifact reference"
unresolved_items: ["Named gaps and owners"]
release_decision: "Accept / hold, with rationale"

Set stop conditions that an operator can apply

Proposed stop conditions include an unexpected credential request, a tool action outside the approved scope, inability to identify the tested revision, or a summary that contradicts retained results. These should produce a reviewable hold with an owner. They should not trigger an agent to broaden its own access to remove the obstacle.

Set a resource budget as well. The announcement warns that parallel teams can consume quota faster than ordinary chat. Define a maximum run budget and a continuation decision before using a swarm for an open-ended investigation. Budget exhaustion should be recorded as an incomplete run, with useful evidence preserved.

Accept the workflow by boundary, then expand deliberately

A useful pilot outcome can be narrower than full autonomy: code edits accepted within a disposable repository, verifier output retained, and external actions reserved for an existing approval process. Re-run the relevant cases when tool permissions, model assignments, repository scope or orchestration behavior changes.

For a broader test inventory, see our agentic AI security testing guide. If you need to assess an application changed by an agent team, create a Penligent account and define the authorized application scope and acceptance evidence before testing.

Method: AI-assisted analysis of Google’s November 10 announcement, checked November 11, 2026. The acceptance cases are proposed local tests. No independent /swarm security test or product integration is claimed.

Prepare an independent application test

The official Penligent 3.0 walkthrough is an example of a testing interface. It does not demonstrate Antigravity or swarm isolation. Use the boundary cases above to define what an independent, authorized application evaluation must observe.