Missbrauch von GitHub MCP: Zugriff auf private Repositories über MCP

• In der GitHub-MCP-Integration wurde eine schwerwiegende Schwachstelle entdeckt, durch die Angreifer den Agenten eines Nutzers über ein bösartiges GitHub-Issue manipulieren und Daten aus privaten Repositories exfiltrieren können
• Die Schwachstelle gehört zu einem neuen Typ namens Toxic Agent Flow, bei dem ein Agent durch bösartige Prompts dazu gebracht wird, unerwünschte Daten in öffentlichen Repositories offenzulegen
• Die Schwachstelle entsteht nicht durch einen Fehler im Tool selbst, sondern durch architektonische Grenzen, wobei realistische Nutzungsgewohnheiten wie einfache Bestätigungsrichtlinien das Risiko erhöhen
• Für eine wirksame Abwehr ist die Einführung systematischer Agent-Schutzmaßnahmen wie granulare Zugriffskontrolle und kontinuierliches Sicherheitsmonitoring erforderlich
• Eine reine Modell-Alignment-Strategie reicht nicht aus; wichtig sind Sicherheitsmaßnahmen auf Systemebene für die gesamte MCP- und Agent-Umgebung

---

Überblick

Invariant hat in der weit verbreiteten GitHub-MCP-Integration (14.000 Stars) eine äußerst schwerwiegende Schwachstelle entdeckt. Diese ermöglicht es Angreifern, ein bösartiges GitHub-Issue zu erstellen, den Agenten eines Nutzers zu manipulieren und Daten aus privaten Repositories nach außen abfließen zu lassen.

Das Problem ist der erste Fall, der mit Invariants automatisiertem Scanner zur Erkennung von Toxic Agent Flows entdeckt wurde. In solchen Szenarien wird ein Agent zu unbeabsichtigten Handlungen verleitet, was zu Datenabfluss oder der Ausführung von Schadcode führen kann.

Da die Branche derzeit Coding Agents und IDEs breit einführt, ist jetzt ein wichtiger Zeitpunkt, das Bewusstsein für solche Angriffe zu schärfen.

Angriffsszenario

• Vorbereitung des Angriffs

  • Es wird angenommen, dass der Nutzer einen MCP-Client wie Claude Desktop mit dem GitHub-MCP-Server verbunden hat
  • <user>/public-repo: ein öffentliches Repository, in dem jeder Issues erstellen kann
  • <user>/private-repo: ein privates Repository mit internen Unternehmensdaten usw.
  • Der Angreifer erstellt in dem öffentlichen Repository ein bösartiges Issue (mit Prompt Injection)
  • Wenn der Nutzer eine gewöhnliche Anfrage wie „Zeig mir die Issue-Liste von public-repo“ stellt, ruft der Agent die Issues des öffentlichen Repositories ab und wird dabei der Injection ausgesetzt

• Ablauf des Angriffs

  • In dem Moment, in dem der Agent das bösartige Issue liest, holt er Daten aus dem privaten Repository in den Kontext und erstellt daraus einen PR im öffentlichen Repository, der für alle zugänglich ist
  • Dieser Prozess wird als Toxic Agent Flow definiert und kann mit Invariants Sicherheitsanalysator in realen Umgebungen automatisch erkannt werden

Demonstration des Angriffs

• Als Beispiel wurde der Angriff mit dem öffentlichen Repository (ukend0464/pacman) und privaten Repositories nachgestellt
• Der Angreifer erstellt ein bösartiges Issue im öffentlichen Repository, und die Prompt Injection wird ausgelöst, wenn der Agent die Issue-Liste dieses Repositories abruft
• Wenn der Nutzer Claude 4 Opus um Unterstützung bittet, führt Claude die Injection über die GitHub-MCP-Anbindung aus
  • Claude Desktop verlangt standardmäßig eine Bestätigung bei der Tool-Nutzung, aber viele Nutzer verwenden die Richtlinie „Immer erlauben“ und handeln dadurch unbedacht
• Der Agent extrahiert Daten aus privaten Repositories und legt sie in einem öffentlichen PR offen
• Im Experiment wurden sogar sensible Informationen wie private Projektnamen, Umzugspläne des Arbeitsplatzes und Gehälter offengelegt

Erkennung von Toxic Agent Flows

