KI Code Review: Berechtigungen für GitHub und Azure DevOps

7. August 2026 · 6 Min. Lesezeit

Code Reviews sind ein naheliegender Einsatzort für KI-Agenten im Entwicklungsprozess. Ein Agent kann einen Pull Request (PR) lesen, ihn mit dem restlichen Repository abgleichen, die CI-Ergebnisse prüfen und innerhalb weniger Minuten Kommentare hinterlassen, noch bevor ein menschlicher Reviewer den Diff geöffnet hat. Werkzeuge wie Claude Code, Cursor oder VS Code können das über das Model Context Protocol (MCP) tun, sobald sie mit GitHub oder Azure DevOps verbunden sind.

Schwierig ist dabei nicht das Review selbst, sondern die Berechtigungen dahinter. Dieselbe Verbindung, über die ein Agent einen Pull Request kommentiert, erlaubt je nach Token auch, ihn freizugeben, zu mergen, auf einen Branch zu pushen oder ein Release anzustoßen. Dieser Beitrag beschreibt, welche Rechte ein Review-Agent tatsächlich braucht, wo die eigentlichen Risiken liegen und wie sich der Zugriff eingrenzen lässt. Er gehört zu unserer Reihe über KI-Agenten in der Softwareentwicklung.

Was ein Review-Agent tun muss

Ein Review-Agent hat eine klar umrissene Aufgabe. Er liest die geänderten Dateien, die Commits des PRs, zugehörige Dateien im Repository und bei Bedarf die Ergebnisse des CI-Workflows. Seine Befunde schreibt er als Review-Kommentare oder als allgemeinen Kommentar in den PR. Manche Teams lassen den Agenten zusätzlich weitere Reviewer anfragen, wenn eine Änderung einen sensiblen Bereich betrifft.

Dafür braucht der Agent Lesezugriff auf Repository, Pull Request und Workflow-Läufe sowie das Recht zu kommentieren. Er muss keine Dateien schreiben, keine Branches anlegen, keine Pull Requests mergen und keine Releases erstellen. Das sind andere Aufgaben, und wenn ein Team dafür einen Agenten einsetzen möchte, ist das ein anderer Agent mit einem anderen Risikoprofil.

Wo die eigentlichen Risiken liegen

Drei Operationen verdienen besondere Aufmerksamkeit, weil sie den Zustand des Codes verändern, statt ihn nur zu beschreiben.

Einen Pull Request freigeben. Ein Review mit dem Ergebnis APPROVE zählt zu den erforderlichen Freigaben eines geschützten Branches, sofern das Konto hinter dem Token als Reviewer berechtigt ist. Ein Agent, der seine eigenen Befunde freigibt oder den PR eines anderen Agenten genehmigt, kann damit das Vier-Augen-Prinzip umgehen, das der Branch-Schutz eigentlich sicherstellen soll.

Einen Pull Request mergen. Der Merge bringt die Änderung in den Hauptzweig und startet in vielen Setups ein Deployment. An dieser Stelle hat eine falsche Entscheidung die größte Wirkung.

Dateien schreiben und Workflows auslösen. Das Schreiben einer Datei erzeugt einen Commit. Das Auslösen oder erneute Starten eines Workflows kann einen Build oder ein Deployment mit den Secrets des Repositorys starten. Beides sind berechtigte Aufgaben für Automatisierung, aber nicht für einen Review-Agenten.

Dazu kommt ein viertes, weniger sichtbares Risiko: Prompt Injection. Der Agent liest Texte, die andere Menschen geschrieben haben, etwa PR-Beschreibungen, Code-Kommentare und Issue-Texte. Enthalten diese Texte Anweisungen an das Modell, versucht ein schlecht begrenzter Agent unter Umständen, ihnen zu folgen. Die Berechtigungen des Agenten bestimmen, wie groß der Schaden einer solchen Anweisung im schlimmsten Fall werden kann.

Warum ein Personal Access Token die falsche Einheit ist

Ein Personal Access Token auf GitHub oder Azure DevOps hat die Rechte der Person, die es erstellt hat. Fine-grained Tokens auf GitHub verbessern das, indem sie Repositories und Berechtigungskategorien einschränken, doch diese Kategorien sind grob. Schreibrechte auf Pull Requests erlauben einen Kommentar ebenso wie eine Freigabe, und eine Regel wie „kommentieren, aber niemals freigeben“ lässt sich mit dem Token nicht ausdrücken. Im Audit-Trail erscheint außerdem das Konto der Person, nicht der Agent.

Besser passt die Operation als Einheit: kommentieren, Review anlegen, mergen, Datei schreiben. Jede davon lässt sich einzeln erlauben oder verbieten, für ein bestimmtes Repository und einen bestimmten Branch.

Wie Vordix einen Review-Agenten eingrenzt

Vordix ist ein selbst gehostetes Gateway zwischen Agenten und Tools. Der Agent verbindet sich mit einem Vordix-Workspace, und jeder Aufruf wird geprüft, bevor er GitHub oder Azure DevOps erreicht.

