Ein Service Principal in Azure DevOps ist eine nicht-menschliche Identität aus Microsoft Entra ID für Dienste und Automatisierungen in Azure DevOps Services. Er trennt technische Zugriffe von Benutzerkonten und macht Rechte gezielter steuerbar; für Freigaben und Schutzregeln sind davon Branch Policies und PR-Status als Richtlinie getrennt zu betrachten.
Für den Betrieb hilft eine einfache Dreiteilung:
- Identität: Wer meldet sich technisch an?
- Berechtigung: Was darf diese Identität tun?
- Richtlinie: Welche Prüfungen müssen vor dem Abschluss eines Pull Requests erfüllt sein?
Diese Trennung verhindert, dass Anmeldekonto, Rechte und Merge-Schutz in der Planung vermischt werden. Gerade bei Repositories ist das wichtig, weil eine Identität nicht automatisch Regeln umgehen sollte; dazu passt auch der Blick auf Bypass-Rechte.
Im weiteren Verlauf des Beitrags geht es deshalb um nicht-menschliche Identitäten in Azure DevOps Services, ihre Abgrenzung und den sinnvollen Einsatz im Betrieb. Azure DevOps Server wird nur dort angesprochen, wo Unterschiede für die Entscheidung relevant sind.
Die Optionen für nicht-menschliche Identitäten in Azure DevOps
Zunächst ist der Begriff sauber zu trennen: Ein Service Principal ist eine Anwendungsidentität aus Microsoft Entra ID. Er steht nicht für eine Person, sondern für eine Anwendung oder einen Dienst, der sich technisch gegenüber Azure DevOps Services ausweist.
Praktisch ist das die passende Form, wenn ein eigener oder externer Dienst auf Azure DevOps zugreifen soll, ohne das Benutzerkonto eines Mitarbeiters zu verwenden. Typische Fälle sind API-Zugriffe, Automatisierung rund um Repositories oder Prozesse, die Pull Requests anlegen oder aktualisieren. Wenn Sie solche Abläufe technisch entkoppeln wollen, ist auch der Blick auf Pull Requests per REST API sinnvoll.
Davon zu unterscheiden ist die Managed Identity. Auch sie ist eine nicht-menschliche Identität, wird aber von Azure für eine Ressource bereitgestellt. Sie passt vor allem dann, wenn Ihr Dienst in Azure läuft und der Zielzugriff Entra-basierte Authentifizierung unterstützt.
Daneben gibt es in Azure DevOps weitere technische Identitäten:
- Build-Service-Konten und verwandte Systemidentitäten für Pipelines und interne Systemvorgänge
- Service Connections als gespeicherte Verbindungen zu Zielsystemen
- darin wiederum unterschiedliche Authentifizierungsarten, etwa über Service Principal, Managed Identity oder ein anderes Verfahren
Wichtig ist dabei: Eine Service Connection ist nicht selbst dasselbe wie ein Service Principal. Sie ist die Verbindungskonfiguration in Azure DevOps; welche Identität darunter liegt, ist eine eigene Entscheidung. Für Ereignis-getriebene Automatisierung ist in diesem Zusammenhang auch der Artikel zu Service Hooks für Pull Requests nützlich.
Der eigentliche Nutzen nicht-menschlicher Identitäten liegt in der Trennung nach Aufgabe. Sie können Rechte pro Funktion zuschneiden, statt ein einziges Benutzerkonto für alles zu verwenden. Das wird auch dort wichtig, wo Sie Schutzmechanismen und Abläufe später als Code verwalten.
Für Azure DevOps Services sind Entra-basierte Identitäten heute der natürliche Bezugspunkt. Azure DevOps Server hat andere Randbedingungen und unterstützt moderne Cloud-Funktionen nicht in gleicher Weise. Ein belastbarer Hinweis dazu: Microsofts Dokumentation nannte für Azure DevOps MCP Server am 24.10.2026 keine Unterstützung für Azure DevOps Server (Microsoft Learn, „Remote MCP server troubleshooting“, geprüft 24.10.2026).
Warum PATs eine letzte Wahl sind
Ein Personal Access Token ist ein geheimes Zugriffstoken, das an ein Benutzerkonto gebunden ist und Aufrufe gegenüber Azure DevOps im Namen dieser Person ausführt.
Für den Betrieb ist das oft genau der Haken. Die Automation erscheint nach außen nicht als eigener technischer Akteur, sondern als Benutzeraktivität. Das erschwert die saubere Zuordnung in Protokollen, Freigaben und internen Kontrollen.
Hinzu kommt die Abhängigkeit vom Lebenszyklus des Kontos. Ändern sich Rolle, Gruppenmitgliedschaften oder der Status des Mitarbeiters, kann die Automation unbeabsichtigt mitbetroffen sein. Die technische Funktion hängt dann an einem personengebundenen Zugang, obwohl sie fachlich davon getrennt sein sollte.
Auch organisatorisch ist ein PAT meist aufwendiger, als es zunächst wirkt:
- Ausgabe und sichere Ablage müssen geregelt sein
- Rotation und Widerruf brauchen einen festen Prozess
- Reichweite und Zweck sollten dokumentiert sein
- Alt-Tokens bleiben sonst leicht zu lange bestehen
Gerade wenn Sie Abläufe später sauber auswerten wollen, stört diese Vermischung von Mensch und Automation. Die Frage ist dann nicht nur, was passiert ist, sondern auch, wer tatsächlich gehandelt hat.
Ein PAT kann trotzdem als Übergangslösung vorkommen, wenn ein Werkzeug keinen anderen Zugriffspfad unterstützt. Dann sollte der Einsatz eng begrenzt, klar befristet und fachlich begründet sein.
Sobald Automatisierung näher an Code, Pull Requests oder Reviews rückt, lohnt sich eine nüchterne Architekturentscheidung. Bei solchen Entwürfen ist vor allem wichtig, Rollen, Rechte und technische Grenzen getrennt zu planen; dazu passt auch der Blick auf agentische Abläufe in Azure DevOps.
Getrennte Identitäten pro Rolle
Ein Rollenmodell für technische Identitäten beginnt in Azure DevOps nicht bei der Frage „Welche Automation wollen wir bauen?“, sondern bei „Welche einzelne Handlung muss diese Identität ausführen?“. Genau daraus leiten sich Rechte ab.
Sinnvolle Rollen sind oft getrennt nach:
- Lesen von Repository- und PR-Daten
- Anlegen oder Aktualisieren von Pull Requests
- Melden eines PR-Status
- Ausführen build-naher Aufgaben
Der Punkt dabei: Ein Status an einem Pull Request ist nicht dasselbe wie eine Freigabe. Wer nur einen Status setzt, braucht dafür eine eigene technische Identität mit engem Umfang. So bleibt prüfbar, welche Komponente was getan hat, und Sie vermeiden, dass eine Funktion stillschweigend Rechte für andere Schritte mitbekommt.
Für den Hauptbranch nennt Microsoft als Orientierung eine kleine Administratorengruppe für die Berechtigungen „Bypass policies when completing pull requests“ und „Bypass policies when pushing“. Dazu kommen mindestens zwei Reviewer, automatisch einbezogene Reviewer für sensible Pfade, verknüpfte Work Items, Build Validation und Comment Resolution (Microsoft Learn, „Secure Azure Repos and GitHub repositories with pull request and branch policies“, gelesen 01.11.2026). Eine technische Identität für Statusmeldungen gehört deshalb in der Regel nicht in diese Bypass-Gruppe.
Ebenso sollten Sie „Limit merge types“ nicht mit einem Sicherheitsmechanismus verwechseln. Die Einstellung steuert die Historie. Microsoft beschreibt sie als Governance-Thema; ob Squash oder Merge-Commit passt, hängt unter anderem davon ab, ob Ihre Nachvollziehbarkeit die genaue Commit-Reihenfolge braucht (Microsoft Learn, „Branch policies“ und „Secure Azure Repos and GitHub repositories with pull request and branch policies“, gelesen 01.11.2026).
Wenn Sie solche Rollen für neue agentische Abläufe bewerten, helfen drei getrennte Fragen: Welche Identität handelt, welche Daten fließen, und welche Schutzplanken greifen wirklich. Für den derzeit beschriebenen Stand solcher Punkte sind die aktuellen Sicherheits- und Datenangaben, der öffentliche Änderungsverlauf, später belegte Messergebnisse und der vorgesehene Rahmen für Anmeldung und Pakete die passenden Stellen.
Seats und Lizenzierung auf allgemeiner Ebene
Bei Service Principal und Lizenzierung in Azure DevOps führt die Frage oft in die falsche Richtung. Nicht der Name der Identität entscheidet, sondern wie sie Azure DevOps tatsächlich nutzt.
Für die Einordnung helfen drei Blickwinkel:
- Welche Funktion wird verwendet?
- Über welchen Zugriffspfad erfolgt der Zugriff?
- Tritt die Identität nur technisch im Hintergrund auf oder nutzt sie Funktionen, die sonst Personen vorbehalten sind?
Darum ist eine allgemeine Aussage wie „Service Principals brauchen immer einen Seat“ oder „nie einen Seat“ nicht belastbar. Prüfen Sie den Fall immer an der konkreten Nutzung in Ihrer Organisation.
Gerade in gemischten Umgebungen sollten Sie zusätzlich den Produktstand beachten. Azure DevOps Services und Azure DevOps Server liegen bei neueren Funktionen nicht gleichauf. Microsoft dokumentierte am 24.10.2026, dass Copilot Code Review auf Azure DevOps Server nicht verfügbar ist; zugleich verweist Microsoft für seine KI-Dienste auf Azure DevOps Services beziehungsweise die Migration dorthin (Microsoft Learn, „Enterprise Live Migrations overview“, geprüft 24.10.2026; Microsoft-Dokumentation zu Copilot Code Review, geprüft 24.10.2026).
Für die Praxis reicht daher ein knapper Prüfpunkt: Lizenz- und Seat-Fragen nicht aus dem Identitätstyp ableiten, sondern aus Funktion, Zugriffspfad und Produktvariante.
Häufige Fragen
Kann ein Service Principal Pull Requests freigeben?
Technisch kann eine nicht-menschliche Identität in Azure DevOps Aktionen an Pull Requests ausführen. Für die Absicherung sollten Sie das aber von Review und Governance trennen.
Wichtig ist der Unterschied:
- Ein Vote oder Reviewer-Eintrag ist eine Freigabehandlung.
- Ein PR-Status ist ein technisches Signal.
- Eine Branch Policy entscheidet, was vor dem Abschluss erfüllt sein muss.
Wenn Sie Automatisierung an Pull Requests anbinden, ist ein Status-Check meist die klarere Form als eine technische „Freigabe“. Microsoft nennt als Branch Policies unter anderem Mindestanzahl an Reviewern, verknüpfte Work Items, Kommentarauflösung, Build Validation und Status Checks; alle sind standardmäßig ausgeschaltet (Microsoft Learn, „Branch policies overview“ und „Branch policies“, gelesen 01.11.2026).
Wo wird ein Service Principal in Azure DevOps praktisch eingesetzt?
Typische Einsätze liegen dort, wo ein Dienst wiederholt und nachvollziehbar auf Azure DevOps Services zugreifen soll, etwa um:
- Repository- und Pull-Request-Daten zu lesen
- Pull Requests anzulegen oder zu aktualisieren
- Status an Pull Requests zu melden
- Prozesse über REST API oder Richtlinien anzubinden
Für Azure DevOps Services lassen sich Richtlinien auch per REST API oder mit „az repos policy“ verwalten (Microsoft Learn, „Branch policies“ und „Secure Azure Repos and GitHub repositories with pull request and branch policies“, gelesen 01.11.2026).
Reicht ein Service Principal allein für sichere Pull-Request-Abläufe?
Nein. Der Service Principal ist nur die Identität. Ob ein Ablauf tragfähig ist, entscheiden zusätzlich Rechte, Branch Policies und die Trennung der Rollen.
Für Hauptbranches empfiehlt Microsoft unter anderem:
- Bypass-Rechte nur für eine kleine Administratorengruppe
- mindestens zwei Reviewer
- automatisch einbezogene Reviewer für sensible Pfade
- Prüfung verknüpfter Work Items
- Build Validation
- Kommentarauflösung
Das beschreibt Microsoft als Sicherheitsbaseline für geschützte Repositories (Microsoft Learn, „Secure Azure Repos and GitHub repositories with pull request and branch policies“, gelesen 01.11.2026).
Nächster Schritt
Machen Sie aus dem Thema eine kurze Betriebsentscheidung statt eines Grundsatzprojekts. Legen Sie für jede technische Identität schriftlich fest:
- Zweck der Identität
- verantwortliche Stelle im Betrieb
- benötigte Rechte in Azure DevOps
- Verfahren für Prüfung, Rotation und Entzug
Setzen Sie danach einen festen Kontrolltermin. Dabei geht es nicht nur um Berechtigungen, sondern auch um die Frage, ob eine Automatisierung heute noch denselben Zugriff braucht wie bei ihrer Einführung.
Sobald technische Identitäten Inhalte aus Work Items, Repositories oder Pull Requests verarbeiten, berührt das oft Datenschutz, DORA, NIS2 und Mitbestimmung. Klären Sie diese Punkte mit Ihrem Rechtsbeistand, Ihrem Datenschutzbeauftragten und gegebenenfalls dem Betriebsrat.
Im Umfeld solcher Architekturfragen entsteht bei ballmüller solutions derzeit Polier für Azure DevOps Services; Stand 01.11.2026: in Entwicklung und noch nicht erhältlich.