Wer Copilot-Seats in der Finanzplanung führt, sieht nur die Kostenseite. Wer sie im Zugriffsmodell führt, sieht die eigentliche Frage: Wer bekommt ein Werkzeug, das Repo-Inhalte liest und Vorschläge daraus generiert, und wie schnell lässt sich dieser Zugriff wieder entziehen. Seat-Verwaltung ist damit kein Lizenz-Thema, sondern ein IAM-Thema wie jede andere Rolle in deiner Organisation.
Ein Seat ist ein Zugriffsrecht, keine Kostenstelle
Vorausgesetzt ist dafür ein Copilot-Business- oder -Enterprise-Plan. Copilot Enterprise setzt zusätzlich einen GitHub-Enterprise-Cloud-Vertrag voraus, Copilot Business dagegen nicht. Für KMU und die GitSecOps-Zielgruppe ist Business damit auch ohne Enterprise-Cloud-Vertrag erreichbar, anders als SAML/SSO, das in GitHubs Plan-Übersicht exklusiv dem Enterprise-Tarif vorbehalten bleibt.
Seat-Zuweisung läuft über die Organisationseinstellungen oder die API
Laut GitHub-Dokumentation zur Seat-Zuweisung wird ein Seat entweder über die Organisationseinstellungen oder über die REST API vergeben, und zwar durch einen Organization Owner. Das ist keine Formalie: Seat-Vergabe ist damit an dieselbe Rolle gebunden, die auch andere privilegierte Org-Einstellungen trifft. Ein Seat selbst ist laut Dokumentation eine Lizenz zur Nutzung von Copilot, gebunden an ein einzelnes Benutzerkonto über einen Copilot-Business- oder -Enterprise-Plan der Organisation. Wer Copilot-Zugriff im eigenen Berechtigungskonzept dokumentiert, trägt diese Zuweisung deshalb in dieselbe Tabelle wie Repo- und Team-Rollen ein, nicht in eine separate Lizenzliste.
Unassign und Revoke sind zwei unterschiedliche Entzugsgeschwindigkeiten
Einen Seat wieder zu entziehen ist nicht ein einziger Vorgang, sondern zwei mit unterschiedlicher Wirkung. Laut Dokumentation erlaubt Unassign dem betroffenen Nutzer weiteren Zugriff bis zum Ende des aktuellen Abrechnungszyklus, während Revoke den Zugriff sofort entzieht. Für die Finanzplanung wirkt der Unterschied nebensächlich, für das Zugriffsmodell ist er es nicht. Bei einer internen Rollenänderung ohne besonderes Risiko reicht Unassign. Verlässt jemand das Unternehmen oder wechselt in eine Rolle ohne Berechtigung für die betroffenen Repositories, ist Revoke die richtige Wahl. Sonst entsteht ein Zeitfenster mit fortbestehendem Zugriff, das im Offboarding-Prozess dokumentiert und begründet werden muss.
Persönliche Pro-Pläne verschwinden in der Policy der Organisation
Nutzt jemand privat bereits Copilot Pro, Pro+ oder Max und bekommt zusätzlich einen Seat über die Organisation zugewiesen, kündigt GitHub laut Dokumentation den persönlichen Plan automatisch. Der Nutzer unterliegt ab diesem Zeitpunkt den Policies der Organisation. Das ist der Punkt, an dem Seat-Verwaltung sichtbar zur Zugriffssteuerung wird: Es geht nicht nur darum, wer ein Werkzeug nutzen darf, sondern unter welchem Regelwerk. Individuelle Einstellungen, die unter einem persönlichen Plan galten, werden durch die Organisationsrichtlinie ersetzt, sobald der Org-Seat aktiv wird.
Doppelte Zuweisung wird nur einmal abgerechnet, das Zugriffsmodell bleibt trotzdem offen
Ist ein Nutzer gleichzeitig über einen Business- und einen Enterprise-Seat erfasst, wird laut Dokumentation nur der Enterprise-Seat abgerechnet. Das ist eine Abrechnungsregel, keine Aussage darüber, welches Regelwerk im Zugriffsmodell tatsächlich gilt. Wer mehrere Organisationen oder Enterprise-Strukturen mit Copilot betreibt, muss diese Zuordnung deshalb separat im eigenen Berechtigungskonzept führen, unabhängig davon, was auf der Rechnung steht.
Abgrenzung zu zwei früheren Beiträgen
Diese Zugriffssteuerung setzt voraus, dass das Werkzeug selbst schon im Einsatz ist. Ob ein MCP-Server vor diesem Punkt überhaupt eingeführt werden sollte, war Thema in MCP-Server prüfen vom 26.09.2026. Dort ging es um das Vetting vor dem Einsatz, hier um die Zugriffsverwaltung danach. Und während KI-generierter Code in der Lieferkette: Was sich beim Code-Review ändert vom 09.09.2026 den Code-Review-Prozess behandelt, also was mit dem Ergebnis von Copilot passiert, geht es hier um die Steuerung des Zugriffs auf das Werkzeug selbst, bevor überhaupt ein Vorschlag entsteht.
Konsequenz für dein Zugriffsmodell
Seat-Zuweisung, Unassign/Revoke und die Policy-Übernahme bei persönlichen Plänen sind drei Hebel desselben Zugriffsmodells, nicht drei Lizenzdetails. Wer sie wie Repo- und Team-Rollen behandelt, kann im Zweifel belegen, wer wann Zugriff auf welche Repo-Inhalte über Copilot hatte und wie schnell dieser Zugriff entzogen wurde.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen