Im Beitrag „GitHub-Copilot-Zugriff verwalten: Seats und Policies als Zugriffsrecht, nicht als Lizenzfrage“ (23.10.2026) ging es darum, wer den Bot überhaupt freischalten darf. Die Frage heute ist eine andere: Was darf der Bot tun, sobald er läuft? Dort geht es darum, wer Zugriff bekommt, hier darum, was der Bot mit dem Zugriff technisch darf. Die Antwort steht in der GitHub-Dokumentation zur Responsible Use des Coding Agents und zur Agent-Firewall, Stand heute, 09.11.2026.
Lesezugriff, kein Schreibrecht des auslösenden Menschen
Der Coding Agent arbeitet in der Cloud read-only, sobald der auslösende Mensch selbst nur Leserechte auf das Repository hat. Schreibrechte des Menschen übertragen sich nicht automatisch auf den Bot. Das ist der erste Unterschied zu einem lokal laufenden Assistenten: der Agent kann nicht mehr, nur weil du ihn startest. Er bewegt sich innerhalb der Rechte, die für ihn konfiguriert sind, nicht innerhalb deiner eigenen.
Secrets nur, wenn sie explizit im copilot-Environment liegen
Zur Laufzeit hat der Agent keinen Zugriff auf Actions-Secrets oder -Variablen auf Organisations- oder Repository-Ebene. Durchgereicht werden ausschließlich Secrets und Variablen, die gezielt im copilot-Environment hinterlegt wurden. Wer glaubt, ein allgemeines Repository-Secret sei für den Agenten automatisch sichtbar, irrt. Diese Trennung ist die praktische Umsetzung dessen, was im Beitrag „Wer darf secrets: inherit setzen? Organisations-Policy beim Aufruf fremder Reusable Workflows“ (08.11.2026) für Reusable Workflows beschrieben ist: Vererbung von Zugriff ist nie ein Automatismus, sondern eine Entscheidung, die irgendwo explizit getroffen werden muss.
Ein Branch, kein automatischer Workflow-Lauf
Der Agent kann nur auf einen einzigen Branch pushen: den bestehenden PR-Branch, wenn er per @copilot in einem laufenden Pull Request aufgerufen wird, sonst einen neuen Branch mit dem Präfix copilot/. Workflows, die durch einen vom Agenten erstellten Pull Request ausgelöst würden, starten nicht automatisch. Sie brauchen die Freigabe einer Person mit Schreibzugriff auf das Repository, bevor sie laufen. Damit bleibt der Einstiegspunkt in die Pipeline an einer Stelle, an der ein Mensch mit entsprechender Berechtigung bewusst zustimmen muss, nicht an der Stelle, an der ein Agent einen Branch anlegt.
Sandbox und Firewall: Schutz mit erklärter Grenze
Jede Agenten-Session läuft in einer temporären, isolierten Umgebung, die nach Abschluss der Session zerstört wird. Zustand aus einer Session trägt sich nicht automatisch in die nächste. Standardmäßig ist zusätzlich eine Firewall aktiv, die den Netzwerkzugriff auf eine empfohlene Allowlist beschränkt: gängige Paketregistries für Sprachen wie Python, Java, JavaScript, Go oder C#, verbreitete Betriebssystem- und Container-Registries, gängige Zertifizierungsstellen zur Validierung von SSL-Zertifikaten sowie die Hosts, von denen der Playwright-MCP-Server Browser herunterlädt.
Wichtig für jeden, der eigene MCP-Server anbindet: Diese Firewall gilt nicht direkt für MCP-Server-Prozesse. Andere Agent-Prozesse, die parallel laufen, unterliegen weiterhin der Firewall, ein MCP-Server-Prozess selbst steht außerhalb dieser direkten Kontrolle. GitHub selbst nennt die Firewall ausdrücklich keine umfassende Sicherheitslösung, sondern Schutz für übliche Szenarien, mit dem Hinweis, dass gezielte Angriffe sie umgehen können. Wer MCP-Server im eigenen Setup einsetzt, sollte das zusammen mit dem Beitrag „MCP-Server prüfen“ (26.09.2026) lesen: die Firewall ersetzt die Prüfung des einzelnen MCP-Servers nicht, sie deckt ihn nicht einmal ab.
Nachvollziehbarkeit über den Commit
Commits des Coding Agents sind signiert und laufen unter Copilot als Autor, mit dem Menschen, der die Aufgabe gestartet hat, als Co-Autor. Dadurch ist im Commit-Verlauf sichtbar, wer welchen Schritt ausgelöst hat, auch wenn der Code selbst vom Agenten geschrieben wurde. Diese Zuordnung ist eine technische Eigenschaft des Agenten, keine Aussage darüber, wer inhaltlich für den Code verantwortlich ist. Verantwortung regelt weiterhin, wer den Pull Request freigibt und mergt, nicht die Autorenzeile im Commit.
Was das für dein Repo bedeutet
Die vier Grenzen zusammen (Lesezugriff statt Schreibrecht, begrenzte Secrets, ein Branch ohne automatischen Workflow-Start, eine Firewall mit erklärter Lücke bei MCP-Prozessen) ergeben kein geschlossenes Sicherheitskonzept. Sie sind einzelne technische Leitplanken, die an unterschiedlichen Stellen greifen. Wo CODEOWNERS festlegt, wer einen Pull Request des Agenten überhaupt freigeben darf, steht im Beitrag „CODEOWNERS in der Praxis: Wer wirklich verantwortlich ist“ (14.09.2026). Wo der Agent seine Arbeitsanweisungen herbekommt und warum diese Dateien ins Code-Review gehören, steht im Beitrag „AGENTS.md, CLAUDE.md und Rules-Dateien: Warum sie ins Code-Review gehören, nicht nur ins Onboarding“ (24.10.2026). Keiner dieser Beiträge für sich ersetzt die anderen, und keiner von ihnen ersetzt die Prüfung des eigenen Repos gegen die eigene Policy.
Kontakt
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