Paketveröffentlichungen durch KI-Agenten ohne Release-Token-Chaos

Ein KI-Programmieragent sollte Abhängigkeiten installieren können, ohne die Berechtigung zum Veröffentlichen, Zurücknehmen, Löschen oder Umhängen von Paketen zu besitzen. Diese Aktionen liegen in der Kommandozeile scheinbar nah beieinander, haben aber völlig unterschiedliche Folgen. Wer sie mit einer einzigen Berechtigung abdeckt, macht aus routinemäßiger Entwicklungsarbeit eine Release-Berechtigung.

Ich habe erlebt, wie sich Release-Zugangsdaten verbreiteten, weil ein Team einem Agenten einen harmlosen Installationsbefehl ermöglichen wollte. Danach lag das Token in einer Shell-Umgebung, einer Konfigurationsdatei oder der Befehlsausgabe, wo jedes Tool dieses Laufs es wiederverwenden konnte. Der spätere Fehler beginnt selten mit einem spektakulären Angriff. Er beginnt damit, dass ein Agent npm publish gegen die falsche Registry ausführt, latest verschiebt, bevor jemand den Tarball geprüft hat, oder ein Zurücknehmen der Veröffentlichung versucht, weil er eine Bitte zum Aufräumen eines Tests zu wörtlich verstanden hat.

Lesezugriff auf eine Registry verleiht keine Release-Berechtigung

Paketinstallation und Paketveröffentlichung verwenden dieselbe Familie von Registry-Endpunkten, beantworten aber unterschiedliche Vertrauensfragen. Ein Download fragt: «Darf dieser Prozess ein Artefakt abrufen?» Eine Veröffentlichung fragt: «Darf dieser Prozess unter diesem Namen einen öffentlichen oder für die Organisation sichtbaren Release erzeugen?» Ein Löschen oder Zurücknehmen fragt: «Darf dieser Prozess den Verlauf und die Verfügbarkeit eines Releases verändern, den andere Builds möglicherweise bereits verwenden?»

Fasse diese Fragen nicht zu einer einzigen Zugangsdaten zusammen, nur weil der Registry-Client sie ähnlich aussehen lässt. Ein Paketmanager kann die Konfiguration für npm ci, npm publish, npm dist-tag add und npm unpublish aus derselben .npmrc-Datei lesen. Diese Dateistruktur ist eine Bequemlichkeit des Clients, kein Berechtigungsmodell.

Teile Registry-Aktionen für einen Agenten mindestens in diese Gruppen auf:

• Lesen: Metadaten abfragen, Tarballs herunterladen, Integrität prüfen und Abhängigkeiten installieren.
• Veröffentlichen: Eine neue unveränderliche Version unter einem genehmigten Paketnamen anlegen.
• Routing: Änderungen an veränderlichen Kanälen wie latest, Pre-Release-Tags oder Registry-Zugriffseinstellungen.
• Destruktiv: Veröffentlichung zurücknehmen, Pakete löschen, sofern die Registry das erlaubt, und Release-Tags entfernen.

Der Unterschied zwischen Veröffentlichen und Routing ist wichtiger, als viele Release-Skripte zugeben. Ein Paket mit einer bestimmten Versionsnummer kann in Ordnung sein, während die Zuweisung zu latest neue Nutzer dorthin schickt. Umgekehrt kann ein Pre-Release unter einem eigenen Tag risikoarm sein, wenn Nutzer diesen Tag ausdrücklich auswählen müssen. Die Paketdaten und der Weg, den Nutzer zu ihnen nehmen, sind getrennte Kontrollen.

Löschen verdient eine eigene Kategorie, selbst wenn eine Registry es einschränkt. Die Regeln unterscheiden sich, und manche als «Löschen» bezeichneten Aktionen verbergen ein Artefakt nur oder markieren es als nicht verfügbar. Harmlos wird die Aktion dadurch nicht. Sie kann reproduzierbare Installationen, Untersuchungen von Vorfällen und Teams beeinträchtigen, die die entfernte Version fest eingetragen hatten. Ein Agent darf niemals daraus schließen, dass das Aufräumen sicher ist, nur weil die Version erst vor wenigen Minuten veröffentlicht wurde.

