Die Rule of Two für KI-Agenten in CI/CD

KI-Coding-Agenten sind gerade dabei, eine neue Grenze zu überschreiten.

Sie schreiben nicht mehr nur Code in einem Editor. Sie kommentieren Pull Requests, lesen Issues, starten Tests, prüfen Diffs, öffnen Dateien, rufen Tools auf und laufen in GitHub Actions oder anderen CI/CD-Umgebungen. Damit werden sie Teil der Delivery-Pipeline.

Das ist nützlich.

Es ist aber auch eine andere Sicherheitskategorie als Autocomplete.

Microsoft Threat Intelligence hat diese Woche einen Fall rund um die Claude Code GitHub Action beschrieben. Die Details sind für Sicherheitsteams interessant, aber die wichtigere Lehre für Produkt- und Engineering-Teams ist einfacher: Ein KI-Agent, der untrusted Input verarbeitet, gleichzeitig Secrets sehen kann und dann nach draußen kommunizieren darf, ist kein harmloser Helfer mehr. Er ist ein operativer Akteur mit Blast Radius.

Genau hier wird eine einfache Regel wertvoll.

Ein agentischer Workflow sollte nie alle drei Fähigkeiten gleichzeitig haben:

• untrusted Input verarbeiten;
• auf Secrets oder privilegierte Credentials zugreifen;
• externe Kommunikation oder Schreibaktionen ausführen.

Zwei davon können in bestimmten Situationen vertretbar sein. Alle drei zusammen sind gefährlich.

Das ist die praktische Rule of Two für KI-Agenten in CI/CD.

Warum CI/CD-Agenten anders sind als lokale Assistenten

Ein lokaler Coding-Assistent arbeitet meistens in einem Kontext, den ein Entwickler direkt beobachten kann.

Er öffnet Dateien, schlägt Änderungen vor, fragt nach Zustimmung, führt vielleicht Tests aus. Wenn er etwas Seltsames tut, fällt es oft auf. Nicht immer, aber die Schleife ist enger.

CI/CD ist anders.

Eine Pipeline läuft automatisiert. Sie hat oft Zugriff auf Umgebungsvariablen, Build-Artefakte, Paket-Repositories, Deployment-Schlüssel, Cloud-Rollen oder GitHub-Tokens. Sie soll gerade deshalb ohne ständige menschliche Bedienung funktionieren.

Wenn dort ein KI-Agent eingebaut wird, entsteht eine neue Frage:

Nicht nur “Kann der Agent die Aufgabe lösen?”, sondern:

Was darf der Agent tun, wenn die Aufgabe von einem Angreifer beeinflusst wurde?

Das ist keine theoretische Sorge. GitHub Issues, Pull-Request-Beschreibungen, Kommentare, Commit Messages, README-Dateien oder Log-Ausgaben können Text enthalten, den das Modell verarbeitet. Ein Teil dieses Textes kann von externen Personen stammen. Für Menschen sieht er aus wie Projektkontext. Für einen Agenten kann er wie eine Anweisung wirken.

Sobald der Agent danach Tools benutzen darf, wird aus Text Einfluss auf Handlung.

Der Denkfehler: “Der Agent liest doch nur”

Viele Risiken entstehen aus einer falschen mentalen Kategorie.

Teams behandeln AI-Workflows oft wie statische Automatisierung:

“Der Bot liest das Issue, erzeugt einen Vorschlag und kommentiert.”

Das klingt klein.

In Wirklichkeit kann der Workflow aber deutlich mehr enthalten:

• Repository-Inhalte lesen;
• Shell-Befehle ausführen;
• Artefakte oder Logs inspizieren;
• Umgebungsvariablen sehen;
• API-Tokens verwenden;
• externe URLs aufrufen;
• Kommentare posten;
• Branches oder Pull Requests verändern.

Jede einzelne Fähigkeit kann legitim sein. Zusammen können sie eine Kette bilden.

Das Problem ist nicht, dass KI “böse” ist. Das Problem ist, dass ein Agent Sprache als Arbeitskontext benutzt. Wenn in diesem Kontext untrusted Input liegt, kann der Agent Dinge für plausibel halten, die nicht vom Team stammen.

Klassische CI/CD-Sicherheit geht davon aus, dass Code, Konfiguration und Credentials getrennte Rollen haben. Agentische Workflows verwischen diese Rollen, weil Sprache sowohl Daten als auch Steuerung sein kann.

Deshalb reicht es nicht, den Prompt vorsichtiger zu formulieren.

Die Architektur muss verhindern, dass ein erfolgreicher Prompt-Injection-Versuch automatisch zu Credentials, Schreibrechten oder Exfiltration führt.

Die Rule of Two als Architekturprinzip

Die Rule of Two ist keine magische Sicherheitslösung. Sie ist ein einfaches Designprinzip für Workflows.