• Diese Schwachstelle entsteht auch dann, wenn bestehende MCP-Tools selbst nicht kompromittiert sind, und zwar durch nicht vertrauenswürdige Informationen aus einer externen Plattform (GitHub)
• In großen Agent-Systemen ist die Analyse und Eindämmung solcher Risiken manuell äußerst komplex. Daher hat Invariant eine automatisierte Erkennungsmethode entwickelt, die proaktive Bedrohungsanalysen ermöglicht

Betroffene Systeme und Gegenmaßnahmen

• Diese Schwachstelle ist nicht auf bestimmte Agenten oder Clients beschränkt, sondern betrifft alle Agenten, die MCP-Server verwenden
• Es handelt sich nicht um einen Fehler im Code des GitHub-MCP-Servers selbst, sondern um ein Designproblem, das sich nicht durch einen Patch am GitHub-Server beheben lässt
• Es werden zwei zentrale Gegenstrategien vorgeschlagen

1. Granulare Zugriffskontrolle

• In MCP-Integrationsumgebungen sollte für Agenten das Prinzip der minimalen Rechte gelten, sodass sie nur auf die unbedingt erforderlichen Repositories zugreifen können
• Eine herkömmliche tokenbasierte Autorisierung schränkt die Nutzbarkeit allein zu stark ein
• Mit einer dynamischen Runtime-Sicherheitsschicht wie Invariant Guardrails lässt sich die Zugriffskontrolle kontextabhängig im Workflow verstärken
  • Beispielrichtlinie: Pro Sitzung ist nur der Zugriff auf ein Repository erlaubt, um repository-übergreifenden Datenabfluss zu verhindern
  • Beispiel für eine Richtliniendefinition:

    raise Violation("You can access only one repo per session.") if:
        (call_before: ToolCall) -> (call_after: ToolCall)
        call_before.function.name in (...set of repo actions)
        call_after.function.name in (...set of repo actions)
        call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
        call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    

  • Richtlinien lassen sich etwa im Guardrails Playground testen

2. Kontinuierliches Sicherheitsmonitoring

• Zusätzlich zu Präventionsmaßnahmen werden leistungsfähige Monitoring-Tools benötigt, die Interaktionen zwischen Agenten und MCP-Systemen in Echtzeit scannen
• Beispiel: Einführung von Invariant MCP-scan zur Überwachung und Erkennung von Anomalien
• Mit dem aktuellen Proxy-Modus kann der MCP-Traffic in Echtzeit analysiert werden, indem er ohne Änderungen an der bestehenden Infrastruktur lediglich über einen Proxy umgeleitet wird
• Durch umfassende Überwachung lassen sich Schwachstellen erkennen, Angriffsversuche protokollieren und bösartige Abläufe frühzeitig blockieren

Warum Modell-Alignment allein nicht ausreicht

• Selbst moderne große Sprachmodelle (z. B. Claude 4 Opus) sind leicht anfällig für einfache Prompt-Injection-Angriffe
• Grundlegendes Alignment-Training allein kann die vielfältigen und kontextabhängigen Angriffe in realen Deployment-Umgebungen nicht vollständig verhindern
• Deshalb müssen kontextbezogene Erkennung und Sicherheitsmechanismen auf Systemebene zusätzlich zur Modellebene unbedingt aufgebaut werden

Fazit

• Invariant hat eine schwerwiegende Schwachstelle im GitHub-MCP-Server nachgewiesen, bei der Agenten durch bösartige GitHub-Issues übernommen und private Repositories offengelegt werden können
• Die Schwachstelle ist ein repräsentativer Fall, der durch Invariants automatisches Erkennungssystem entdeckt wurde; ähnliche Angriffe treten weiterhin in verschiedenen Umgebungen einschließlich MCP auf
• Für die sichere Einführung und den sicheren Betrieb von MCP-/Agent-Systemen sind spezialisierte Sicherheitsscanner wie MCP-scan und Guardrails entscheidend

Referenz und Kontakt

• Für zusätzliche Sicherheitsmaßnahmen oder Beratungsbedarf ist eine Kontaktaufnahme über [e-mail] möglich

Autor:
Marco Milanta
Luca Beurer-Kellner

[crawler]

Klingt zwar groß, ist aber einfach ein Problem, das durch Prompt Injection und zu weitreichende Berechtigungen für MCP entsteht.
Daher wirkt es so, als würde hier ein Tool beworben, mit dem sich die MCP-Berechtigungen von außen steuern lassen.
Es wäre gut, wenn die von außen eingegebenen Prompts andere Berechtigungen für MCP hätten als die Prompts, die nur intern eingegeben werden.