Breite Publish-Tokens scheitern im Alltag

Ein Registry-Token in der Umgebung eines Agenten ist eine Berechtigung in einem praktischen Dateiformat. Es ist keine beschränkte Handlungsanweisung. Wenn der Agent die Umgebung oder eine Konfigurationsdatei lesen kann, kann eine Prompt-Injection in einer Abhängigkeit, einem Issue-Template, einem Build-Log oder kopiertem Terminaltext auf die Zugangsdaten zugreifen.

Die übliche Empfehlung lautet, ein Token mit dem kleinsten Umfang zu verwenden, den die Registry anbietet. Das ist richtig, reicht aber nicht aus. Ein auf Veröffentlichungen beschränktes Token kann weiterhin eine unerwünschte Version veröffentlichen, ein falsches Paket verwenden, auf das sein Konto Zugriff hat, oder an einen Registry-Endpunkt senden, der durch eine veränderte Konfiguration ausgewählt wurde. Ein begrenzter Umfang reduziert den möglichen Schaden. Er stellt aber nicht die Absicht für jeden einzelnen Release fest.

Ein Fehler, den ich mehr als einmal beheben musste, sieht so aus:

1. Ein Team gibt einem Agenten ein Registry-Token, damit er Release-Prüfungen ausführen kann.
2. Die Projektkonfiguration zeigt auf die Produktions-Registry, weil das auch auf den Rechnern der Entwickler so ist.
3. Der Agent muss den Paketinhalt prüfen und führt npm pack aus. Das ist harmlos.
4. Eine Folgeanweisung lautet, das «Veröffentlichen zu testen», und der Agent führt npm publish aus, statt an ein isoliertes Ziel zu veröffentlichen.
5. Der Befehl ist erfolgreich, weil Token und Paketname gültig sind. Das Team bemerkt es erst, nachdem die Automatisierung oder Nutzer die neue Version sehen.

Dafür braucht es keinen Angreifer. Das Design hat einem Planungssystem eine Zugangsdaten gegeben und darauf vertraut, dass es eine Grenze einhält, die die Betriebsumgebung nicht durchgesetzt hat.

Halte die Zugangsdaten aus dem Agentenprozess heraus. Ein separates Aktions-Gateway kann sie verwahren und einen bestimmten HTTP-Aufruf oder Befehl ausführen, nachdem es das gewünschte Ziel geprüft und die erforderliche menschliche Genehmigung eingeholt hat. Sallyport folgt diesem Muster: Der Agent erhält das Ergebnis einer autorisierten Aktion, niemals das Registry-Token selbst.

Auch dieses Design braucht gute Aktionsdefinitionen. Ein Gateway, das «jede Anfrage an registry.example» genehmigt, hat das Problem des breiten Tokens nur hinter eine Schaltfläche verschoben. Die Anfrage muss genügend sichtbare Details enthalten, damit der Genehmigende einen Tarball-Abruf von einer Versionsveröffentlichung und eine Veröffentlichung von einem Zurücknehmen unterscheiden kann.

Die Release-Anfrage vor der Ausführung prüfbar machen

Ein Mensch kann eine vage Anweisung wie «Veröffentliche das Paket» nicht sinnvoll genehmigen. Die Genehmigungsansicht sollte die Paketkennung, die exakte Version, den Registry-Host, die Aktion und eine mögliche Tag-Änderung zeigen. Wenn der Agent diese Felder nicht liefern kann, hat er noch keine Release-Anfrage vorbereitet.

Bei einer npm-kompatiblen Registry solltest du die Arbeit in eine Artefaktprüfung und eine Änderungsphase für die Registry aufteilen. Die Prüfung kann ohne Veröffentlichungsberechtigung laufen:

