KI-Agenten-Frameworks: Sicherheit, Lock-in, Entscheidungen

Was sich in der Landschaft der KI-Agenten-Frameworks verändert hat

Die Kategorie der KI-Agenten-Frameworks reifte in weniger als zwei Jahren vom Experiment zum Deployment-Ziel. Teams, die diese Systeme als Prototypen behandelten, betreiben sie nun gegen Produktionsverkehr.

Der Wandel ist architektonisch. Orchestrierungsschichten, Tool-Calling, Retrieval und Multi-Agenten-Übergaben wurden zu Standardfunktionen in den wichtigsten Stacks. Dieser Standard hat Konsequenzen.

Anbieter liefern Auto-Invocation standardmäßig aktiviert aus. Ein Agent liest ein Dokument, entscheidet sich, ein Tool aufzurufen, und führt es aus, wobei die Ausführungsgrenzen dem Integrator überlassen bleiben. Der Komfort ist real. Das Risiko ist es ebenso.

Der Mechanismus unter der Abstraktion

Jedes Agenten-Framework lässt sich auf eine Schleife reduzieren: wahrnehmen, planen, handeln, beobachten. Das Modell empfängt Kontext, gibt eine Aktion aus, und die Laufzeitumgebung führt diese Aktion gegen reale Systeme aus.

Das entscheidende Detail liegt im Beobachtungsschritt. Die Ausgabe einer Komponente wird zur Eingabe der nächsten. Wenn diese Kette über mehrere Agenten läuft, summieren sich Fehler, statt sich aufzuheben.

Retrieval speist die Schleife mit externem Text. Dieser Text kommt in den meisten Standardkonfigurationen mit derselben Vertrauensstufe an wie eine Nutzeranweisung. Die Laufzeitumgebung behandelt einen abgerufenen Absatz als zu befolgende Anweisung.

Dies ist die Grundbedingung, auf die spätere Abschnitte zurückkommen: Das Framework hebt die Grenze zwischen Daten und Anweisung auf.

Die Sicherheitslage hinkt der Deployment-Kurve hinterher

Die Sicherheitslage von KI-Systemen liegt zwei bis drei Jahre hinter der Reife der umgebenden Infrastruktursicherheit zurück. Veröffentlichte Advisories gegen Orchestrierungsbibliotheken sind Signale, keine Anomalien.

Das Feld geht in Produktion, bevor Härtungspraktiken entwickelt werden. Webanwendungen wiederholten dieses Muster in den 2000ern. APIs wiederholten es in den 2010ern.

Das Muster wiederholt sich, weil Anreize das Ausliefern von Funktionen über das Härten von Schnittstellen belohnen. Sicherheitsarbeit wird nach dem ersten Vorfall sichtbar.

Jede in einer internen Prüfung genannte Schwachstelle sollte ihre offizielle CVE-Kennung tragen. Vage Risikobehauptungen helfen niemandem. Dokumentierte Patches und versionsgebundene Advisories schon.

Für einen CTO ist die Implikation direkt: Behandeln Sie jedes KI-Agenten-Framework als Software vor der Härtung. Budgetieren Sie das Audit, das der Anbieter ausgelassen hat.

Die Protokollstandardisierung ist der eigentliche Burggraben

Standardisierte Kommunikationsprotokolle, darunter A2A und MCP, entscheiden über die Wettbewerbsposition mehr als die reine Modellleistung. Wer die Schicht zwischen den Agenten kontrolliert, kontrolliert die Architektur.

Die Governance der Linux Foundation über A2A ist das richtige Signal. Protokolle, die sich durchsetzen, entziehen sich dem Orbit eines einzelnen Anbieters.

Die Modellleistung konvergiert über die Anbieter hinweg zur Parität. Die Differenzierung wandert zur Koordinationsschicht, und diese Schicht ist das Protokoll.

Ein v1.0-Stabilitätssignal auf einer gemeinsam genutzten Spezifikation verändert die Beschaffungsrechnung. Die Spezifikation wird zu einem zu übernehmenden Standard statt zu einem zu bewertenden Anbieterprodukt.

Lesen Sie dies als Lock-in-Warnung. Ein Framework, das einen proprietären Agentendialekt spricht, bindet Sie an eine einzige Roadmap. Ein Framework, das ein offenes Protokoll spricht, wahrt Ihren Ausstieg.

Prompt Injection bleibt unterbewertet

Prompt Injection ist der am meisten unterschätzte Angriff gegen Unternehmens-KI-Teams. Ein aus einem Retrieval-System gezogenes Dokument ist ein Angriffsvektor, der die eigenen Zugangsdaten des Nutzers trägt.