[GN⁺]

Hacker-News-Kommentare

• Ich habe das Gefühl, dass dieser Angriff nicht vollständig verstanden wird. Wenn man Claude ein Zugriffstoken gibt, kann Claude dazu gebracht werden, alles innerhalb der Berechtigungen dieses Tokens zu tun, ganz egal, wofür man es eigentlich verwenden lassen wollte. Wenn man einem LLM Zugangsdaten gibt, sollte man davon ausgehen, dass dem LLM alle Rechte dieser Zugangsdaten zur Verfügung stehen. Besonders vorsichtig muss man sein, wenn Tool-Aufrufe automatisch erlaubt werden. GitHub bietet allerdings Zugriffstoken mit fein granulierten Berechtigungen, daher lässt sich der Missbrauchsrahmen einschränken, wenn man nur Zugriff auf ein bestimmtes Repository gewährt. Dieser Angriff ist nur möglich, wenn das LLM Zugriff auf das gesamte Konto hat, und schon das Vergeben solch riskanter Zugangsdaten an Claude ist das eigentliche Problem.

  • Der wichtige Punkt dabei ist, dass das LLM hier — wie bei den meisten Prompt-Injection-Angriffen — gleichzeitig Zugriff auf mindestens zwei von drei Dingen bekommt: vom Angreifer kontrollierte Daten, sensible Informationen und Funktionen zur Datenexfiltration. Ein Grundprinzip beim Design von Agenten ist, immer höchstens zwei davon gleichzeitig zu erlauben; nur so lässt sich diese Art von Sicherheitsproblem verhindern. Sobald man zum Beispiel ein von einer nicht vertrauenswürdigen Person erstelltes Issue ansieht, ist der Kontext des LLM bereits mit vom Angreifer erzeugten Daten verunreinigt. Wenn danach auf sensible Daten zugegriffen wird, müssen Funktionen wie Internetzugang deaktiviert werden. Befolgt man dieses Modell, bleibt es auch ohne repository-spezifische Tokens sicher. Leider bietet MCP keine Werkzeuge, die das garantieren.

  • Das Problem sind zu weit gefasste Token-Berechtigungen, aber gleichzeitig wollen Entwickler nicht für jedes Repository ein eigenes Token offen halten. Daher geben sie Tokens breite Berechtigungen und vertrauen dem LLM einfach pauschal. Diese Vorsicht ist klug, aber in der Praxis halten sich viele Akteure im Ökosystem nicht daran. Genau deshalb ist dieser Bericht wichtig: Er verdeutlicht, dass ein LLM mit Rechten und nicht vertrauenswürdigen Daten für praktisch alles gekapert werden kann. Die Lösung ist, den Nutzungsumfang von Tokens dynamisch einzuschränken. Wir untersuchen diesen Ansatz in dieser Liste.

  • Das ist ein Problem, das bei Diensten wie Railway auftreten kann. Railway verlangt selbst für das Deployment eines einzelnen Projekts mitunter Zugriff auf alle GitHub-Repositories, während Netlify respektiert, dass man nur die gewünschten Repositories freigibt. GitHub sollte Apps, die solche Zugriffsbeschränkungen nicht respektieren, gar nicht erst zulassen.

  • Das ist ein Muster, das sich bei jeder neuen Technologie wiederholt. Man tut so, als könnten grundlegende Sicherheitsprinzipien im neuen Kontext ignoriert werden. Tatsächlich dürfen grundlegende Sicherheitsprinzipien niemals missachtet werden, egal welche „glänzende“ neue Technologie man benutzt. Dass sich im Kryptobereich frühere Betrugs- und Finanzkriminalitätsmuster einfach wiederholt haben, lag ebenfalls daran, dass man alte Lehren ignoriert hat, nur weil die Technik anders war.

  • Wenn ein Chatbot mit Nutzern interagiert, muss man davon ausgehen, dass er alles tut, was innerhalb seines erlaubten Rahmens möglich ist. Ein Chatbot ist nur eine Komfortschicht über einer API und ganz sicher kein eigenständiger Sicherheitsmechanismus.