npm ci
npm test
npm pack --json

npm pack --json gibt strukturierte Informationen über den Tarball zurück, den der Befehl erstellen würde. Die wichtigen Teile sehen ungefähr so aus:

[
  {
    "id": "@acme/[email protected]",
    "name": "@acme/widget",
    "version": "1.4.0",
    "filename": "acme-widget-1.4.0.tgz",
    "files": [
      {"path": "README.md", "size": 2400},
      {"path": "dist/index.js", "size": 18420},
      {"path": "package.json", "size": 910}
    ]
  }
]

Prüfe die Dateiliste, nicht nur den Exit-Code. Ich achte auf Quellverzeichnisse, die privat bleiben sollten, Test-Fixtures mit Zugangsdaten, ein fehlendes kompiliertes Ausgabeverzeichnis und Paketmetadaten mit dem falschen Einstiegspunkt. Bei npm pack lassen sich solche Fehler noch günstig beheben.

Erfasse anschließend den Zustand der Registry getrennt. Die npm-CLI-Dokumentation beschreibt npm view als Möglichkeit, Paketmetadaten aus der Registry zu prüfen. Stelle damit konkrete Fragen, statt einen großen, unübersichtlichen Datenblock abzurufen:

npm view @acme/widget version dist-tags --json
npm view @acme/[email protected] dist --json

Der erste Befehl zeigt, welche Version existiert und wohin die Tags zeigen. Der zweite ist nach der Veröffentlichung nützlich, weil dist die von der Registry aufgezeichnete Tarball-Adresse und Integritätsdaten enthält. Ein Release-Workflow sollte diese Ausgabe ohne Geheimnisse im Release-Vermerk aufbewahren. Sie zeigt, was die Registry akzeptiert hat, statt nur, was das lokale Verzeichnis senden wollte.

Erstelle aus diesen Fakten eine Genehmigungsanfrage. Eine gute Anfrage lautet: Veröffentliche @acme/[email protected] auf registry.example, ohne einen Tag zu verschieben. Eine schlechte Anfrage lautet: Führe npm publish aus. Bei der ersten kann ein Prüfer einen Namespace-Fehler erkennen. Die zweite verlangt, dass er die Absicht aus einem möglicherweise nicht vertrauenswürdigen Befehl rekonstruiert.

Ein Wegwerf-Paket beweist den Registry-Weg

Ein Wegwerf-Paket ist die sicherste Möglichkeit, den Weg zu testen, der aus einem vorbereiteten Tarball einen abrufbaren Registry-Release macht. Es beweist nicht, dass dein Produktionspaket bereit ist. Es zeigt, dass Authentifizierung, Registry-Auswahl, Veröffentlichungsmechanik und saubere Installation unter Kontrollen zusammenspielen, die dem echten Release ähneln.

Verwende einen Paketnamen unter einem Namespace, den du kontrollierst, und mache deutlich, dass das Paket nur vorübergehend ist. Imitiere keinen bekannten Paketnamen und verwende keinen Namen, der später versehentlich zu einem echten Produkt werden könnte. Packe ein winziges, harmloses Modul hinein. Seine Aufgabe ist die Veröffentlichung und Installation, nicht die Demonstration von Anwendungsverhalten.

Diese minimale package.json hält den Test übersichtlich:

{
  "name": "@acme-release-test/relay-check-2025-04",
  "version": "0.0.1",
  "description": "Temporary registry release-path check",
  "main": "index.js",
  "files": ["index.js", "README.md"],
  "publishConfig": {
    "access": "restricted"
  }
}

Wähle Zugriffseinstellungen, die dem tatsächlichen Pakettyp entsprechen. Kopiere restricted nicht blind, wenn dein echtes Paket öffentlich ist. Mache aber auch ein Wegwerf-Testpaket nicht öffentlich, nur weil das realistischer wirkt. Entscheidend ist, dieselbe Autorisierung und dieselbe Grenze für den vorgesehenen Nutzerkreis zu testen. Wenn du öffentliche Veröffentlichungen testen musst, verwende einen ausdrücklich temporären öffentlichen Namen und prüfe vorab die Aufbewahrungs- und Zurücknahmeregeln der Registry.

