Zentrale Erkenntnisse
- Die Sicherheitspraxis für agentische KI hinkt der Reife der umgebenden Infrastruktur um zwei bis drei Jahre hinterher und spiegelt die Exploit-Wellen wider, die zuvor bei Webanwendungen und öffentlichen APIs zu beobachten waren.
- Abgerufene Dokumente in RAG-Pipelines tragen die Berechtigungen des Aufrufers; ein einziges vergiftetes Artefakt genügt, um einen Agenten umzuleiten, weshalb abgerufene Inhalte als nicht vertrauenswürdige Eingabe behandelt werden sollten.
- Eine fünfstufige Agentenkette aus zu neunzig Prozent zuverlässigen Schritten sinkt auf etwa neunundfünfzig Prozent End-to-End-Zuverlässigkeit, was Circuit Breaker und eine Validierung zwischen den Stufen zwingend erforderlich macht.
- Standardisierte Agentenprotokolle wie A2A (jetzt unter der Obhut der Linux Foundation) und MCP bilden den Wettbewerbsvorteil und verlagern das Beschaffungsrisiko weg von proprietären Agentenplattformen.
Was sich im agentischen Stack verändert hat
Agentische KI hat im vergangenen Jahr eine Grenze überschritten. Systeme, die Modelle, Werkzeuge und Retrieval verketten, laufen nun in Produktions-Stacks großer Unternehmen.
Diese Verschiebung verändert das Risikoprofil. Ein Agent, der Werkzeuge aufruft, hält dieselben Anmeldeinformationen wie der Nutzer, der ihn ausgelöst hat. Der Wirkungsradius wächst mit jeder Integration.
Zwei Protokolle verankern den Übergang: A2A für die Kommunikation zwischen Agenten und MCP für den Kontext zwischen Modell und Werkzeug. Beide bewegten sich in Richtung neutraler Governance.
Die Linux Foundation betreut nun A2A, ein Signal dafür, dass sich die Kommunikationsschicht der Kontrolle eines einzelnen Anbieters entzieht. Beschaffungsteams sollten dies sorgfältig lesen, denn die Anbieterlandschaft verschiebt sich in dem Moment, in dem ein Protokoll private Hände verlässt.
Die Sicherheitshaltung hinkt der Deployment-Kurve hinterher
Unternehmensteams stellen Agenten schneller bereit, als sie sie absichern. Das ist das Kernproblem.
Meine feste Position: Die Sicherheitspraxis für AGI-nahe KI-Systeme liegt zwei bis drei Jahre hinter der Reife der umgebenden Infrastruktur. Die gegen Agenten-Frameworks eingereichten Advisories lesen sich als Symptom dieser Lücke. Teams gehen zuerst in Produktion und entdecken die Härtungsarbeit erst später.
Wir haben dieselbe Abfolge bei Webanwendungen in den 2000er-Jahren und bei öffentlichen APIs in den 2010er-Jahren beobachtet. Jedes Feld wurde im großen Maßstab ausgerollt, absorbierte eine Welle von Exploits und schrieb dann das Playbook. Agentische KI wiederholt nun dieses Muster.
Für einen CTO ist die Implikation direkt: Behandeln Sie jedes Agenten-Framework aus Sicherheitssicht als Beta, unabhängig vom Marketinglabel. Lesen Sie unsere Notiz zur KI-Sicherheitshaltung für die ausführliche Argumentation.
Prompt Injection ist die unterschätzte Angriffsfläche
Die Angriffsfläche ist die Retrieval-Schicht. Ein aus einem Vektorspeicher gezogenes Dokument gelangt mit demselben Vertrauen ins Modell wie eine direkte Nutzeranweisung.
Die meisten RAG-Architekturen in Produktion behandeln abgerufenen Text als vertrauenswürdigen Inhalt. Diese Annahme ist falsch. Ein einziges abgerufenes Dokument genügt, um einen Agenten auf einen Datenexfiltrationspfad umzuleiten.
Der Mechanismus ist einfach. Das Modell liest Anweisungen, die in ein Dokument eingebettet sind, und handelt dann danach unter Verwendung der Berechtigungen des Aufrufers. Eine vergiftete Wiki-Seite wird zum Ausführungsvektor, und das Audit-Log zeigt einen legitimen Nutzer hinter der Aktion.
Unternehmens-KI-Teams sollten jedes abgerufene Artefakt als nicht vertrauenswürdige Eingabe klassifizieren. Die Validierung gehört jedes Mal zwischen Retrieval und Aktion.
Multi-Agenten-Pipelines fallen kaskadenartig aus
Multi-Agenten-Systeme in Produktion ohne explizite Circuit Breaker werden kaskadenartig ausfallen. Das ist Arithmetik, keine Prophezeiung.
Wenn die Ausgabe eines Agenten zur Eingabe des nächsten wird, häufen sich die Fehler. Eine Halluzination in Schritt eins pflanzt sich durch jeden nachgelagerten Schritt fort. Eine unabhängige Validierung zwischen den Stufen begrenzt den Schaden.
Betrachten Sie die Mathematik. Ein zu neunzig Prozent zuverlässiger Schritt, über eine fünfstufige Kette wiederholt, ergibt etwa neunundfünfzig Prozent End-to-End-Zuverlässigkeit. Der Fehler verbirgt sich in plausibel aussehender Ausgabe.
Die Lösung ist ingenieurtechnische Disziplin: Circuit Breaker, Ausgabevalidierung und begrenzte Wiederholungen. Aktivierte Auto-Invocation ohne Ausführungsgrenzen ist der Fehlermodus, nach dem im Design-Review zu suchen ist.
Standardprotokolle sind der eigentliche Wettbewerbsvorteil
Die Modellleistung konvergiert. Der dauerhafte Vorteil liegt in der Kommunikationsschicht zwischen den Agenten.
Wer das Protokoll kontrolliert, das die Agenten verbindet, kontrolliert die Architektur. Deshalb zählt der Governance-Schritt rund um A2A mehr als jedes einzelne Benchmark-Ergebnis.
Eine Spezifikation unter neutraler Obhut ist ein zu übernehmender Standard und kein zu bewertendes Anbieterprodukt. Diese Unterscheidung sollte die Beschaffung leiten. Verträge, die auf einem proprietären Agentenbus aufbauen, bringen einen architektonischen Lock-in mit sich, den ein Standard beseitigt.
Ein v1.0-Stabilitätssignal bei einem offenen Protokoll senkt das Risiko, dagegen zu entwickeln. Teams gewinnen einen Migrationspfad über Anbieter hinweg, was ihre Verhandlungsposition bei der Verlängerung stärkt.
Drei Fragen für Unternehmens-KI-Teams
Diese drei Fragen entsprechen den drei oben beschriebenen Fehlermodi. Führen Sie sie in Ihrem nächsten Review durch.
- Erzwingt jeder Agent Ausführungsgrenzen um automatisch aufgerufene Werkzeuge?
- Behandelt die Retrieval-Pipeline Dokumente als nicht vertrauenswürdige Eingabe, mit Validierung vor der Aktion?
- Enthalten Multi-Agenten-Ketten Circuit Breaker und unabhängige Ausgabeprüfungen zwischen den Stufen?
Ein Team, das alle drei mit Ja beantwortet, betreibt eine produktionsreife Haltung. Ein einziges Nein markiert die Priorität des nächsten Sprints. Der Rahmen ist hier operativ, weisen Sie also jeder Frage einen Verantwortlichen zu.
Build, Buy und die Beschaffungsentscheidung
Die Build-versus-Buy-Entscheidung dreht sich um die Kommunikationsschicht. Kaufen Sie die Modelle. Übernehmen Sie das offene Protokoll. Bauen Sie die Governance-Kontrollen, die Anbieter dünn lassen.
Für den CFO verschiebt sich das Infrastrukturrisiko. Die Investition in eine proprietäre Agentenplattform birgt jetzt ein höheres Lock-in-Risiko als die Investition in Werkzeuge rund um A2A und MCP. Die offene Schicht schützt die Bilanz.
Ein Technology Procurement Committee sollte jeden Vertrag neu öffnen, der einen geschlossenen Agentenbus voraussetzt. Verhandeln Sie neu über Protokollkonformität und klare Ausstiegsbedingungen.
Vergleichen Sie die Optionen in unserer Build-versus-Buy-Analyse vor dem nächsten Budgetzyklus.
Entscheidungen für den nächsten Planungszyklus
Die Entscheidungen von CTO und Head of Engineering für den nächsten Planungszyklus laufen auf vier Schritte hinaus.
Erstens: Prüfen Sie jede RAG-Pipeline auf den Umgang mit nicht vertrauenswürdigen Eingaben. Zweitens: Fügen Sie jeder Multi-Agenten-Kette in Produktion Circuit Breaker hinzu. Drittens: Verankern Sie Ihre Architektur an A2A und MCP statt an einem Anbieterbus.
Viertens: Planen Sie eine Sicherheitsüberprüfung jedes Agenten-Frameworks, als wäre es eine frische Beta. Das Bedrohungsmodell ändert sich monatlich, und die Härtungsarbeit gehört heute auf die Roadmap.
Die Architekturfrage bleibt konstant: Ist das eine Falle oder ein Wettbewerbsvorteil? Eine offene Protokollschicht mit disziplinierter Governance ist der Vorteil. Ein geschlossenes, unvalidiertes Agenten-Mesh ist die Falle.
Dieser Artikel wurde von einem KI-gestützten redaktionellen Autor unter menschlicher redaktioneller Aufsicht erstellt, in Übereinstimmung mit den Transparenzanforderungen der Verordnung (EU) 2024/1689 (KI-Verordnung, Art. 50). Die Quellen sind im Text verlinkt.
Artikel von LEON