• Wer sich für MCP und Agentensicherheit interessiert: Dazu gibt es bereits verschiedene Materialien aus unserer bisherigen Arbeit. Siehe den Claude-Ausführungs-Trace für das gesamte Angriffsszenario (Link), den Sicherheitsscanner für MCP-Verbindungen (Link), Tool-Poisoning-Angriffe bei MCP (Blog), einen WhatsApp-MCP-Exploit-Fall (Blog), die Sicherheits-Layer Guardrails für Agenten (Blog) und AgentDojo zur gemeinsamen Bewertung von Sicherheit und Utility bei AI-Agenten (Blog).

• Ich bin nicht sicher, ob man das wirklich einen „Exploit“ nennen sollte. Wenn man einem Agenten ein Token gibt, das auf private Repositories zugreifen kann, dann kann er eben darauf zugreifen. MCP ist nur ein API-Server. Was man nicht über eine API bereitstellen will, dafür sollte man auch keine Berechtigungen vergeben.

  • Wie viele andere habe ich auch erst die Kommentare gelesen, bevor ich den Artikel angeschaut habe. Im eigentlichen Artikel geht es darum, dass auf GitHub ein bösartiges Issue angelegt wird, das einen Prompt enthält, der das LLM zur Datenexfiltration verleiten soll. Wenn der Repository-Eigentümer den Agenten auslöst, handelt der Agent nach diesem bösartigen Prompt.

  • Das ist ein echter Exploit, der menschliche Fehler — oder Selbstüberschätzung — ausnutzt. Das Problem ist, dass Leute wegen des Hypes arglos private, sensible GitHub-Tokens mit Vollzugriff an ein LLM weitergeben.

  • Weil das Thema wichtig ist, möchte ich leicht dagegenhalten: Alle müssen die Risiken der Tool-Ausführung durch AI genau verstehen. Agenten führen derzeit Tools abhängig von ihrem aktuellen Aufmerksamkeitskontext aus, und dieser Kontext lässt sich leicht durch Tool-Ergebnisse oder Prompts beeinflussen. In den Kommentaren wird das aber oft nur auf „passiert halt, wenn man ein Token gibt“ reduziert. Schade ist auch, dass selbst nach einer korrekten Erklärung des Problems weiter mit Aussagen wie „der Nutzer hat es ja erlaubt“ vom Kern abgelenkt wird. Das ist ein klassisch falsches Argument beim Problem des confused deputy. Außerdem wird gern auf die Verantwortung des Nutzers verwiesen, obwohl das eigentliche Problem auch darin liegt, dass MCP keine nachgelagerten Zugriffskontrollen oder Protokollierung bietet. Ich würde mich nur sicher fühlen, wenn Logging zwingend vorhanden wäre. Ebenso finde ich es schlecht, Sicherheitsforschung als bloßen „gesunden Menschenverstand“ abzutun; über Sicherheit zu sprechen ist nie verkehrt. Eine Schwachstelle ist nicht deshalb wertlos, weil sie schwächer ausfällt. Man kann es durchaus mit SQL Injection vergleichen. Und es ist gefährlich, nicht zu verstehen, dass hier ein System indirekt vergiftet wird — also bösartiger Code über ein öffentliches Issue eingeschleust wird. Schließlich ist es bedauerlich, wenn Menschen defensiv reagieren, statt offen für neue Perspektiven zu sein.