Ein KI-Agent sollte nicht gleichzeitig:

1. Inhalte aus untrusted Quellen verarbeiten;
2. privilegierte Geheimnisse oder Tokens erreichen;
3. nach aussen schreiben, posten oder senden können.

Wenn ein Workflow untrusted Input lesen muss, sollte er mit minimalen Rechten laufen.

Wenn ein Workflow Secrets braucht, sollte sein Input stark kontrolliert sein.

Wenn ein Workflow extern posten oder schreiben darf, sollte er keine sensiblen Daten sehen, die er versehentlich oder manipuliert weitergeben kann.

Das zwingt Teams zu einer gesunden Trennung.

Zum Beispiel:

• Ein Agent darf ein GitHub Issue analysieren, aber nicht mit Produktions-Credentials laufen.
• Ein Agent darf einen Vorschlag für eine Code-Änderung erzeugen, aber nicht selbst in geschützte Branches pushen.
• Ein Agent darf Tests starten, aber keine Deployment-Secrets lesen.
• Ein Agent darf Security Findings zusammenfassen, aber nicht rohe Secrets in Kommentare schreiben.
• Ein Agent darf Logs auswerten, aber nur redigierte oder eingeschränkte Logs sehen.

Diese Grenzen wirken zuerst umständlich. In seriösen Produkten sind sie aber genau der Unterschied zwischen produktiver Automatisierung und einem stillen Sicherheitsrisiko.

Was das für Gründer und CTOs bedeutet

Viele Unternehmen werden KI-Agenten nicht zuerst in kritischen Kernsystemen einsetzen. Sie starten mit scheinbar harmlosen Dingen:

• automatische PR-Reviews;
• Issue-Triage;
• Testvorschläge;
• Dokumentationsupdates;
• Release-Notes;
• kleine Bugfixes;
• interne Tools für Support oder Operations.

Das ist ein sinnvoller Einstieg.

Aber auch diese Workflows berühren echte Systeme. Sie laufen in echten Repositories. Sie lesen echte Tickets. Sie können echte Tokens sehen. Sie beeinflussen echte Entscheidungen.

Für Gründer, Product Owner und CTOs ist deshalb nicht die wichtigste Frage, ob Claude Code, Codex, Cursor, Copilot oder ein anderer Agent “gut genug” ist.

Die bessere Frage lautet:

Welche Autorität bekommt der Agent in unserem Delivery-System?

Ein Agent, der nur lokal einen Patch vorschlägt, hat eine andere Risikoklasse als ein Agent, der in CI läuft und auf Issues von externen Nutzern reagiert. Ein Agent, der nur einen Diff kommentiert, ist anders zu bewerten als ein Agent, der Commands ausführen und Ergebnisse ins Internet schreiben darf.

Die technische Fähigkeit ist nur eine Seite. Die Betriebsverantwortung ist die andere.

Eine praktische Prüfliste für agentische CI/CD-Workflows

Bevor ein Team KI-Agenten in CI/CD, GitHub Actions oder Deployment-nahe Prozesse integriert, sollte es eine kurze, ehrliche Bestandsaufnahme machen.

1. Welche Inputs sind untrusted?

Nicht jeder Text im Repository ist vertrauenswürdig.

Prüfen Sie:

• GitHub Issues;
• Pull-Request-Beschreibungen;
• Kommentare;
• Commit Messages;
• externe Logs;
• Kundentickets;
• Support-Nachrichten;
• generierte Dokumente;
• README- oder Konfigurationsdateien aus fremden Repositories.

Wenn ein Agent diese Inhalte liest, muss der Workflow so designt sein, als könnte darin eine manipulierte Anweisung stehen.

2. Welche Secrets sind erreichbar?

Viele CI/CD-Umgebungen haben mehr Zugriff als man denkt.

Prüfen Sie:

• GitHub Tokens;
• OIDC-Token und Cloud-Rollen;
• Paket-Registry-Credentials;
• Deployment-Schlüssel;
• API-Keys;
• Datenbank-URLs;
• Monitoring- oder Log-Zugänge.

Der Agent sollte nur sehen, was für die konkrete Aufgabe nötig ist. “Ist halt in der Umgebung vorhanden” ist kein Sicherheitskonzept.

3. Wohin kann der Agent schreiben?

Externe Kommunikation ist nicht nur HTTP.

Prüfen Sie:

• Kommentare in Issues oder Pull Requests;
• Pushes auf Branches;
• erstellte Artefakte;
• hochgeladene Logs;
• Paketveröffentlichungen;
• Slack- oder Ticket-Kommentare;
• Webhooks;
• ausgehende Netzwerkverbindungen.

Wenn der Agent sensible Daten sehen kann, muss kontrolliert werden, ob und wohin diese Daten gelangen können.

4. Wer genehmigt den nächsten Schritt?

