Google hat am 21. August 2026 Remote Control für Antigravity 2.0 angekündigt. Damit lassen sich aktive Sitzungen des Entwicklungsagenten über einen modernen Browser sowie über mobile Geräte mit iOS oder Android aufrufen. Der Rollout beginnt schrittweise und priorisiert zunächst Abonnenten von Google AI Ultra. Für Unternehmen ist das mehr als eine Komfortfunktion: Ein Agent kann am Arbeitsplatz weiterarbeiten, während eine verantwortliche Person Aufgaben, Pläne und Ergebnisse von unterwegs prüft. Genau dadurch verschiebt sich aber auch die Sicherheitsfrage. Nicht mehr nur der Entwicklungsrechner, sondern zusätzlich das verwendete Mobilgerät, das Google-Konto und der Freigabeprozess werden Teil des betrieblichen Kontrollsystems.
Was Remote Control tatsächlich kann
Die offizielle Dokumentation beschreibt einen direkten Zugriff auf aktive Antigravity-Sitzungen. Nutzer melden sich im Browser mit demselben Google-Konto an, das sie auf dem Antigravity-Host verwenden. Anschließend können sie bestehende Gespräche öffnen, neue Aufgaben starten, Implementierungspläne prüfen und erzeugte Artefakte einsehen. Auf Mobilgeräten lässt sich die Oberfläche als Progressive Web App auf dem Startbildschirm ablegen; Benachrichtigungen können auf neue Aktivitäten hinweisen. Das ist relevant, weil ein Coding-Agent dadurch nicht mehr an einen dauerhaft geöffneten Laptop-Bildschirm gebunden ist. Fachliche oder operative Freigaben können näher an den tatsächlichen Arbeitsfluss rücken.
Die Ausführung bleibt an einen Host gebunden
Remote Control ist kein vollständiger Wechsel zu einem reinen Cloud-Agenten. Google weist darauf hin, dass der ausführende Rechner mit dem Internet verbunden und wach bleiben muss. Alternativ kann ein vorgesehener Headless-Daemon auf einem geeigneten Host betrieben werden. Hintergrundaufgaben und Shell-Befehle laufen nur weiter, wenn diese Ausführungsumgebung erreichbar bleibt. Für Unternehmen folgt daraus eine klare Trennung: Das Smartphone ist die Bedien- und Prüffläche, der Host bleibt die eigentliche Arbeitsmaschine mit Zugriff auf Repository, Werkzeuge und gegebenenfalls interne Daten. Wer diese Rollen verwechselt, unterschätzt die Anforderungen an Patchstand, Rechte, Netzwerkzugriff und Protokollierung des Hosts.
- Aktive Unterhaltungen lassen sich remote öffnen und weiterführen.
- Neue Agentenaufgaben können über den Browser oder ein Mobilgerät gestartet werden.
- Implementierungspläne können vor der Ausführung geprüft werden.
- Erzeugte Artefakte und Ergebnisse bleiben auch außerhalb des Arbeitsplatzes einsehbar.
- Der ausführende Host benötigt weiterhin Internetzugang und darf nicht in den Ruhezustand wechseln.
Der größte Nutzen liegt in kontrollierten Freigaben
Der stärkste Unternehmensnutzen entsteht nicht dadurch, dass Entwickler nun überall Code erzeugen können. Wertvoller ist die Möglichkeit, Wartezeiten in längeren Agentenabläufen zu verkürzen. Ein Agent erstellt beispielsweise einen Implementierungsplan, wartet auf eine Entscheidung und setzt die Änderung erst nach der Prüfung fort. Eine verantwortliche Person kann diesen Schritt mobil freigeben, ohne eine vollständige Entwicklungsumgebung zu öffnen. Das eignet sich besonders für klar begrenzte Aufgaben mit nachvollziehbaren Zwischenständen. Nicht geeignet ist ein ungeregelter Dauerbetrieb, bei dem mobile Nutzer weitreichende Shell-Befehle oder Änderungen an produktionsnahen Systemen auslösen dürfen.
Aus den bestätigten Produktfunktionen lässt sich eine organisatorische Schlussfolgerung ableiten: Unternehmen brauchen künftig nicht nur Rollen für Menschen und Dienste, sondern auch für Agentensitzungen. Es sollte festgelegt sein, wer eine Sitzung starten, wer einen Plan genehmigen und wer Ergebnisse übernehmen darf. Diese Schlussfolgerung ist eine GNS-Einordnung und keine von Google veröffentlichte Sicherheitsgarantie. Die Produktdokumentation bestätigt den Fernzugriff; das passende Berechtigungsmodell muss jedes Unternehmen selbst gestalten.
So sollte ein sicherer Pilot aussehen
Ein sinnvoller Pilot beginnt mit einem nicht kritischen Repository und einem separaten Host, auf dem keine produktiven Zugangsdaten liegen. Remote Control wird zunächst nur einer kleinen Gruppe freigeschaltet. Die ersten Aufgaben sollten jederzeit rückgängig zu machen sein, etwa Dokumentationsänderungen, Tests oder isolierte Refactorings. Gleichzeitig wird dokumentiert, welche Aktionen mobil erlaubt sind und an welchem Punkt eine zweite Person prüfen muss. Erst wenn Berechtigungen, Protokollierung und Wiederherstellung funktionieren, sollte der Einsatz auf wichtigere Abläufe ausgeweitet werden.
- Einen isolierten Host und ein nicht kritisches Test-Repository auswählen.
- Google-Konten mit Mehrfaktor-Authentifizierung und klarer Geräteverwaltung absichern.
- Mobile Nutzung zunächst auf Einsicht, Planprüfung und begrenzte Freigaben beschränken.
- Agentenaufgaben mit engen Repository-, Shell- und Netzwerkrechten ausstatten.
- Jeden Lauf, jede Freigabe und die Übernahme eines Ergebnisses nachvollziehbar protokollieren.
- Nach zwei Wochen prüfen, ob Durchlaufzeit, Fehlerrate und manueller Prüfaufwand tatsächlich besser werden.
Was Entscheider jetzt tun sollten
Unternehmen, die Antigravity bereits testen, sollten Remote Control nicht ungeprüft für alle Nutzer aktivieren. Zuerst muss geklärt werden, welche Sitzungen remote sichtbar sein dürfen, welche Daten auf dem Host liegen und wie verlorene oder private Mobilgeräte behandelt werden. Danach kann ein kleiner Pilot zeigen, ob mobile Freigaben echte Wartezeit beseitigen oder lediglich mehr Unterbrechungen erzeugen. Für Unternehmen ohne Antigravity-Einsatz ist die Veröffentlichung trotzdem ein wichtiges Signal: KI-Agenten entwickeln sich von einzelnen Desktop-Werkzeugen zu dauerhaft erreichbaren Arbeitsprozessen. Governance, Identität und Betriebsverantwortung müssen deshalb von Anfang an Teil der technischen Architektur sein.