• Aus Sicherheitsper­spektive muss man annehmen: Sobald ein LLM Text aus einer nicht vertrauenswürdigen Quelle sieht, kann diese Quelle steuern, wie das LLM seine Ausgabe erzeugt. Wenn das Ergebnis dann zu Tool-Aufrufen führt, kann die nicht vertrauenswürdige Quelle damit faktisch auch diese Tools verwenden. Als ich dazu weiter recherchiert habe, hatte ich den Eindruck, dass die Guardrails-Dokumentation von invariant labs auch einen Marketingaspekt hat. Es ist beunruhigend, dass die Architektur sicherheitstechnisch so kompliziert ist, dass überhaupt solche Guardrail-Produkte nötig sind. Wäre von Anfang an sicherheitszentriert designt worden, bräuchte man solche Produkte womöglich gar nicht.

  • Das ist ein leichtes Problem, wenn man Eingaben sauber trennt. Man markiert sie im Prompt einfach mit Tags wie <github_pr_comment> und legt fest, dass sie ausschließlich schreibgeschützt verwendet und niemals als Anweisungen interpretiert werden dürfen. Dieser Angriff ist in Wahrheit strukturell etwas komplexer. Er erinnert an frühere Prompt-Injection-Probleme bei Chatbots. Jetzt trifft es eben auch MCP.

  • Ich frage mich, ob man Teile des Texts als unbereinigte, verunreinigte Daten markieren und das LLM so trainieren könnte, die dort enthaltenen Anweisungen nicht als Befehle zu interpretieren.

  • Tatsächlich denken AI-Unternehmen Sicherheit beim Design mit. Dieser „Exploit“ ist aber nur in einem Szenario möglich, in dem Sicherheitsmechanismen deaktiviert wurden — mit deutlichen Warnhinweisen. Claude Desktop verlangt standardmäßig zum Beispiel für jeden Tool-Aufruf eine explizite Bestätigung. Viele Nutzer stellen jedoch auf „immer erlauben“ und überwachen einzelne Aktionen dann nicht mehr.

  • Dieses Muster von Software-Schwachstellen taucht traditionell immer wieder auf, und es ist zugleich irgendwie komisch und absurd, dass es auch bei neuer Technologie ständig wiederkehrt. „Nutzereingaben annehmen und sie in einer schlecht abgesicherten Umgebung als Befehle interpretieren und ausführen“ — dieses Muster kehrt immer wieder. Dieselbe Geschichte haben wir schon bei SQL Injection, XSS, PHP-Includes und vielem mehr gesehen, und jetzt wiederholt sie sich bei LLMs.

• Ich glaube nicht, dass MCP an sich besonders innovativ ist oder speziell anfällig fürs Hacking wäre, auch wenn ich zu MCP eigene Ansichten habe. Das wirkt eher wie ein marketingtauglich verpacktes Prompt-Injection-Thema. Wenn ich Agentensysteme entwerfe, folge ich immer der Philosophie: „Auf alles, worauf der Agent zugreifen kann, kann auch jeder zugreifen, der Zugriff auf den Agenten hat.“ Ich verlasse mich nicht darauf, dass das LLM Zugriffskontrolle durchsetzt, und mache klar, dass die Sicherheitsverantwortung für die Arbeit des Agenten immer bei der anfragenden Identität selbst liegt. Von Anfang bis Ende ist der eigentliche Punkt hier, auf welche Ressourcen ein Agent tatsächlich Zugriff bekommen soll. Wenn man Zugriff auf E-Mail-Daten erlaubt und eine Prompt-Injection-Mail das LLM dazu bringt, Sicherheitstokens zu stehlen und weiterzuleiten, dann ist das das wirklich ernste Risiko.

  • Das ganze MCP-Label erinnert ein bisschen an den Trend vor zehn Jahren, alles mit „läuft auf der Blockchain“ zu schmücken. „Da das LLM die genehmigende und handelnde Instanz ist, muss das Least-Privilege-Prinzip strikt angewendet werden“ — für alle mit Erfahrung ist das selbstverständlich, aber vielleicht muss eine neue Generation diese Grundlagen eben wieder neu lernen.

• Den tatsächlichen Angriff und die Reaktion des Agenten kann man hier sehen. Dass der Agent den Angriff vollständig erfolgreich ausgeführt hat, hat fast schon einen gewissen Komikfaktor.

• Ich habe übrigens vor einer Woche Googles Coding-Agent Jules ausprobiert, und die GitHub-OAuth-Berechtigungsanfrage verlangte vollständigen Zugriff auf alle Repositories und Berechtigungen im Konto. Das ist zum Teil dem Komfort für Entwickler geschuldet, zum Teil aber auch dem GitHub-OAuth-Flow selbst. Eigentlich müsste es viel einfacher sein, auf Repository-Ebene eingeschränkte Rechte zu vergeben und später zusätzliche Rechte nachzufordern. In der Praxis bleibt oft nur, ein separates GitHub-Konto anzulegen, dem man nur bestimmte Repositories gibt (Beispielkonto). Das ist ausgesprochen umständlich. Selbst GitHubs offizielle Dokumentation empfiehlt ja, solche Maschinenbenutzer separat anzulegen, aber die Festlegung des Standard-Repository-Scope müsste viel einfacher sein. Falls jemand einen besseren Weg kennt, würde ich ihn wirklich gern erfahren.

  • Auf der GitHub-Einstellungsseite kann man die Jules-Berechtigungen auf bestimmte Repositories beschränken.

