# Kann die Identität eines IDE-Erweiterungshosts beweisen, welcher Agent dahintersteckt? Ein Editor-Erweiterungshost kann eine gültige Codesignatur tragen und dir trotzdem keine sichere Aussage darüber ermöglichen, welche Erweiterung eine sensible Aktion angefordert hat. Das ist kein Fehler der Codesignierung. Es ist die vorhersehbare Folge davon, dass ein Mechanismus für die Identität des Betriebssystems eine Frage beantworten soll, die innerhalb eines einzelnen Prozesses entsteht. Das ist wichtig, wenn ein KI-Coding-Agent über eine IDE läuft. Der Host kann mehrere Erweiterungen laden, Befehle aus einem Arbeitsbereich annehmen und Aufgaben an ein Gateway weitergeben, das eine API oder ein SSH-Ziel erreichen kann. Wenn das Gateway den Host einmal genehmigt und diese Genehmigung als Beleg für die Absicht einer bestimmten Erweiterung behandelt, gewährt es mehr Autorität, als die Belege hergeben. Ich habe diesen Fehler schon in einer scheinbar sauberen Sicherheitsarchitektur gesehen: den signierten Editor verifizieren, den Signierer in einem Genehmigungsdialog anzeigen und die Ausführung erlauben. Das ist eine sinnvolle Kontrolle. Gefährlich wird sie, wenn der Dialog eine Genauigkeit suggeriert, die er nicht besitzt. Der Host kann vertrauenswürdig sein, während die Anfrage, die seine Grenze passiert, unklar bleibt. ## Eine Host-Signatur identifiziert den Container, nicht seine Insassen Codesignierung belegt Fakten über ein ausführbares Abbild. Apple beschreibt die Codesignierung unter macOS als Möglichkeit, die Herkunft und Integrität einer Software festzustellen. Das System kann prüfen, ob eine vertrauenswürdige Signaturstelle den Code signiert hat und ob der geladene Code noch mit dem signierten Material übereinstimmt. Genau diese Informationen braucht eine Sicherheitsentscheidung auf die Frage: «Welcher Anwendungsprozess fragt an?» Sie beweist nicht: «Welche Erweiterungsfunktion innerhalb dieses Prozesses hat gefragt?» Ein Prozess hat an dieser Grenze eine einzige ausführbare Identität. Wenn ein Editor einen Erweiterungshost startet und dieser zehn Plugins lädt, erstellt der Kernel nicht zehn separate Codesignatur-Identitäten für deren JavaScript, Bytecode, Rückruffunktionen oder Aufrufe der Erweiterungs-API. Das hat eine praktische Folge. Ein Gateway kann einen belastbaren Eintrag erstellen wie: ```text caller executable: /Applications/Editor.app/.../extension-host signing authority: Example Software Team ID ABC123 process id: 8421 parent process: Editor.app pid 8304 ``` Aus der Signatur allein kann es diesen Eintrag nicht ableiten: ```text extension: publisher.cloud-deploy command: deployCurrentProject prompt source: chat request 18 ``` Der erste Block enthält Belege des Betriebssystems. Der zweite beschreibt die Herkunft innerhalb der Anwendung. Beides kann nützlich sein, sollte in einem Protokoll und auf einem Genehmigungsbildschirm aber unterschiedlich behandelt werden. Oft werden beide Dinge als «Identität» bezeichnet, und bei der Implementierung geht die Unterscheidung verloren. Tu das nicht. Der Signierer zeigt dir, wer die Box hergestellt hat. Er zeigt dir nicht, welcher Passagier nach den Steuerungen gegriffen hat. ## Gemeinsame Erweiterungshosts bündeln mehrere Autoritäten Ein Erweiterungshost existiert, damit der Editor Erweiterungen laden und koordinieren kann. Das ist praktisch, macht den Host aber zu einem Bündel von Autoritäten. Ein Vervollständigungs-Plugin, ein Formatter, eine Quellcodeverwaltung, ein Chat-Assistent und eine Erweiterung für den Arbeitsbereich können alle im selben Hostprozess ausgeführt werden. Stell dir ein Gateway vor, das einen HTTPS-Aufruf erlaubt, nachdem es die Signatur des Editors geprüft hat. Erweiterung A bittet den Host, einen Deployment-Endpunkt aufzurufen. Erweiterung B hat Zugriff auf eine Erweiterungs-API, über die sie denselben Host dazu bringen kann, eine ausgehende Aktion auszuführen, vielleicht direkt, vielleicht über einen von A registrierten Befehl. Am Gateway kommen beide Anfragen mit derselben Prozess-ID und derselben Signaturstelle an. Das Gateway kann sie nicht anhand der Host-Signatur voneinander unterscheiden. Die Unklarheit wird noch größer, wenn Erweiterungen über gemeinsame Hostdienste kommunizieren. Ein Plugin kann einen Befehl registrieren. Ein anderes Plugin kann ihn aufrufen. Eine Chat-Erweiterung kann Anweisungen aus einer Repository-Datei, einem Issue-Text oder einem eingefügten Terminalergebnis erhalten und anschließend einen Befehl ausführen. Die Zuordnung hat nun mehrere Ebenen: den signierten Host, die Erweiterung, die den Aufruf erstellt hat, die Erweiterung, die Eingaben geliefert hat, sowie den Menschen oder nicht vertrauenswürdigen Inhalt, der sie beeinflusst hat. Nichts davon macht IDE-Erweiterungen grundsätzlich unsicher. Es bedeutet, dass eine Genehmigung auf Host-Ebene die gebündelte Autorität des Hosts genehmigt. Wenn das für eine Operation zu weit gefasst klingt, brauchst du eine zweite Kontrolle, die die Operation selbst sieht. ## Ein Erweiterungsname ist nur dann Herkunftsinformation, wenn der Host ihn bindet Eine Erweiterungskennung wie `publisher.name` liefert nützlichen Kontext, aber ein Gateway sollte eine vom Aufrufer gelieferte Zeichenfolge nicht mit einem Beleg verwechseln. Jeder Code, der eine Anfrage erstellen kann, kann `publisher.name` in einen Header, einen JSON-Body, ein Befehlsargument oder eine Umgebungsvariable schreiben. Das zeigt nur, was behauptet wurde. Ein Host kann diese Behauptung belastbarer machen, indem er die Kennung aus seiner eigenen Erweiterungsregistrierung bezieht, sie an den aktiven Ausführungskontext bindet und über einen geschützten lokalen Kanal sendet, den Erweiterungen nicht fälschen können. Selbst dann beantwortet das Ergebnis nur eine engere Frage: Welcher vom Host verwaltete Erweiterungskontext hat diese Anfrage gestartet? Es identifiziert möglicherweise weder die Eingabeaufforderung noch den Repository-Inhalt oder die Person, die diesen Kontext beeinflusst hat. Der nützliche Test ist einfach. Frage dich, woher jedes Feld stammt und wer es ändern könnte. | Feld | Was es belegen kann | Wer es fälschen oder ändern kann | |---|---|---| | Signaturstelle des Hosts | Die Identität der geladenen ausführbaren Hostdatei | Eine Erweiterung kann sie normalerweise nicht fälschen | | Prozess-ID und Startzeit | Eine bestimmte laufende Hostinstanz | Das Betriebssystem weist sie zu | | Erweiterungs-ID in einer Anfrage | Eine behauptete Erweiterungsidentität | Jeder Code, der die Anfrage erstellen kann, sofern der Host sie nicht bindet | | Arbeitsbereichspfad | Der vom Host behauptete Kontext | Der Host oder eine Erweiterung kann ihn falsch angeben | | Genehmigungsentscheidung | Ein Mensch hat die angezeigte Anfrage genehmigt | Die Genehmigungsoberfläche muss sie an die Aktion binden | Darum ist «Wir nehmen den Erweiterungsnamen ins Prüfprotokoll auf» keine vollständige Sicherheitsaussage. Behalte den Namen bei. Kennzeichne ihn als vom Host gemeldet, sofern die Architektur dem Gateway keinen Grund gibt, ihn als verifiziert zu betrachten. Diese Kennzeichnung verhindert, dass spätere Ermittler bequeme Metadaten als Beweis behandeln. ## Eine Sitzungsgenehmigung hat einen sinnvollen Bereich und eine klare Grenze Es lohnt sich, einen neu gestarteten, verifizierten Hostprozess zu genehmigen. Damit lassen sich ein anderer Prozess, eine geänderte Signaturstelle, eine neue Prozesslaufzeit und ein unerwarteter Startpfad erkennen. Außerdem kann die Person am Rechner sehen, wer gleich Zugriff erhalten soll. Für Routineaufgaben mit eng begrenzten Zugangsdaten kann diese Unterbrechung der richtige Kompromiss sein. Die Grenze liegt darin, dass eine Sitzungsgenehmigung dem gesamten genehmigten Prozess alles erlaubt, was die Sitzung tun kann. Wenn der Prozess viele Erweiterungen beherbergt, kann er eine Anfrage der erwarteten Erweiterung nicht von einer Anfrage einer anderen geladenen Erweiterung unterscheiden. Eine übersichtliche Genehmigungskarte kann den Signierer und die Prozessidentität des Hosts anzeigen, sollte aber keine Zuordnung auf Plugin-Ebene versprechen, die sie nicht leisten kann. Es gibt noch einen zweiten Fehler, den Teams oft übersehen. Sie genehmigen morgens einen Editorprozess und installieren oder aktivieren später in derselben langlebigen Sitzung eine Erweiterung. Wenn der Host neuen Code lädt oder neu lädt, ohne seine von außen geprüfte Identität zu ändern, bleibt die Genehmigung umfassender, als die Person sich bewusst macht. Die passende Reaktion hängt vom Verhalten des Hosts ab. Das Prinzip bleibt jedoch gleich: Änderungen innerhalb eines genehmigten Hosts sind für einen Broker außerhalb des Hosts nicht automatisch sichtbar. Verwende eine Sitzungsgenehmigung für die Frage, die sie beantworten kann: «Darf dieser signierte Hostprozess diese Zugriffskategorie nutzen, solange er existiert?» Dehne sie nicht auf die Frage aus: «Darf diese bestimmte Erweiterung diese bestimmte nicht rückgängig zu machende Aktion ausführen?» ## Eine Genehmigung pro Nutzung gleicht die Unklarheit im entscheidenden Moment aus Bei sensiblen Zugangsdaten solltest du um Genehmigung bitten, sobald die Aktion erstellt wird, nicht erst beim ersten Auftreten des Hosts. Der Dialog sollte genug von der geplanten Aktion zeigen, damit eine Person sinnvoll entscheiden kann: Ziel, Methode oder SSH-Ziel, Bezeichnung der Zugangsdaten und der Teil der Anfrage, der Folgen hat. Angenommen, ein Host sendet diese Anfrage an ein lokales Aktionsgateway: ```json { "channel": "http", "credential": "production-deploy", "method": "POST", "url": "https://deploy.example.internal/releases", "body": {"service": "billing", "version": "a1b2c3d"} } ``` Eine passende Genehmigungskarte muss die Entscheidung an die genaue Methode, das Ziel, die Zugangsdaten und den Body oder an einen stabilen Digest des Bodys binden. Sie sollte nicht nur sagen: «Der Editor möchte production-deploy verwenden.» Diese Formulierung macht aus einer Aktionsgenehmigung einen Blankoscheck für jeden Aufruf, den der Host vor Ablauf der Entscheidung ausführen kann. Genehmigungen pro Nutzung sind unbeliebt, weil sie den Arbeitsfluss unterbrechen. Für harmlose Aufrufe ist dieser Einwand berechtigt. Bei einer Änderung in der Produktion, weitreichenden Zugangsdaten oder einem SSH-Befehl, der einen Rechner verändern kann, überzeugt er nicht. Die genehmigende Person muss nicht mit Sicherheit wissen, welche Erweiterung verantwortlich ist. Sie muss die Konsequenz sehen, die den Rechner verlassen soll, und entscheiden, ob sie beabsichtigt ist. Ein Tresor-Gate schafft eine weitere Grenze, die eine Sitzungsgenehmigung nicht bieten kann. Solange der Tresor gesperrt ist, werden alle Aktionen abgelehnt, auch Aufrufe zuvor genehmigter Hosts. Sallyport setzt diese absolute Sperre vor der Sitzungsautorisierung durch. Bei ausgewählten Zugangsdaten kann außerdem jede Nutzung eine Genehmigung erfordern. So bleibt das Zusammenspiel der Kontrollen ehrlich: Die Host-Signatur identifiziert den Aufrufer, die Sitzungsentscheidung lässt diesen Prozess für eine begrenzte Lebensdauer zu, und die Genehmigung pro Nutzung deckt die sensible Aktion ab. ## Eng begrenzte Zugangsdaten reduzieren den Schaden einer korrekten Genehmigung Eine Genehmigung ersetzt keine Begrenzung von Zugangsdaten. Jemand kann den richtigen Host und die richtige Anfrage genehmigen und anschließend trotzdem feststellen, dass die Zugangsdaten weit mehr erlauben als die beabsichtigte Operation. Das ist ein Fehler beim Entwurf der Zugangsdaten, nicht bei der Genehmigung. Teile den Zugriff nach seinen möglichen Folgen auf. Ein Token, das ein Repository lesen kann, sollte nicht zugleich jedes Projekt verwalten. Zugangsdaten für Deployments sollten weder Benutzer anlegen noch fremde Geheimnisse abrufen können. Verwende für SSH ein separates Konto oder, sofern die Gegenseite es unterstützt, eine Konfiguration mit erzwungenem Befehl, statt einem Arbeitsablauf, der nur eine Wartungsaufgabe erledigen soll, eine allgemeine Shell zu geben. Die verbreitete Empfehlung, einem Agenten ein einziges weitreichendes Entwicklungs-Token zu geben, wirkt attraktiv, weil die Einrichtung fünf Minuten dauert. Sie ist falsch, sobald das Token mehrere Umgebungen berührt oder Schreibrechte besitzt. Ein weitreichendes Token macht jede Unklarheit innerhalb des Erweiterungshosts auch außerhalb des Hosts zu einer weitreichenden Unklarheit. Eng begrenzte Zugangsdaten erleichtern das Lesen der Genehmigungsabfrage, weil der mögliche Aktionsbereich bereits klare Grenzen hat. Bei HTTP-Aktionen solltest du das Ziel in den Zugangsdaten oder in der Gateway-Konfiguration beschränken, sofern die Architektur das erlaubt. Ein Bearer-Token, das in jede beliebige URL eingefügt werden kann, lässt sich von einem Host abgreifen, der dazu gebracht wurde, einen von Angreifern kontrollierten Endpunkt aufzurufen. Bei SSH-Aktionen solltest du Host, Konto und die vorgesehene Befehlsklasse festhalten, bevor du entscheidest, dass eine Sitzungsgenehmigung ausreicht. ## Ein typischer Fehler beginnt mit einer harmlosen Aktion aus der Befehlspalette Ein Entwickler installiert eine Assistenten-Erweiterung und eine Deployment-Erweiterung. Beide laufen in einem signierten Erweiterungshost. Der Entwickler genehmigt den Host, als der Assistent eine Staging-API prüfen möchte, weil die Genehmigungskarte die Signaturstelle des Editors korrekt anzeigt. Später öffnet der Entwickler ein Repository mit einer Aufgabendatei, die Anweisungen für den Assistenten enthält. Der Assistent liest die Datei und ruft einen Hostbefehl auf, den die Deployment-Erweiterung registriert hat. Der Befehl bittet dasselbe Gateway, Produktionszugangsdaten zu verwenden. Die Anfrage hat dieselbe signierte Prozessidentität wie die Staging-Anfrage. Ein Gateway, das sich allein auf die Sitzungsgenehmigung verlässt, sieht einen genehmigten Aufrufer und fährt fort. Für diese Abfolge braucht es weder eine gefälschte Signatur noch ein kompromittiertes Betriebssystem. Der Fehler entsteht, weil die Genehmigungsentscheidung den Host abdeckte und die Zugangsdaten eine Aktion erlaubten, die der Entwickler nicht freigeben wollte. Ein Prüfprotokoll mit dem Eintrag «genehmigter Editor hat einen HTTP-Aufruf ausgeführt» zeigt dem Team nicht, ob die Deployment-Erweiterung, der Assistent oder eine Aufgabendatei die Abfolge ausgelöst hat. Ändere die Konfiguration an drei Stellen. Verlange für die Produktionszugangsdaten bei jeder Nutzung eine ausdrückliche Genehmigung. Zeige darin das Ziel und die Release-Nutzdaten. Protokolliere die Hostidentität getrennt vom vom Host gemeldeten Erweiterungskontext und bewahre die Verbindung zwischen Genehmigungsereignis und Aufruf auf. Die Anfrage kann weiterhin legitim sein, darf aber nicht als gewöhnliche Hintergrundarbeit durchgehen. ## Prüfprotokolle brauchen eine Beweisspalte, keine schmeichelhafte Geschichte Protokolle werden irreführend, wenn sie verifizierte Fakten und selbst gemeldeten Kontext zu einem einzigen Satz zusammenfassen. «Plugin X hat Dienst Y bereitgestellt» klingt präzise, kann aber eine unverifizierte Plugin-Bezeichnung und eine unbekannte Kausalkette verbergen. Zeichne das Rohereignis mit seiner jeweiligen Quelle auf. Eine nützliche Ereignisstruktur trennt die Behauptungen: ```json { "time": "2026-07-24T10:16:43Z", "caller": { "signing_authority": "Example Software Team ID ABC123", "pid": 8421, "started_at": "2026-07-24T09:58:03Z" }, "host_reported_context": { "extension_id": "publisher.cloud-deploy", "workspace": "/work/payments" }, "action": { "channel": "http", "method": "POST", "destination": "https://deploy.example.internal/releases", "credential": "production-deploy" }, "authorization": { "session_approved": true, "per_use_approved": true } } ``` Es geht nicht darum, mehr Protokollfelder zu erzeugen. Die Grenze zwischen einem vom System verifizierten Fakt und einer Aussage des Hosts soll erhalten bleiben. Bei einem Vorfall entscheidet dieser Unterschied darüber, ob Ermittler eine Aktion zurückverfolgen oder lediglich eine Bezeichnung wiederholen können. Auch der Manipulationsschutz ist wichtig. Ein lokales Journal, das ein kompromittierter Prozess umschreiben kann, liefert nur schwache Belege über dessen eigenes Verhalten. Sallyport stellt Ansichten zu Sitzungen und Aktivitäten aus einem verschlüsselten, hashverketteten Prüfprotokoll bereit. Mit `sp audit verify` lässt sich die Kette offline ohne Tresorschlüssel prüfen. Das löst die Zuordnung von Erweiterungen nicht, verhindert aber, dass eine spätere Änderung die Geschichte unbemerkt verbessert. ## Isoliere die Operation, wenn die Zuordnung exakt sein muss Manche Aktionen brauchen eine eindeutigere Antwort, als ein gemeinsamer Host liefern kann. Wenn Zugangsdaten Geld bewegen, Produktionszugriffe ändern, Daten löschen oder uneingeschränkte Remote-Befehle ausführen können, leite die Operation über eine Komponente mit eigener ausführbarer Identität und einer engen Schnittstelle. Das Gateway kann dann diesen Helfer verifizieren, statt die Absicht aus einem überfüllten Erweiterungshost abzuleiten. Der Helfer sollte ein ausdrückliches Anfrageformat akzeptieren, zusätzliche Parameter ablehnen und seine eigene Autorität klein halten. Ein Release-Helfer kann beispielsweise einen Dienstnamen aus einer Allowlist und einen Versions-Digest akzeptieren, aber beliebige URLs und Shell-Fragmente ablehnen. Der übergeordnete Editor kann die Arbeit weiterhin starten, den Helfer aber nicht in einen allgemeinen Netzwerkclient verwandeln. Prozesstrennung ist kein Zauber. Wenn der Host beliebige Anfragen an den Helfer senden kann, wurde dieselbe Unklarheit lediglich in einen neuen Prozess verschoben. Die Schnittstelle muss Auswahlmöglichkeiten entfernen, die der Host nicht haben sollte. Ein separater signierter Helfer mit einer weit offenen Anfrage «Alles ausführen» ist nur Theater. Wenn Isolation zu teuer ist, weiche auf aktionsspezifische Genehmigungen und eng begrenzte Zugangsdaten aus. Diese Kombination gibt einem Menschen die Möglichkeit, die Konsequenz zu erkennen, selbst wenn die Quelle innerhalb des Editors unklar bleibt. Behaupte keine Sicherheit auf Plugin-Ebene, wenn die Architektur nicht zeigen kann, woher diese Sicherheit kommt. ## Behandle den Text der Genehmigung als Teil der Zugriffsschranke Eine Genehmigungsabfrage verändert Verhalten. Ihr Wortlaut braucht deshalb dieselbe Sorgfalt wie der Code, der sie durchsetzt. Wenn dort steht «Dem Editor Zugriff auf das Deployment erlauben», lernen Benutzer, eine Kategorie zu genehmigen. Wenn dort steht «Diesem signierten Erweiterungshost erlauben, dieses Release mit diesen Zugangsdaten per POST an dieses Ziel zu senden», können Benutzer die konkrete Aktion bewerten, die sie autorisieren. Der Signierer des Prozesses sollte deutlich sichtbar sein, denn so lässt sich die falsche Anwendung erkennen. Zeige auch den Erweiterungsnamen, wenn der Host ihn bereitstellt, weil er einer Person hilft, erwartete Arbeit wiederzuerkennen. Kennzeichne ihn als gemeldeten Kontext, wenn das Gateway ihn nicht verifizieren kann. Menschen können mit Unsicherheit besser umgehen, wenn die Oberfläche sie klar benennt, statt durch eine polierte Bezeichnung eine Garantie vorzutäuschen. Beginne damit, alle Zugangsdaten zu erfassen, die von einem IDE-Host aus erreichbar sind. Notiere für jede Zugangsdaten, welche Genehmigung auf Host-Ebene sie sicher übernehmen kann, welche Aktionsform eine neue Entscheidung erfordert und welche konkreten Belege das Prüfprotokoll bewahrt. Wenn die Antwort auf «Welche Erweiterung hat das getan?» nur eine Vermutung ist, vergib keine Berechtigung, als wäre sie eine Tatsache.