GitHub begrenzt das Informationsbudget für Enklaven in vertraulichen Repositories auf acht Bit pro Repository und Workflow-Lauf. Ein ASCII-Zeichen braucht sieben oder acht Bit. Mehr als eine knappe Ja-Nein-Antwort passt also nicht hindurch. Dieses Limit gehört zu einem Sicherheitsmechanismus, den GitHub auf der GitHub Universe vorgestellt hat, zusammen mit der allgemeinen Verfügbarkeit von GitHub Agentic Workflows. Der Mechanismus soll verhindern, dass ein KI-Agent private Repository-Inhalte in öffentliche Kommentare schreibt. Er erkennt keine Angreifer; er begrenzt den Rückkanal.
Was bei GitLost schiefging: Berechtigungen statt Sandbox-Ausbrüche
GitLost beginnt weder mit einem ausgebrochenen Container noch mit einem gestohlenen Token. Forscher von Noma Labs gaben einem Agenten Leserechte für öffentliche und private Repositories einer Organisation und ließen ihn auf Issues in einem öffentlichen Repository reagieren. Dann eröffneten sie ein bösartiges öffentliches Issue. Es brachte den Agenten dazu, Inhalte aus einem privaten Repository in einem öffentlichen Kommentar zu veröffentlichen. Der Angriff nutzte keine Lücke in der Sandbox aus. Er nutzte eine Kombination von Berechtigungen, die einzeln legitim waren.
Ein Sachbearbeiter hat einen Schlüssel zum Archiv und einen zum öffentlichen Schwarzen Brett. Jeder Schlüssel allein ist harmlos. Gefährlich wird der kombinierte Auftrag: lies dort, schreibe hier. So beschreibt GitHub den Kern: Der Zugriff war nicht gebrochen. Die Absicht des Betreibers wurde überstimmt.
Die Enclave: getrennte Ausführung und begrenzte Antwort
Eine Enclave ist bei GitHub eine einmalig verwendbare Sandbox. Der primäre Agent eines Agentic Workflows startet sie, um Arbeit in einem anderen Repository zu erledigen. Er selbst sieht nur das Repository, in dem er läuft; für alles andere beauftragt er eine Enclave. Zurück kommt kein Dateiinhalt, sondern ein Formular mit wenigen angekreuzten Feldern.
Beim Start legt der primäre Agent drei Dinge fest: das Repository der Enclave, die Aufgabe und ein Antwortschema. Ein vertrauenswürdiger Broker prüft den Startauftrag, führt die Enclave isoliert aus und validiert die Antwort, bevor sie den primären Agenten erreicht. Das Antwortschema bestimmt, was die Enclave überhaupt zurückgeben darf. Meist sind das Booleans, Aufzählungen, begrenzte Ganzzahlen und strukturierte Kombinationen dieser Typen.
Die Enclave kann keine Erklärungen anhängen, keine Dateien beilegen und keine beliebigen Zeichenketten zurückgeben. Der Broker vergleicht jede Antwort mit dem Schema und weist zurück, was nicht passt. Der Rückkanal hängt damit nicht vom Vertrauen in den Agenten ab, sondern von einer Prüfung, die vor der Ausführung feststeht. Wissen wird nur geteilt, wenn es für die konkrete Aufgabe budgetiert ist.
Das Informationsbudget: acht Bit und ein reserviertes Fehlerbit
Die Information, die ein Antwortschema tragen kann, wird in Bit gemessen. Ein Boolean hat zwei Werte und überträgt ein Bit; eine Auswahl aus vier Kategorien überträgt zwei Bit. Mehr Felder ergeben mehr mögliche Antworten und damit mehr Information. Ein Bit bleibt immer für Fehler reserviert. Validierungsfehler, Laufzeitfehler, Budgetüberschreitungen und Zeitüberschreitungen setzen dieses Fehlerbit.
Die Sensitivität des Enclave-Repositories bestimmt das Budget pro Repository und Workflow-Lauf. trusted ist ungemessen und erlaubt strukturierte Antworten mit freien Zeichenketten. public ist ebenfalls ungemessen, aber auf endliche strukturierte Antworten ohne freie Zeichenketten beschränkt. internal erlaubt 64 Bit, confidential nur 8 Bit. sealed setzt das Budget auf 0 Bit; dann sind keine repository-abgeleitete Offenlegung und keine Aufrufe zulässig. Die Abstufung trennt nicht fein, sondern zieht eine Grenze zwischen „ein Ja oder Nein“ und „eine ausführliche Erklärung“.
Vor dem Start einer Enclave berechnet der Broker die maximale Informationsladung eines schema-konformen Ergebnisses. Er prüft sie gegen das verbleibende Budget des Repositories. Die Ladung wird vor der Ausführung reserviert, nicht erst anhand der tatsächlichen Antwort bestimmt. Alle Aufrufe teilen sich ein Konto pro Repository und Lauf. Der primäre Agent kann seine Fragen anpassen, aber das Budget nicht vergrößern oder durch ein neues Schema zurücksetzen. Überschreitet eine Antwort das Guthaben, wird sie abgelehnt.
Skript-Enklaven und Agenten-Enklaven
GitHub unterscheidet zwei Arten von Enklaven. Skript-Enklaven führen begrenzte Python-Programme über schreibgeschützte Repository-Snapshots aus und haben keinen Netzwerkzugriff. Sie eignen sich für deterministische Prüfungen: ob eine Datei existiert, ob eine Abhängigkeit in einem Manifest auftaucht oder ob eine Konfiguration eine Regel erfüllt. Das Ergebnis ist eng, wiederholbar und passt gut zu einem knappen Schema.
Agenten-Enklaven starten einen separaten Coding-Agenten für Aufgaben, die Reasoning benötigen. Er kann eine Implementierung prüfen und einordnen, ob ein gemeldeter Fehler zutrifft. Sein Netzwerkzugriff ist auf den konfigurierten Modellpfad beschränkt, wenn ausdrücklich aktiviert auch auf eine schmale GitHub-Werkzeugschnittstelle. Allgemeine GitHub-Zugangsdaten oder ein offenes Netzwerk erhält er nicht.
Enklaven werden im Front Matter eines Workflows deklariert. Dasselbe private Repository kann beide Ausführungsarten erhalten. Der Workflow muss aber getrennt Zugangsdaten bereitstellen, die den Zugriff auf das Repository autorisieren. Eine Enclave-Deklaration erweitert nicht, was diese Zugangsdaten lesen dürfen. Der primäre Agent bekommt die Enclave-Werkzeuge über das MCP-Gateway und sieht weder private Snapshots noch Authentifizierungsdaten. Der Maintainer legt Repository-Richtlinie, Sensitivität und Ausführungsgrenzen fest; ein Werkzeugaufruf kann diese Einstellungen nicht einfach überschreiben.
GitLost mit Enclaves: ein Ja, ein Nein und kein README
Für GitLost beschreibt GitHub ein Szenario mit contoso/public-repo und contoso/private-repo. tools.github.allowed-repos beschränkt die GitHub-Lesezugriffe des primären Agenten auf das öffentliche Repository. Der Enclave-Eintrag erlaubt die private Analyse; sensitivity: confidential setzt für dieses Repository im Lauf ein Budget von acht Bit. safe-outputs erlaubt dem primären Agenten, einen öffentlichen Kommentar vorzuschlagen. Die Enclave kann selbst keinen Kommentar veröffentlichen.
Ein öffentliches Issue fragt etwa, ob Version 2 einer Abhängigkeit mit der privaten Integration kompatibel ist. Der primäre Agent kann die Enclave mit einem Boolean-Schema nach einer Ja-Nein-Antwort fragen. Dasselbe Schema trägt viele verschiedene Fragen; die Aufgabenbeschreibung liefert die Bedeutung. Hier heißt true kompatibel. Der Broker muss diese Bedeutung nicht verstehen. Er erkennt nur, dass das erfolgreiche Ergebnis zwei mögliche Werte hat. Der Workflow-Autor setzt die Offenlegungsgrenze; der primäre Agent entscheidet über die konkrete Verwendung.
Braucht der primäre Agent mehr Nuancen, kann er ein ausdrucksstärkeres Schema verlangen, etwa drei Kompatibilitätswerte und zwei Migrationswerte. Das ergibt sechs mögliche Erfolgsantworten und damit drei Bit. Vier Bit für Timing und eines für Erfolg oder Fehler bringen die Ladung auf genau acht Bit – das Budget eines confidential-Repositories. Der Broker reserviert diesen Worst Case vor der Ausführung, nicht nur den tatsächlich zurückkommenden Fall. Die Enclave liest dann das private Repository. Sie stößt vielleicht auf Kompatibilitätsnotizen, aber auch auf einen fremden vertraulichen Projektnamen oder ein Startdatum. Ihre Antwort muss trotzdem in das Schema passen. Der Broker validiert sie und gibt nur das begrenzte Ergebnis an den primären Agenten weiter, der einen öffentlichen Kommentar vorschlagen kann. Die privaten Dateien und die Analyse der Enclave gelangen nie in den Kontext des primären Agenten.
Enthält das Issue die GitLost-Anweisung, ein privates README zu holen und in den öffentlichen Kommentar zu kleben, greifen mehrere Sperren. Ein direkter Lesezugriff des primären Agenten liegt außerhalb seines Repository-Bereichs. Eine freie Zeichenketten-Antwort wird für ein confidential-Repository abgelehnt. Ein endliches Schema mit mehr möglichen Antworten, als das Restbudget erlaubt, wird ebenfalls verweigert. Hängt die Enclave einer eingeschleusten Anweisung folgend das README an das Kompatibilitätsergebnis an, scheitert die Antwort an der Validierung. Der primäre Agent erhält einen begrenzten Fehler, nicht die abgelehnte Antwort und keinen Auszug daraus. Weitere Aufrufe oder ein neues Schema füllen das Budget nicht wieder auf.
Was die Garantie leistet und was nicht
GitHub formuliert die Grenze ausdrücklich: Die Enclave verhindert nicht jede Information, die das private Repository verlässt. Die Kompatibilitätsantwort ist eine beabsichtigte Offenlegung. Ein kompromittierter Agent könnte mit seinen erlaubten Antworten auch andere Informationen signalisieren, aber nur innerhalb des erzwungenen Budgets. Die Garantie ist eine Obergrenze für Kommunikation. Sie besagt nicht, dass jede mögliche Frage und Antwort sicher ist.
Ein endliches Schema allein löst das Problem nicht. Ein Angreifer könnte wiederholt Boolean-Fragen über einzelne Bits eines Geheimnisses stellen und es so rekonstruieren. Enklaven rechnen die Offenlegung deshalb über den gesamten Workflow-Lauf ab, nicht nur innerhalb einer Antwort. Jedes Repository hat ein gemeinsames Budget, das sich aus seiner Sensitivität ergibt. Wer Cross-Repository-Workflows absichern will, muss diese gemeinsame Abrechnung mitdenken. Sie ist keine einmalige Abfragegrenze.
Für den Betrieb heißt das: Der Maintainer legt Sensitivität, Repository-Richtlinie und Ausführungsgrenzen fest. Die Zugangsdaten müssen separat so gesetzt sein, dass sie den gewünschten Zugriff ermöglichen, ohne ihn heimlich auszuweiten. Das private Repository darf außerdem nicht zusätzlich im Arbeitsbereich des primären Agenten ausgecheckt oder über ein anderes Werkzeug erreichbar sein. Wer Agenten den Zugriff auf private Daten beschränken will, bekommt hier ein begrenztes Werkzeug. Die vollständige Sicherheitsentscheidung nimmt es ihm nicht ab. Acht Bit reichen nicht für eine Akte, aber für eine Ja-Nein-Antwort oder ein kleines Schema.
Quelle: githubnext.com