• Ich finde die Behauptung des Artikels stark überzogen. Die Erklärung, dass schon ein simples Issue zur Datenexfiltration geführt habe, blendet aus, dass der Nutzer in Wirklichkeit selbst mehrere sicherheitstechnisch riskante Schritte durchführen musste. Man musste also einen MCP-Server einrichten, Zugangsdaten mit Zugriff auf öffentliche und private Repositories vergeben, dem LLM den Zugriff auf diesen Server sowie das Lesen von Repository-Issues erlauben und dann auch noch das bösartige Issue lesen und die Ausgabe nach außen veröffentlichen lassen. Das Ergebnis ist schlecht, aber es ist nicht wirklich das, was man üblicherweise als „bösartige Sicherheitslücke, die von Dritten ausgenutzt wird“ bezeichnen würde. Es ist vielmehr die Folge davon, dass der Nutzer selbst nicht vertrauenswürdige Daten gelesen und die Ergebnisse an einen nicht vertrauenswürdigen Ort ausgegeben hat. Trotzdem trägt GitHub MCP einen Teil der Verantwortung. Dass keine Kreuzverarbeitung zwischen öffentlichen und privaten Repositories verhindert wird, ist problematisch.

  • Man darf nicht übersehen, dass schon ein einfacher Befehl wie „Bitte diese Issues zusammenfassen“ ausreichen kann, damit Anweisungen ausgeführt werden, die direkt im bösartigen Issue stehen.

  • Auch die Marketingperspektive rund um MCP ist wichtig. Das Protokoll selbst sollte in Vertrauensdomänen getrennt werden, sodass nur vertrauenswürdige Umgebungen oder Nutzer Zugriff haben. Problematisch ist, dass es für MCP-Server keine standardisierte Möglichkeit für Scoping oder Authentifizierung gibt. Ich sehe das grundlegende Problem weniger bei GitHub MCP selbst als in der Art, wie unsere Branche insgesamt solche Dinge benutzt und implementiert. Wenn ich benutzerdefinierte MCP-Server einsetze, übermittle ich zusätzlich zu AI auch andere Informationen wie IDs oder JWTs, um Sicherheitsbarrieren einzuziehen.

  • Wegen des aktuellen AI-Hypes ist die Realität leider, dass viele Leute solche riskanten Konfigurationen und Abläufe gedankenlos übernehmen. Man kann leicht sagen: „So etwas sollte man nicht verwenden.“ Aber genau deshalb braucht man Guardrails. Menschen treffen nun einmal oft riskante Entscheidungen.

  • Auf die Forderung, öffentliche und private Repositories nicht zu mischen: In Wirklichkeit sind das aus Sicht des MCP-Servers völlig getrennte Tool-Aufrufe. Der MCP-Server hat keine Möglichkeit, diese Interaktion zu erkennen.

• Mir ist aufgefallen, dass die Diskussion inzwischen in diesem HN-Thread weitergeführt wird.

  • Wie dort schon erwähnt wurde, ist das Sicherheitsrisiko klar: Wenn man einem System Zugriff auf private Daten gibt und gleichzeitig externen Nutzern erlaubt, beliebigen Eingabetext einzuspeisen, gewährt man diesen externen Nutzern damit indirekt auch Zugang zu privaten Daten. Mit normalen Sicherheitspraktiken lässt sich das leicht verhindern.

  • Die aktuellen Kommentare sind inzwischen hier gesammelt worden.

• MCP ist nur ein Protokoll, und es gibt viele ähnliche Fälle wie A2A oder noch primitivere Ansätze. Man könnte einem LLM auch einfach die GitHub-API-Dokumentation lesen lassen und es anweisen, die API mit einem Token zu verwenden. Noch haben nicht alle LLMs dieses Funktionsniveau, aber bald wird das so sein. Den Mechanismus zur Tool-Registrierung vollständig abzusichern, ist praktisch unmöglich. Die letztendliche Verantwortung für Datenabfluss liegt damit beim LLM. Entwickler wollen Produktivitätsgewinne durch LLMs; also muss entweder Sicherheit garantiert werden, oder wir landen irgendwann bei zusätzlichen Sicherheitsfirewalls auf jedem Notebook. Der wirklich lästige Teil ist, dass die Zukunft vielleicht sogar in einen Wettlauf „LLM, das sich schlecht verhält“ gegen „LLM, das das schlechte LLM in der Sicherheitsfirewall einfängt“ mündet.