KI-Agenten-Erweiterungen brauchen das Äquivalent signierter Treiber
Enterprise-KI-Teams fragen nicht mehr nur, ob ein Agent sicher ist, sondern zunehmend: Was hat der Agent installiert, womit verbunden oder wovon gelernt, bevor er handelte?
Dieser Wandel ist wichtig, weil der nützliche Agent selten eine abgeschlossene Anwendung ist. Er ist ein System, das nach außen reicht. Er ruft einen MCP-Server auf, lädt eine Fähigkeit, ruft ein Dokument ab, nutzt einen Connector, folgt Anweisungen auf einer Webseite und agiert in Systemen mit echten Unternehmensdaten. Der Agent ist nicht nur Software, sondern eine Lieferkette in Bewegung.
Diese Woche trat das Startup AIR mit 50 Millionen Dollar Seed-Finanzierung öffentlich auf, das sich auf diese Lieferkette konzentriert. Die Grundannahme ist einfach: Agentenfähigkeiten, Plugins, MCP-Server, Subagenten, Webseiten und interne Daten können alle Eingaben für den Kontext eines Agenten sein, und jede Eingabe kann das Verhalten des Agenten verändern. Das ist kein Nischenproblem, sondern das Betriebsmodell, das Unternehmen schnell übernehmen.
Die beste Analogie ist nicht ein weiterer KI-Chatbot, sondern der signierte Treiber.
Warum eine Agenten-Erweiterung eher einem Treiber als einer App ähnelt
Eine traditionelle Anwendung wird meist als eigenständige Software geprüft. Eine Agenten-Erweiterung verhält sich anders. Sie kann Werkzeuge bereitstellen, Anweisungen einfügen, Zugangsdaten anfordern, Abrufe steuern und nachgelagerte Aktionen beeinflussen. Ein scheinbar harmloser Connector kann zum Zugang zu sensiblen Daten oder zum Vehikel für eine Prompt-Injection werden.
AIR-CEO Yair Saban verglich das bei der Vorstellung klar: Moderne Betriebssysteme erwarten signierte Treiber, weil diese Code in einen sensiblen Teil der Maschine laden. Agentenfähigkeiten und Plugins können einen ähnlich sensiblen Teil eines Agenten verändern: seinen Arbeitskontext und seine erlaubten Aktionen. Dennoch installieren Unternehmen sie oft mit viel weniger Nachweisen zu Herkunft, Umfang oder Änderungssteuerung.
Diese Lücke ist größer, als es ein Schwachstellenscan lösen kann. Ein Paket kann frei von bekannter Malware sein und dennoch für einen bestimmten Agenten unsicher. Eine Fähigkeit kann legitim sein, aber mehr Werkzeuge anfordern, als für die Aufgabe nötig sind. Ein MCP-Server kann heute vertrauenswürdig sein und morgen andere Anweisungen ziehen. Ein Connector kann einen legitimen Geschäftszweck haben, aber ungeeignet sein für einen Agenten, der Verträge, Kundendaten oder Finanzabläufe bearbeitet.
Die entscheidende Frage lautet daher nicht einfach: „Ist diese Erweiterung bösartig?“ Sondern: „Sollte dieser Agent diese Komponente mit dieser Identität, diesen Daten und dieser Autorität zu diesem Zeitpunkt nutzen dürfen?“
Das verborgene Problem: Beschaffung findet innerhalb von Workflows statt
Die meisten Unternehmenssicherheitsprogramme haben bereits Prozesse zur Genehmigung von SaaS-Anbietern. Sie verfügen vielleicht über Softwarezusammensetzungsanalysen für Entwicklerabhängigkeiten. Aber Agenten-Erweiterungen werden oft viel weniger sichtbar beschafft.
Ein Mitarbeiter erstellt einen Workflow. Der Workflow benötigt eine neue Fähigkeit. Der Agentenbauer wählt einen MCP-Server oder eine Fähigkeit aus einem Katalog, einem Git-Repository, einem Marktplatz oder einer Empfehlung eines Kollegen aus. Eine Berechtigungsabfrage erscheint. Die Arbeit geht weiter.
Das ist Beschaffung, Integration und produktive Bereitstellung in wenigen Klicks.
Das erzeugt auch Schatten-KI in neuer Form. Das Problem ist nicht mehr nur, dass Mitarbeiter sensible Daten in ein nicht genehmigtes Modell eingeben. Es sind nicht genehmigte Agenten-Komponenten, die Zugriff auf Unternehmenssysteme erhalten, oft durch gutmeinende Teams, die schneller vorankommen wollen. Das Sicherheitsteam kann nicht steuern, was es nicht entdeckt, und kann keine guten Entscheidungen auf Basis einer Tabelle treffen, die am Tag nach ihrer Erstellung veraltet ist.
Bauen Sie einen Vertrauensprozess für Agenten-Erweiterungen auf, keine einmalige Prüfung
Die Antwort ist nicht, jeden Connector zu verbieten. Das würde die Nutzung unsichtbar machen. Die Antwort ist, den sicheren Weg schneller zu machen als den unsichtbaren.
Beginnen Sie mit vier praktischen Kontrollen.
1. Erstellen Sie ein Inventar der KI-Komponenten
Verfolgen Sie Agenten, Fähigkeiten, MCP-Server, Plugins, Connectoren, Modelle, Datenquellen, Eigentümer und die Systeme, die jede Komponente erreichen kann. Beziehen Sie sowohl genehmigte als auch entdeckte Komponenten ein. Ein Inventar, das nur genehmigte Tools auflistet, ist ein Richtlinienregister, kein Risiko-Register.
Aonas [AI-BOM-Framework](/blog/ai-bom-shadow-ai-enterprise-security-inventory) ist ein nützlicher Ausgangspunkt: Behandeln Sie die Abhängigkeiten und Integrationen eines Agenten als Governance-Objekte erster Klasse, nicht als Implementierungsdetails.
2. Fordern Sie Herkunft und Zweck vor der Verbindung
Erfassen Sie für jede externe Komponente, wer sie pflegt, woher sie stammt, was sie tut, auf welche Daten sie zugreifen kann, welche Werkzeuge sie aufrufen kann und welchen Geschäftsworkflow sie unterstützt. Das sollte verhältnismäßig sein. Eine schreibgeschützte Wissenssuche ist nicht dasselbe wie ein Connector, der E-Mails senden, CRM-Datensätze ändern oder Zahlungsabläufe auslösen kann.
Der Schlüssel ist Nachweis. „Es ist beliebt“ und „das Team brauchte es“ sind keine Risikobewertungen.
3. Binden Sie die Autorität an die Aufgabe und lassen Sie sie dann verfallen
Ein Agent sollte nur die minimale Autorität für eine bestimmte Aufgabe erhalten, nicht einen dauerhaften Satz weitreichender Berechtigungen. Verwenden Sie möglichst unterschiedliche Identitäten. Begrenzen Sie Werkzeuge eng. Setzen Sie Zeitlimits. Fordern Sie für Aktionen mit hohem Einfluss menschliche Zustimmung.
Dieser Ansatz baut auf einem Prinzip auf, das wir in [KI-Agenten-Berechtigungen](/blog/ai-agent-expiring-permissions-enterprise-governance) behandelt haben: Widerruf muss vor einem Vorfall eingeplant sein, nicht erst danach improvisiert werden. Er verhindert auch, dass ein kompromittiertes oder verändertes Add-on mehr Rechte erhält, als seine Aufgabe rechtfertigt.
4. Änderungen und Laufzeitverhalten kontinuierlich überprüfen
Einmaliges Signieren oder Überprüfen einer Komponente reicht nicht aus. Agenten-Add-ons ändern sich. Ihre Abhängigkeiten ändern sich. Ihre Anweisungen und externen Endpunkte können sich ändern. Überwachen Sie Konfigurationsabweichungen, neue Berechtigungsanfragen, veränderte Tool-Aufrufe, unerwarteten Datenzugriff und Aktionen außerhalb des genehmigten Zwecks des Agenten.
Hier wird Governance operativ. Warnungen benötigen einen Verantwortlichen und einen Entscheidungsweg: erlauben, einschränken, isolieren oder untersuchen. Beobachtbarkeit ohne Eingriffsmöglichkeit ist eher ein besserer Vorfallbericht als eine Kontrolle.
Was CISOs in diesem Quartal fragen sollten
Eine nützliche Executive-Review ist kurz und konkret:
- Welche KI-Agenten und Add-ons sind derzeit mit unseren Systemen verbunden?
- Welche dieser Komponenten wurden entdeckt und nicht formell genehmigt?
- Können wir die Daten, Tools, Identitäten und Verantwortlichen für jede Komponente identifizieren?
- Was passiert, wenn sich eine Komponente nach der Genehmigung ändert?
- Welche Aktionen erfordern eine manuelle Genehmigung, bevor sie ausgeführt werden?
Wenn die Antworten manuelle Recherche über mehrere Teams erfordern, hat das Unternehmen bereits den Punkt erreicht, an dem die Agenten-Nutzung die Governance überholt.
Der AIR-Start ist ein zeitgemäßes Signal, nicht weil ein neuer Anbieter den Markt verändert, sondern weil er eine echte architektonische Veränderung benennt. Die Angriffsfläche ist jetzt die Kette aus Kontext, Tools und Komponenten, auf die ein Agent angewiesen ist. Sicherheitskontrollen, die für statische Anwendungen entwickelt wurden, übersehen diese Dynamik.
Unternehmen müssen ihre KI-Programme nicht verlangsamen. Sie müssen die Add-ons eines Agenten als vertrauenswürdige Rechenkomponenten behandeln: entdecken, verifizieren, einschränken und auch nach der Bereitstellung weiter überprüfen.
Wenn Sie versuchen, Shadow-KI und die Agentenverbindungen in Ihrer Umgebung zu erfassen, [sprechen Sie mit Aona](/contact-us?utm_source=blog&utm_medium=organic&utm_campaign=agent-add-on-governance). Wir helfen Sicherheitsteams, KI-Entdeckung in Richtlinien, Beweise und Maßnahmen umzusetzen.
