Veröffentlicht am
GitHub hat Agentic Workflows am 28. Oktober 2026 allgemein verfügbar gemacht. Das offene Projekt von GitHub Next führt Coding-Agenten innerhalb von GitHub Actions aus. Als Einsatzfelder nennt GitHub etwa das Einordnen neuer Issues, die Analyse fehlgeschlagener CI-Läufe sowie Dokumentations- und Testarbeiten. Workflows werden in Markdown beschrieben und in reguläre Actions-YAML-Dateien übersetzt. GitHub: allgemeine Verfügbarkeit.
Bestehende Actions-Strukturen weiterverwenden
Nach der Ankündigung können die Abläufe vorhandene Runner-Gruppen und Richtlinien nutzen. Als Antrieb kommen GitHub Copilot oder andere Coding-Agenten infrage. Die Freigabe gilt auf github.com für Free, Team und Enterprise; für die standardmäßig eingesetzte Copilot-CLI-Engine ist eine Copilot-Lizenz erforderlich.
Zu den Ergänzungen gegenüber der Vorschau zählen Unterstützung für selbst betriebene ARC-Runner mit Docker-in-Docker sowie eine erweiterte Budgetprognose. Der Befehl „gh aw forecast“ berücksichtigt nun auch Credits für die Bedrohungsprüfung und monatliche Bandbreiten. Die Verfügbarkeit ist damit keine Zusage kostenloser Ausführung. Runner, Kostenplanung und Lizenzvoraussetzung.
Vorschlagen und Anwenden bleiben getrennte Schritte
GitHub beschreibt standardmäßig lesende Agentenrechte, eine isolierte Ausführung und eine Netzwerk-Firewall. Geplante Änderungen durchlaufen einen gesonderten Ausgabeprozess. Die zugehörige Dokumentation erläutert eine Bedrohungsprüfung, die Agentenausgaben und Codeänderungen unter anderem auf manipulierte Anweisungen und offengelegte Geheimnisse untersuchen soll.
Bei konfigurierten „safe outputs“ ist diese Prüfung standardmäßig aktiviert. Ihr Verhalten hängt jedoch von der Einstellung ab: Im Warnmodus können überprüfbare Ausgaben mit Warnhinweisen weitergegeben werden; bestimmte nicht überprüfbare Aktionen werden abgebrochen. Der strenge Modus blockiert die Ausgaben bei Befunden oder Fehlern der Prüfung. Eine fehlgeschlagene Analyse gilt ausdrücklich nicht als sauberes Ergebnis. GitHub: Threat Detection und Fehlerbehandlung.
Auch eine Warnmarkierung allein erzwingt laut Dokumentation keine Plattformfreigabe. Die Schutzregeln für das Zusammenführen von Änderungen müssen die gewünschte Prüfung tatsächlich durchsetzen. Die beschriebenen Mechanismen sind deshalb konfigurierbare Kontrollen und kein Nachweis vollständiger Sicherheit gegen Prompt Injection. Grenzen der Warn- und Freigabemechanismen.
Unsere Einordnung: Mit einer lesenden Aufgabe beginnen
Für Entwicklungsteams erscheint uns die Analyse eines fehlgeschlagenen CI-Laufs als sinnvoller Pilot. Der Auftrag könnte zunächst nur verlangen, Ursache, Belegstellen und einen Änderungsvorschlag zusammenzustellen. So lässt sich die Qualität anhand vorab festgelegter Abnahmekriterien beurteilen, bevor Schreibaktionen hinzukommen.
Für die Abnahme würden wir normale Fehlerfälle und absichtlich irreführende Testeingaben getrennt betrachten. Entscheidend wäre, ob der Vorschlag auf nachvollziehbare Protokollstellen verweist und ob Grenzen des Auftrags erhalten bleiben. Zusätzlich würden wir einen Ausfall der Bedrohungsprüfung simulieren und kontrollieren, welche Aktionen danach noch möglich sind.
Kosten und Qualität sollten wir dabei gemeinsam bewerten: Wiederholungen, erfolglose Läufe und zusätzliche Prüfjobs gehören in die Betrachtung. KI-AGT hat die Workflows nicht selbst ausgeführt; die genannten Prüfschritte sind redaktionelle Einordnung. Grundlagen erläutern unsere Beiträge zu Berechtigungen und Human-in-the-Loop.
Quelle: Offizielle Quelle