Agentische Workflows brauchen Gates.

Nicht jeder Schritt muss manuell sein. Aber kritische Übergänge sollten bewusst gestaltet werden:

• von Analyse zu Änderung;
• von Änderung zu Merge;
• von Merge zu Deployment;
• von internem Kommentar zu externer Kommunikation;
• von Leserechten zu Schreibrechten.

Ein guter Workflow macht die schnelle Route einfach, aber nicht unsichtbar.

5. Was wird protokolliert?

Wenn ein Agent Teil der Delivery-Pipeline ist, braucht das Team nachvollziehbare Spuren.

Mindestens hilfreich sind:

• welcher Prompt oder welches Ereignis den Lauf gestartet hat;
• welche Dateien gelesen wurden;
• welche Tools ausgeführt wurden;
• welche Secrets oder Rollen im Workflow verfügbar waren;
• welche Änderungen erzeugt wurden;
• welche externen Aktionen stattgefunden haben;
• wer den finalen Schritt genehmigt hat.

Auditierbarkeit ist nicht nur Compliance. Sie ist Debugging für Organisationen.

Warum deutsche Teams hier besonders vorsichtig sein sollten

Im deutschen Markt ist Software oft eng mit Vertrauen verbunden.

Mittelstand-Teams, B2B-SaaS-Anbieter, regulierte Unternehmen und interne Produktteams arbeiten mit Kundendaten, Betriebsprozessen, Vertragslogik, Rollenmodellen und langfristigen Wartungspflichten. Ein Sicherheitsvorfall ist dort nicht nur ein technisches Problem. Er wird schnell zu einem Vertrauensproblem.

Gleichzeitig ist der Nutzen von KI-gestützter Entwicklung real.

Teams können schneller refactoren, mehr Tests schreiben, bessere Dokumentation erzeugen, Altcode verstehen, interne Tools bauen und Produktideen früher validieren. Es wäre falsch, diese Möglichkeiten aus Angst zu ignorieren.

Aber es wäre genauso falsch, Agenten ungeplant in Delivery-Pipelines zu setzen, nur weil der Demo-Flow beeindruckend aussieht.

Der richtige Weg liegt dazwischen:

KI-Agenten ja. Aber mit Architektur.

Der produktive Kompromiss: Geschwindigkeit mit Blast-Radius-Design

Ein guter AI-Delivery-Workflow ist nicht maximal frei. Er ist bewusst begrenzt.

Das klingt nach weniger Geschwindigkeit, führt aber oft zu mehr nutzbarer Geschwindigkeit. Teams verlieren weniger Zeit durch unklare Reviews, unsichere Automatisierung, kaputte Builds, nachträgliche Sicherheitsdiskussionen und “wer hat das eigentlich freigegeben?”-Momente.

Ein produktiver Aufbau kann so aussehen:

• Agenten laufen in isolierten Umgebungen;
• untrusted Input wird getrennt von privilegierten Schritten verarbeitet;
• Secrets sind pro Workflow minimiert;
• Schreibrechte sind eng geschnitten;
• Netzwerkzugriff ist begrenzt;
• kritische Aktionen brauchen explizite Zustimmung;
• generierte Änderungen laufen durch normale Tests und Reviews;
• Architekturregeln stehen im Repository;
• Logs zeigen, was der Agent getan hat;
• das Team weiss, wer den Workflow besitzt.

Das ist keine Bremse für moderne Entwicklung. Es ist die Voraussetzung dafür, dass moderne Entwicklung tragfähig wird.

Wo McDougall Digital helfen kann

Bei McDougall Digital betrachten wir KI-gestützte Softwareentwicklung nicht als Tool-Frage, sondern als Delivery-Architektur.

Die entscheidenden Fragen sind:

• Wo beschleunigt ein Agent echte Produktarbeit?
• Wo braucht er Zugriff auf Code, Tickets, Logs oder Deployments?
• Welche Rechte sind wirklich notwendig?
• Welche Entscheidungen müssen Menschen treffen?
• Welche Kontrollen gehören in CI/CD, Tests, Reviews und Betrieb?
• Wie bleibt das System wartbar, wenn die erste Euphorie vorbei ist?

Wir helfen Teams, bestehende AI-Coding-Setups zu prüfen, unsichere Workflow-Muster zu entschärfen und agentische Entwicklung so einzuführen, dass sie zu Produkt, Architektur, Sicherheit und Betrieb passt.

Das Ziel ist nicht, KI-Agenten kleinzuhalten.

Das Ziel ist, ihnen genau die richtige Verantwortung zu geben.

Denn die nächste Generation von Softwareteams wird nicht nur schneller coden. Sie wird lernen müssen, automatisierte Mitspieler sicher in echte Delivery-Systeme einzubauen.

Die Rule of Two ist dafür ein guter Anfang.