Operationen werden einzeln freigeschaltet. Für GitHub stellt Vordix Lesezugriffe auf Dateien, Branches, Commits, Issues, Pull Requests, PR-Dateien und PR-Commits, Reviews, Workflows, Läufe und Releases bereit. Auf der Schreibseite gibt es getrennte Operationen für Kommentare, das Anlegen eines Reviews, die Freigabe eines PRs, das Anfragen von Reviewern, das Erstellen oder Ändern eines PRs, den Merge, das Schreiben oder Löschen einer Datei, das Anlegen oder Löschen eines Branches, das Auslösen, Wiederholen oder Abbrechen eines Workflows und das Erstellen eines Releases. Für Azure DevOps decken die entsprechenden Operationen Repositories, Dateien, Branches, Commits, Pull Requests mit Kommentaren und Pipelines ab. Jede Operation ist zunächst deaktiviert, und der Workspace eines Review-Agenten erhält nur die Lesezugriffe und das Kommentieren.

Repositories und Branches stehen auf einer Allowlist. Der Zugriff auf GitHub ist pro Repository abgegrenzt, darunter gibt es eine Allowlist für Branches (und bei der Suche für Autoren). Azure DevOps ist pro Projekt abgegrenzt, mit einer Allowlist der Repositories je Projekt. Ein Review-Agent für den Payment-Service sieht also genau dieses Repository und sonst nichts.

Freigabe und Merge sind getrennte Entscheidungen. Da create_review, approve_pr und merge_pr eigene Operationen sind, kann ein Team einem Agenten Reviews erlauben, ohne ihm Freigaberechte zu geben: create_review kann nur kommentieren oder Änderungen anfordern, eine Freigabe ist nur über approve_pr möglich, und diese Operation bleibt deaktiviert, bis jemand sie einschaltet. Möchte ein Team einen Agenten doch mergen lassen, etwa bei Dependency-Updates, kann es eine Freigaberegel an merge_pr binden: Der Aufruf wird angehalten, bis ein Mensch ihn bestätigt. Solche Regeln legt ein Admin pro Operation fest; standardmäßig ist keine Freigabe erforderlich.

Ein Review-Workspace in der Praxis: Lesen und Kommentieren gehen an GitHub durch, approve_pr und merge_pr werden abgelehnt, weil sie nicht freigeschaltet sind.

Ein Workspace pro Agent. Unterschiedliche Agenten erhalten unterschiedliche Workspaces. Der Review-Agent und ein Release-Agent teilen sich keine Rechte, und jeder hat seinen eigenen API-Key, sein eigenes Rate Limit und seinen eigenen Audit-Trail. Über einen Kill Switch lässt sich ein Workspace außerdem sofort abschalten.

Prompt Injection kann markiert oder blockiert werden. Vordix kann die Parameter prüfen, die ein Agent sendet, und verdächtige Inhalte entweder markieren oder den Aufruf ablehnen, bei Schreiboperationen mit strengerer Behandlung. Das macht Injection nicht unmöglich, ergänzt aber eine Prüfung genau an der Stelle, an der der Agent handeln will.

Jede Entscheidung wird protokolliert. Erlaubte, abgelehnte und angehaltene Aufrufe landen in einem Audit-Log, das nur ergänzt werden kann und über eine Hash-Kette abgesichert ist. Versucht ein Agent ohne Berechtigung zu mergen, sind der Versuch und der Grund der Ablehnung im Nachhinein sichtbar. Was ein solches Protokoll enthalten sollte, beschreibt der Beitrag über Audit-Logs für KI-Agenten.

Grenzen

Einige Kontrollen gibt es derzeit noch nicht, und sie sind für Review-Workflows relevant. Labels, Assignees und die Liste der angefragten Reviewer werden heute nicht über Allowlists gesteuert: Darf der Agent Reviewer anfragen, darf er jeden Reviewer anfragen.

Vordix ersetzt außerdem keinen Branch-Schutz. Erforderliche Reviews, Status Checks und Code Owners sollten weiterhin in GitHub oder Azure DevOps konfiguriert bleiben. Das Gateway entscheidet, was der Agent versuchen darf; der Branch-Schutz entscheidet, was das Repository annimmt. Beide Ebenen zusammen sind robuster als jede für sich.

Zwei Kontrollebenen: Vordix prüft Operation, Repository und Branch, bevor der Aufruf das Gateway verlässt; der Branch-Schutz entscheidet weiterhin, was in main landet.

Schließlich ist ein sauber begrenzter Agent nicht automatisch ein guter Reviewer. Er kann Probleme übersehen oder Unwichtiges kommentieren. Die Berechtigungen begrenzen den möglichen Schaden, der Nutzen des Reviews hängt aber weiterhin vom Modell, vom Prompt und davon ab, dass das Team die Kommentare kritisch liest.

Fazit

Ein KI-Agent für Code Reviews braucht Lesezugriff und das Recht zu kommentieren. Freigabe, Merge, Schreibzugriffe auf Dateien und das Auslösen von Workflows sind eigene Risiken und sollten eigene Entscheidungen sein. Eine Begrenzung nach Operation, Repository und Branch, ein Workspace pro Agent und ein vollständiger Audit-Trail machen es möglich, Agenten im Review einzusetzen, ohne die Schutzmechanismen des Hauptzweigs zu schwächen. Für die Planungsseite desselben Prozesses siehe KI-Agenten in der Jira-Sprintplanung, für die zugrunde liegende Architektur den Beitrag Was ist ein MCP Gateway?.

Die Vordix-Dokumentation listet die Operationen für GitHub und Azure DevOps im Detail auf; in einer Demo zeigen wir einen Review-Workspace an einem echten Repository.