[{"data":1,"prerenderedAt":20},["ShallowReactive",2],{"blog-post-de-ki-code-review-berechtigungen-github-azure-devops":3},{"slug":4,"lang":5,"title":6,"description":7,"heading":6,"translationKey":8,"date":9,"keywords":10,"readingMinutes":16,"html":17,"alternates":18},"ki-code-review-berechtigungen-github-azure-devops","de","KI Code Review: Berechtigungen für GitHub und Azure DevOps","Welche Rechte ein KI-Agent für Code Reviews auf GitHub und Azure DevOps braucht, warum Approve und Merge eigene Risiken sind und wie man Repos begrenzt.","code-review-permissions","2026-08-07",[11,12,13,14,15],"KI Code Review Berechtigungen","KI Code Review GitHub","Azure DevOps Pull Request KI","Least Privilege KI-Agent","GitHub MCP Berechtigungen",6,"\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"\u002Fde\u002Fblog\u002Fki-agenten-softwareentwicklung\">KI-Agenten in der Softwareentwicklung\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Was ein Review-Agent tun muss\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Wo die eigentlichen Risiken liegen\u003C\u002Fh2>\n\u003Cp>Drei Operationen verdienen besondere Aufmerksamkeit, weil sie den Zustand des Codes verändern, statt ihn nur zu beschreiben.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Einen Pull Request freigeben.\u003C\u002Fstrong> Ein Review mit dem Ergebnis \u003Ccode>APPROVE\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Einen Pull Request mergen.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Dateien schreiben und Workflows auslösen.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Warum ein Personal Access Token die falsche Einheit ist\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Wie Vordix einen Review-Agenten eingrenzt\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Operationen werden einzeln freigeschaltet.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Repositories und Branches stehen auf einer Allowlist.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Freigabe und Merge sind getrennte Entscheidungen.\u003C\u002Fstrong> Da \u003Ccode>create_review\u003C\u002Fcode>, \u003Ccode>approve_pr\u003C\u002Fcode> und \u003Ccode>merge_pr\u003C\u002Fcode> eigene Operationen sind, kann ein Team einem Agenten Reviews erlauben, ohne ihm Freigaberechte zu geben: \u003Ccode>create_review\u003C\u002Fcode> kann nur kommentieren oder Änderungen anfordern, eine Freigabe ist nur über \u003Ccode>approve_pr\u003C\u002Fcode> 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 \u003Ccode>merge_pr\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Cfigure class=\"post-figure\">\n\u003Csvg viewBox=\"0 0 760 300\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" role=\"img\" aria-labelledby=\"crp-gate-title\">\n  \u003Ctitle id=\"crp-gate-title\">Ein Review-Agent darf Pull Requests lesen und kommentieren; Freigabe und Merge werden abgelehnt, weil sie in seinem Workspace deaktiviert sind.\u003C\u002Ftitle>\n  \u003Crect class=\"fig-box fig-box--primary\" x=\"176\" y=\"30\" width=\"320\" height=\"256\" rx=\"14\"\u002F>\n  \u003Ctext class=\"fig-h fig-c-primary\" x=\"192\" y=\"60\">VORDIX · REVIEW-WORKSPACE\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--ai\" d=\"M144 150 C170 150 170 100 190 100\"\u002F>\n  \u003Cpath class=\"fig-flow fig-flow--ok\" d=\"M482 100 C556 100 556 150 624 150\"\u002F>\n  \u003Cpath class=\"fig-flow fig-flow--ai\" d=\"M144 150 C170 150 170 150 190 150\"\u002F>\n  \u003Cpath class=\"fig-flow fig-flow--ok\" d=\"M482 150 C556 150 556 150 624 150\"\u002F>\n  \u003Cpath class=\"fig-flow fig-flow--ai\" d=\"M144 150 C170 150 170 200 190 200\"\u002F>\n  \u003Cpath class=\"fig-flow fig-flow--ai\" d=\"M144 150 C170 150 170 250 190 250\"\u002F>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"190\" y=\"80\" width=\"292\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"204\" y=\"105\">read_pr\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-ok\" x=\"470\" y=\"104\" text-anchor=\"end\">erlaubt\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"190\" y=\"130\" width=\"292\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"204\" y=\"155\">add_comment\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-ok\" x=\"470\" y=\"154\" text-anchor=\"end\">erlaubt\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--deny\" x=\"190\" y=\"180\" width=\"292\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"204\" y=\"205\">approve_pr\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-deny\" x=\"470\" y=\"204\" text-anchor=\"end\">abgelehnt · deaktiviert\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--deny\" x=\"190\" y=\"230\" width=\"292\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"204\" y=\"255\">merge_pr\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-deny\" x=\"470\" y=\"254\" text-anchor=\"end\">abgelehnt · deaktiviert\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--ai\" x=\"16\" y=\"120\" width=\"128\" height=\"60\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ai\" x=\"80\" y=\"146\" text-anchor=\"middle\">Review-Agent\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"80\" y=\"165\" text-anchor=\"middle\">1 API-Key\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"624\" y=\"110\" width=\"120\" height=\"80\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"684\" y=\"146\" text-anchor=\"middle\">GitHub\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"684\" y=\"165\" text-anchor=\"middle\">acme\u002Fpayments\u003C\u002Ftext>\n\u003C\u002Fsvg>\n\u003Cfigcaption>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.\u003C\u002Ffigcaption>\n\u003C\u002Ffigure>\n\n\u003Cp>\u003Cstrong>Ein Workspace pro Agent.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Prompt Injection kann markiert oder blockiert werden.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Jede Entscheidung wird protokolliert.\u003C\u002Fstrong> 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 \u003Ca href=\"\u002Fde\u002Fblog\u002Faudit-log-ki-agenten-eu-ai-act\">Audit-Logs für KI-Agenten\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Grenzen\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cfigure class=\"post-figure\">\n\u003Csvg viewBox=\"0 0 760 230\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" role=\"img\" aria-labelledby=\"crp-layers-title\">\n  \u003Ctitle id=\"crp-layers-title\">Zwei Ebenen: Vordix entscheidet, was der Agent versuchen darf; der Branch-Schutz entscheidet, was das Repository annimmt.\u003C\u002Ftitle>\n  \u003Cpath class=\"fig-flow\" d=\"M136 110 H672\"\u002F>\n  \u003Crect class=\"fig-box fig-box--ai\" x=\"16\" y=\"80\" width=\"120\" height=\"60\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ai\" x=\"76\" y=\"115\" text-anchor=\"middle\">Review-Agent\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--primary\" x=\"176\" y=\"30\" width=\"220\" height=\"160\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-h fig-c-primary\" x=\"192\" y=\"56\">VORDIX\u003C\u002Ftext>\n  \u003Ctext class=\"fig-t\" x=\"192\" y=\"82\">Was darf der Agent tun?\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"192\" y=\"96\" width=\"188\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"204\" y=\"112\">✓ Operation\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"192\" y=\"126\" width=\"188\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"204\" y=\"142\">✓ Repository\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"192\" y=\"156\" width=\"188\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"204\" y=\"172\">✓ Branch-Allowlist\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--muted\" x=\"432\" y=\"30\" width=\"210\" height=\"160\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-h\" x=\"448\" y=\"56\">GITHUB · AZURE DEVOPS\u003C\u002Ftext>\n  \u003Ctext class=\"fig-t\" x=\"448\" y=\"82\">Was nimmt das Repo an?\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"448\" y=\"96\" width=\"178\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"460\" y=\"112\">✓ Pflicht-Reviews\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"448\" y=\"126\" width=\"178\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"460\" y=\"142\">✓ Status Checks\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"448\" y=\"156\" width=\"178\" height=\"24\" rx=\"6\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"460\" y=\"172\">✓ Code Owners\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"672\" y=\"88\" width=\"72\" height=\"44\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ok\" x=\"708\" y=\"115\" text-anchor=\"middle\">main\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-deny\" x=\"192\" y=\"214\">× stoppt den Versuch, protokolliert\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s fig-c-deny\" x=\"448\" y=\"214\">× blockiert den Merge\u003C\u002Ftext>\n\u003C\u002Fsvg>\n\u003Cfigcaption>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.\u003C\u002Ffigcaption>\n\u003C\u002Ffigure>\n\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Fazit\u003C\u002Fh2>\n\u003Cp>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 \u003Ca href=\"\u002Fde\u002Fblog\u002Fki-agent-jira-sprintplanung\">KI-Agenten in der Jira-Sprintplanung\u003C\u002Fa>, für die zugrunde liegende Architektur den Beitrag \u003Ca href=\"\u002Fde\u002Fblog\u002Fwas-ist-ein-mcp-gateway\">Was ist ein MCP Gateway?\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n",{"de":4,"en":19},"ai-code-review-permissions-github-azure-devops",1790588073393]