Führe den Test in einem frischen Verzeichnis aus, damit zwischengespeicherte Metadaten und ein vorhandener Workspace das Ergebnis nicht besser aussehen lassen:

mkdir release-path-check
cd release-path-check
npm init -y
npm install @acme-release-test/[email protected]
node -e "console.log(require('@acme-release-test/relay-check-2025-04'))"

Eine erfolgreiche npm install beantwortet eine bessere Frage als eine erfolgreiche Publish-Antwort: Kann ein sauberer Consumer die genannte Version auflösen und abrufen? Wenn dein Paket Exports, Typdeklarationen, ein Kommandozeilen-Binary oder ein Postinstall-Skript verwendet, teste in diesem frischen Verzeichnis auch den jeweiligen öffentlichen Einstiegspunkt. Dass die Registry das Paket gespeichert hat, bedeutet nicht automatisch, dass der Consumer es verwenden kann.

Lösche das Testpaket nicht nur, damit das Konto ordentlich aussieht. Hinterlasse nach den normalen Regeln der Registry einen Audit-Verlauf oder verwende, falls passend, eine Deprecation. Ein Release-Test sollte dem Agenten und dem Team zeigen, wie ein echter Vermerk nach der Veröffentlichung aussieht. Wenn du ihn löschst, lernen beide, dass die Veröffentlichungshistorie beliebig verschwinden kann.

Paketinhalt und Akzeptanz durch die Registry sind getrennte Tests

Teams nennen npm pack oft einen Release-Test. Tatsächlich ist es ein Test des Paketinhalts. Danach nennen sie eine erfolgreiche npm publish einen Release-Test. Das ist ein Test der Registry-Akzeptanz. Keiner ersetzt den anderen. Wer einen davon als vollständig betrachtet, erzeugt vorhersehbare Lücken.

Beim Test des Paketinhalts geht es darum, ob der Tarball die gewünschten Dateien und Metadaten enthält. Er findet einen Fehler in .npmignore, ein zu weit gefasstes files-Array, ein fehlendes Build-Artefakt und einen Versionsunterschied zwischen Quelle und Manifest. Einen großen Teil dieser Arbeit kannst du ohne Netzwerkzugriff erledigen.

Der Registry-Akzeptanztest prüft, ob die Registry Zugangsdaten und Namespace erkennt, die Version akzeptiert, den Tarball speichert, Integritätsinformationen erfasst und ihn einem Consumer zur Verfügung stellt. Er findet einen falschen Registry-Host, fehlende Berechtigungen für die Organisation, einen Fehler in der Publish-Konfiguration und einen Autorisierungsweg, der sich von der lokalen Entwicklung unterscheidet.

Der Consumer-Test stellt eine dritte Frage: Kann ein sauberes Projekt den exakten Release installieren und ihn so aufrufen, wie Nutzer es tun werden? Hier zeigen sich fehlende Peer-Abhängigkeiten, fehlerhafte exports-Einträge und eine versehentliche Abhängigkeit von Workspace-Dateien.

Führe diese Tests in dieser Reihenfolge aus. Zuerst zu veröffentlichen, weil «wir können es ja jederzeit zurücknehmen», ist schlechte Praxis. Das Zurücknehmen einer Veröffentlichung ist kein Rollback-Schalter. Einige Nutzer, Spiegel, Caches und Build-Vermerke können das Paket behalten, während andere Consumer es nicht mehr auflösen können. Eine falsche Version lässt sich möglicherweise operativ beheben, erzeugt aber trotzdem Arbeit und Verwirrung, die eine lokale Tarball-Prüfung verhindert hätte.

Die Genehmigung sollte den Folgen des Aufrufs folgen

