Postmans stille KI-Plugins brechen die eine Regel, die Entwickler-Tools nie verletzen dürfen

Wie sehr vertrauen Sie der App, in die Sie Ihre Produktions-Tokens einfügen? Die meisten Entwickler stellen sich diese Frage nie, denn API-Clients liegen im selben gedanklichen Fach wie das Terminal: unspektakulär, lokal, unser. Genau deshalb hat der jüngste Postman-Aufruhr so stark getroffen.

Was passiert ist, soweit bekannt

Ein Bericht im Postman-Support-Tracker auf GitHub, eingereicht am 3. November, trägt den Titel „Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook“. Laut AI Weekly installierte das Öffnen von Postman Desktop 12.33.4 seine Plugins in Codex und Claude Code. Dabei seien ~/.codex/config.toml und ~/.claude/settings.json ohne ausdrückliches Opt-in verändert worden.

Der Bericht machte auch auf Hacker News die Runde. Mehrere Sekundärquellen behaupten, die App versuche außerdem, API-Daten mit den KI-Diensten von Postman zu teilen. Diese Behauptungen sind vorerst Vorwürfe aus einem Support-Tracker-Eintrag und aus Community-Beiträgen. Eine Stellungnahme von Postman liegt uns in unseren Unterlagen nicht vor; der Teil zur Datenweitergabe ist daher unbestätigt.

Die Konfigurationsdatei ist der Tatort

Selbst wenn man die Datenfrage beiseitelässt, ist die Plugin-Installation der am schwersten zu verteidigende Punkt – vorausgesetzt, der Bericht hält stand. Eine Analyse von explainx.ai weist darauf hin, dass die Anweisung für „any non-trivial API engineering task“ gilt. Die Einstellung steht in der nutzerweiten Konfiguration, sodass jedes Projekt sie erbt. Ein Tool, das man zum Debuggen eines einzelnen Endpunkts geöffnet hat, kann damit das Verhalten des KI-Assistenten in völlig anderen Arbeiten prägen.

Das wäre kein Schalter im eigenen Postman-Fenster, sondern ein Werkzeug, das in die Einstellungen anderer Werkzeuge eingreift. Das ist aus unserer Sicht der eigentliche Verstoß, und das Argument „wir wollten nur helfen“ deckt ihn nicht ab. Editor, Shell und Agent-Konfigurationen gehören dem Nutzer. Der Installer eines anderen Anbieters hat dort nichts zu schreiben, nur weil er vermutet, dass es gefällt.

Dieselbe Analyse merkt an, dass das Plugin auch einen gehosteten MCP-Endpunkt einbindet, den sie als Weg beschreibt, auf dem Daten den Rechner verlassen können, sobald die Authentifizierung gelingt. Wir bleiben im Ton maßvoll: Ein Weg ist kein Leck. Aber die Entwickler wurden nicht gefragt, ob dieser Weg gebaut werden soll.

Opt-in ist keine Reibung, sondern das Produkt

Produktteams hören „erst fragen“ und sehen einen Conversion-Trichter mit Loch. Bei Entwickler-Tools halten wir das für verkehrt herum. Der Wert von Postman liegt darin, dass Menschen echte Dinge hineingeben: Tokens, Kundendaten, interne Systeme. Ein Leitfaden auf dev.to warnt, dass standardmäßig aktivierte KI-Funktionen relevant sind, wenn man Produktions-Tokens, Kundendaten oder Gesundheitsdaten durch Postman schickt. Das ist eine Behauptung aus der Community, kein verifizierter Befund. Aber sie beschreibt das richtige Risikomodell.

Eine API-Collection ähnelt eher einem Zugangsdaten-Tresor als einem Dokument. Sie bildet Ihre Systeme ab und enthält oft die Schlüssel. Unsere Position ist einfach: Collections sollten wie Geheimnisse behandelt werden, und alles, was sie liest, synchronisiert oder zusammenfasst, sollte ein bewusstes Ja des Nutzers erfordern. Keine versteckte Einstellung und keine Zeile im Changelog.

Es gibt auch ein kommerzielles Argument. Unternehmen sind beim Thema KI-Zugriff ohnehin nervös. Eine TCS-Studie unter 1.333 Führungskräften ergab, dass Sicherheit, Risiko und Governance der wichtigste Faktor für Entwicklung und Einsatz von KI sind – vor Kosten, Geschwindigkeit und einfacher Einführung. Sicherheitsteams, die diesen Thread lesen, werden sich wohl nicht an die clevere Agent-Integration erinnern. Sie werden sich an den Bericht erinnern, ein Client habe ungefragt Konfigurationsdateien geändert. Danach werden Beschaffungsgespräche schwieriger.

Was jetzt zu tun ist

Wer Postman Desktop nutzt, sollte vor der nächsten Sitzung die beiden Konfigurationsdateien und die KI-Einstellungen prüfen. Ein Beitrag in einem Hacker-News-Thread besagt, ältere Versionen seien unbedenklich, doch das ist ein einzelner Kommentar; bitte selbst überprüfen. Tokens, die möglicherweise durch einen betroffenen Build gelaufen sind, sollten rotiert werden, wenn das Bedrohungsmodell es verlangt. Sensible Collections sollten Sie außerdem aus cloudsynchronisierten Workspaces heraushalten.

Für Anbieter ist die Lehre billig. KI-Funktionen standardmäßig deaktiviert ausliefern, genau anzeigen, was installiert oder gesendet wird, und die Konfiguration eines anderen Tools nie ohne Rückfrage anfassen. Unser Urteil: Sollten die Berichte zutreffen, mag Postman es als Komfort gemeint haben, doch es wirkt wie ein Verstoß gegen die Etikette, den Entwickler als Vertrauensbruch werten. Vertrauen ist das Einzige, was ein Tool, das Ihre Schlüssel hält, wirklich verkauft.