Die meisten RAG-Architekturen in Produktion behandeln abgerufene Dokumente als vertrauenswürdig. Diese Haltung ist falsch.

Ein einziges abgerufenes Artefakt genügt, um einen Agenten zu einer unbeabsichtigten Aktion umzulenken. Die Angriffsfläche ist die Retrieval-Grenze selbst. Der Angriff erfordert zwei Bedingungen: aktivierte Auto-Invocation und fehlende Ausführungsgrenzen.

Unsere frühere Analyse zu Sicherheitsmustern beim Retrieval behandelt die Isolationskontrollen, die diese Fehlerklasse eindämmen.

Der Kaskadenausfall ist Arithmetik

Multi-Agenten-Systeme in Produktion ohne explizite Circuit Breaker werden kaskadierend ausfallen. Das ist Arithmetik, keine Prognose.

Die Halluzinationsraten variieren zwischen den Modellen stark je nach Aufgabe und Version, und jeder Fehler in einem frühen Agenten pflanzt sich stromabwärts fort. Wenn die Ausgabe eines Agenten ohne unabhängige Validierung zur Eingabe des nächsten wird, verstärkt die Pipeline den Fehler.

Ein Circuit Breaker ist ein Validierungsgate, das die Fortpflanzung stoppt. Es prüft die Zwischenausgabe gegen eine externe Bedingung, bevor der nächste Agent sie verarbeitet.

Teams des Head of Engineering sollten jede Übergabe in ihrem KI-Agenten-Framework abbilden und markieren, welche davon validiert laufen. Die nicht markierten Übergaben sind die Kaskadenkandidaten.

Drei Fragen für Unternehmens-KI-Teams

Klären Sie vor dem nächsten Deployment drei Fragen. Jede entspricht einer konkreten Kontrolle.

1. Behandelt die Retrieval-Schicht Dokumente als nicht vertrauenswürdige Eingabe, mit Bereinigung vor dem Lesen durch das Modell?
2. Durchläuft jede Agenten-zu-Agenten-Übergabe ein unabhängiges Validierungsgate?
3. Sind Tool-Ausführungen durch explizite Berechtigungen begrenzt, die unterhalb der vollen Zugangsdaten des Nutzers liegen?

Ein Framework, das alle drei Fragen standardmäßig beantwortet, ist produktionsreif. Ein Framework, das alle drei dem Integrator überlässt, trägt technische Schulden, die Sie am ersten Tag erben.

Build, Buy und die Beschaffungsentscheidung

Die Build-versus-Buy-Rechnung hat sich verschoben. Vor zwei Jahren bauten Teams die Agentenorchestrierung mangels Alternativen intern. Nun existieren reife Frameworks.

Die Frage änderte sich von "Können wir das bauen" zu "Welches Lock-in akzeptieren wir". Jedes Framework kodiert Annahmen über Zustand, Speicher und Tool-Schemata.

Für den CFO ist die Infrastrukturwette riskanter, wo das Framework sich eng an eine einzige Cloud oder einen einzigen Modellanbieter koppelt. Portabilität senkt die Risikoprämie.

Der Technologiebeschaffungsausschuss sollte jeden Vertrag neu verhandeln, der ein proprietäres Agentenprotokoll voraussetzt. Die Unterstützung offener Protokolle gehört in den Vertrag statt in das Roadmap-Versprechen.

Entscheidungen für den nächsten Planungszyklus

Die Entscheidungen von CTO und Head of Engineering für den nächsten Planungszyklus reihen sich klar aneinander.

Erstens, klassifizieren Sie jedes abgerufene Dokument als nicht vertrauenswürdige Eingabe und fügen Sie an der Grenze eine Bereinigung hinzu. Zweitens, fügen Sie Circuit Breaker an jeder Multi-Agenten-Übergabe ein. Drittens, begrenzen Sie Tool-Berechtigungen unterhalb der Zugangsdaten des aufrufenden Nutzers.

Viertens, bevorzugen Sie Frameworks, die an offenen Protokollen unter neutraler Governance ausgerichtet sind. Diese eine Wahl wahrt Ihren architektonischen Ausstieg und beschränkt die Hebelwirkung des Anbieters.

Das KI-Agenten-Framework, das Sie dieses Jahr übernehmen, legt Ihre Fehlertoleranz-Obergrenze für die nächsten drei Jahre fest. Behandeln Sie diese Wahl als Architekturentscheidung, und sie wird zum Wettbewerbsvorteil. Behandeln Sie sie als Funktionshäkchen, und sie wird zur Falle.

Unsere Übersicht zu Governance-Mustern für Agenten beschreibt im Detail die Überwachungsschicht, die diese Kontrollen in Produktion beobachtbar macht.