Eine Genehmigung auf Sitzungsebene ist für einen Lauf sinnvoll, der viele erwartete Lesezugriffe ausführt. Wenn jemand jede Metadatenabfrage bestätigen muss, gewöhnt er sich daran, ohne Lesen zu klicken. Das führt zu Genehmigungsmüdigkeit und macht es unwahrscheinlicher, dass die wichtige Anfrage Aufmerksamkeit erhält.

Veröffentlichungen und Löschvorgänge sollten diesen Ablauf jedoch unterbrechen. Jede dieser Aktionen verändert den externen Zustand auf eine Weise, die ein routinemäßiger Dependency-Download nicht verändert. Verlange eine eigene Bestätigung für eine neue Paketversion, eine weitere für eine Dist-Tag-Änderung und eine weitere für jede destruktive Aktion. Wenn der Agent zwei Pakete veröffentlichen will, zeige zwei Anfragen. Eine Sammelgenehmigung verbirgt genau die Version, die ein Prüfer ansehen muss.

Die Anfrage pro Aufruf sollte genügend Informationen enthalten, damit eine Aktion aus dem richtigen Grund abgelehnt werden kann:

• Registry-Host und Paket-Scope oder Eigentümer.
• Aktion: Veröffentlichen, Tag verschieben, als veraltet markieren, Veröffentlichung zurücknehmen oder löschen.
• Exakte Version und gewünschter Wechsel des Tags.
• Der Agentenprozess, der die Anfrage gestellt hat, damit ein unerwarteter Aufrufer abgelehnt werden kann.
• Eine kurze Begründung aus dem Release-Plan, nicht aus einer frei formulierten Tool-Ausgabe.

Ein Mensch sollte in diesem Moment keinen Authorization-Header analysieren oder undurchsichtige Hashes vergleichen müssen. Das sind Details für das Audit. Die aktuelle Entscheidung sollte die Folgen der Aktion in verständlicher Sprache zeigen, während das System die ursprüngliche Anfrage für eine spätere Prüfung bewahrt.

Sallyports Schlüsselkontrolle pro Aufruf passt gut zu dieser Grenze: Die Registry-Zugangsdaten können bei jeder Nutzung eine Genehmigung verlangen, während der Agent seine normale Arbeit unter einer separaten Sitzungsentscheidung erledigt. Das ersetzt nicht die Prüfung des Paketinhalts. Es verhindert, dass eine Release-Zugangsdaten nach einem früheren Klick dauerhaft als Hintergrundberechtigung verfügbar bleibt.

Tags als Änderung der Nutzerweiterleitung behandeln

Ein Dist-Tag kann eine technisch einwandfreie Version für deine Nutzer riskant machen. In npm-kompatiblen Registries folgt eine Installation ohne explizite Version normalerweise dem Tag latest. Wenn du diesen Tag verschiebst, ändert sich, was neue Installationen erhalten, obwohl der bereits veröffentlichte Tarball unverändert bleibt.

Halte Veröffentlichung und Tag-Verschiebung als getrennte Anfragen. Veröffentliche zuerst eine Kandidatenversion und rufe sie anschließend in einem sauberen Testprojekt über ihre exakte Version ab. Erst danach sollte jemand entscheiden, ob latest verschoben wird. So entsteht eine sinnvolle Pause: Die Daten sind unter einer unveränderlichen Version sichtbar, während die Weiterleitungsentscheidung noch nicht gefallen ist.

Die Befehle machen den Unterschied deutlich:

npm publish --tag candidate
npm view @acme/widget dist-tags --json
npm dist-tag add @acme/[email protected] latest

Der erste Befehl erstellt eine Version und weist ihr eine Kandidatenroute zu. Der letzte ändert die Route, der viele Nutzer folgen. Ein Release-Skript, das beides in einer Hilfsfunktion versteckt, nimmt den wichtigsten Punkt für menschliches Urteil weg.

Lass einen Agenten einen Tag-Fehler nicht durch Raten reparieren. Wenn latest auf die falsche Version zeigt, sollte der Agent die aktuelle Tag-Zuordnung, die gewünschte Version und die geplante Korrektur melden. Ein Prüfer sollte sie bestätigen. An dieser Stelle ist ein zusätzlicher Klick kaum Aufwand, verglichen mit den Kosten, ein fehlerhaftes Paket an jede neue Installation zu senden.

Audit-Vermerke auch nach dem Incident-Call brauchbar halten

Eine Befehlszeile allein beantwortet nicht, wer eine Registry-Änderung genehmigt hat, welcher Agentenlauf sie ausgelöst hat oder ob jemand das Log nachträglich verändert hat. Release-Vorgänge brauchen einen Vermerk, der Anfrage, Genehmigung, Ausführungsergebnis und zurückgegebene Registry-Metadaten miteinander verbindet.

Speichere Paketname, Version, Registry-Host, Aktionstyp, endgültigen Status und einen Verweis auf die vor der Aktion erstellte Artefaktprüfung. Speichere keine Tokens, Authorization-Header oder Rohkonfigurationsdateien, die Zugangsdaten enthalten könnten. Ein gutes Audit beantwortet Monate später eine praktische Frage: Haben wir diese Version veröffentlicht, einen Tag verschoben oder es nur versucht?

Manipulationsnachweise sind wichtig, weil Release-Logs oft erst nach einem Fehler zu Beweismitteln werden. Sallyport speichert Sitzungsereignisse und einzelne Aufrufe in getrennten Journalen, die aus einem verschlüsselten, hashverketteten Audit-Log erstellt werden. Mit sp audit verify lässt sich diese Kette offline ohne Tresorschlüssel prüfen. Das ist belastbarer als eine veränderbare Textdatei im Repository.

Logs machen eine gefährliche Aktion nicht sicher. Sie ermöglichen es, den Ablauf zu rekonstruieren, wenn eine Genehmigungsanfrage missverstanden wurde, ein falsches Registry-Ziel verwendet wurde oder ein Release-Prozess etwas Unerwartetes getan hat. Kombiniere das Log mit einer sofortigen Möglichkeit, eine laufende Agentensitzung zu widerrufen. Wenn sich ein Release seltsam verhält, ist das Stoppen des nächsten Aufrufs wertvoller als ein perfekter Postmortem-Bericht später.

Den Wegwerf-Test in den Release-Vertrag aufnehmen

Der Test mit dem Wegwerf-Paket sollte eine geplante Prüfung des Release-Wegs sein, keine improvisierte Maßnahme nach einem fehlgeschlagenen Produktions-Release. Lege fest, wann er läuft: wenn sich die Registry-Integration oder die Verarbeitung von Zugangsdaten ändert, wenn du eine neue Paketmanager-Konfiguration einführst oder bevor ein neuer Agenten-Workflow Veröffentlichungsrechte erhält.

Halte seine Berechtigungen nach Möglichkeit enger als die Produktionsberechtigungen. Gestalte den Test aber nicht so künstlich, dass er den echten Fehler verfehlt. Teste dieselbe Registry-Klasse, denselben Request-Broker, dasselbe Muster für die Speicherung von Zugangsdaten und dieselbe Prüfung der sauberen Installation. Wenn für Produktionsveröffentlichungen ein Mensch genehmigen muss, sollte das auch für den Test gelten. Sonst testest du ein anderes System.

Der erste sinnvolle Schritt besteht darin, Registry-Schreibzugangsdaten aus für den Agenten sichtbaren Umgebungsvariablen zu entfernen. Danach führst du ein Wegwerf-Paket durch genau den kontrollierten Weg, dem du vertrauen willst. Prüfe die Paketdateiliste vor der Genehmigung. Untersuche nach der Veröffentlichung die exakte Version. Das Löschen bleibt eine eigene genehmigungspflichtige Aktion, denn ein ordentliches Testkonto ist niemals eine versehentliche Lücke in deiner Release-Grenze wert.