Am 28. Januar 2026 öffnet ein Nutzer auf GitHub ein Issue im Repository des KI-Coding-Assistenten Cline. Der Titel des Issues enthält einen Befehl. Keinen Befehl an einen Menschen – einen Befehl an den Claude-basierten KI-Agenten, der die Triage neuer Issues automatisiert übernimmt.
Der Agent liest den Titel. Er interpretiert ihn als Instruktion. Er führt sie aus.
Drei Wochen später, am 17. Februar 2026, wird die Version cline@2.3.0 in der npm-Registry veröffentlicht. Das CLI-Binary ist byte-identisch mit der Vorgängerversion. Die einzige Änderung: eine Zeile in der package.json, die im Rahmen der Installation automatisch einen zweiten KI-Agenten namens OpenClaw 📎 mitinstalliert – jene Klasse lokal betriebener, endpointnaher KI-Agenten, die ich bereits im Februar 2026 als eigenständiges systemisches Risiko für Unternehmen und kritische Infrastrukturen eingeordnet habe, mit vollem Systemzugriff. In den nächsten acht Stunden laden rund 4.000 Entwicklermaschinen weltweit diese Version 📎. Ohne Zustimmung. Ohne sichtbaren Unterschied. Ohne dass npm audit, Code Review oder Provenance Attestation Alarm schlagen.
Niemand hat Zugangsdaten gestohlen. Keine Richtlinie wurde umgangen. Die Kette – Issue-Triage-Agent liest Prompt Injection, ein zweiter Agent führt npm install aus, eine poisoned Cache-Entry kapert die Release-Pipeline, der veröffentlichte Build installiert einen dritten Agenten – bestand aus Aktionen, die jede für sich legitim waren. Die Mechanik erinnert an den Trivy-Vorfall vom März 2026 📎, bei dem ein Sicherheitstool selbst zum Angriffsvektor wurde – mit dem Unterschied, dass bei Cline nicht ein Werkzeug kompromittiert war, sondern die Vertrauenskette zwischen mehreren KI-Agenten ausgenutzt wurde. Der Vorfall trägt heute den Namen Clinejection 📎. Er ist der erste in der Industrie breit dokumentierte Fall, in dem ein KI-Agent einem anderen KI-Agenten Autorität weitergereicht hat – und die Weitergabe genau das Problem produziert hat, das jede KRITIS-Prüfung spätestens mit dem Anwendungsstart der Annex-III-Pflichten des EU AI Act adressieren muss, der nach heutigem Stand spätestens am 2. Dezember 2027 greift.
Das ist die fünfte Komponente.
Die Lücke, die der Vorgängerartikel benannt hat – jetzt von innen
Ich habe in der Architekturanalyse vom 19. April 📎 fünf Komponenten beschrieben, mit denen sich ein tragfähiges Zugangskontrollmodell für agentische Systeme konsistent denken lässt: Just-in-Time Provisioning, Context-Aware Authorization, Continuous Verification, lückenlose Herkunftsdokumentation, Runtime Revocation. Die Analyse war der dritte Teil einer Reihe, die mit der Gefährdungsanalyse zu agentischer KI in kritischer Infrastruktur 📎 das Problem aufgemacht und mit der Diagnose zu Okta, Microsoft und IBM 📎 gezeigt hat, warum die verbreiteten IAM-Lösungen das Problem nicht adressieren. Für vier der fünf Komponenten existieren heute implementierbare Ansätze. Für die fünfte nicht.
Die fünfte ist die Bereichseinschränkung in Delegationsketten. Auf Englisch: scope narrowing. Auf Deutsch: die Garantie, dass weitergegebene Rechte niemals größer sind als die Rechte des delegierenden Agenten – und dass die Herkunft der Handlungsabsicht über jede Delegationsgrenze hinweg nachweisbar bleibt.
Diese Garantie existiert in keinem der heute verbreiteten Agent-Frameworks. Sie existiert auch nicht im dominierenden Protokoll, das die Kommunikation zwischen Agenten gerade industrialisiert.
Und sie ist die einzige der fünf Komponenten, die in Multi-Agenten-Architekturen überhaupt erst zum Problem wird. Wer einen einzelnen Agenten einsetzt, kommt mit den vier verfügbaren Komponenten weit. Wer zwei Agenten einsetzt, die miteinander sprechen, steht vor einer Norm – §30 Abs. 2 Nr. 9 BSIG – auf die heute noch niemand eine belastbare architektonische Antwort hat.
Clinejection ist der Beleg, dass das keine theoretische Übung ist. Die Kette bestand nicht aus einem kompromittierten Agenten. Sie bestand aus drei.
A2A: Das Protokoll, das die Frage aufwirft – aber nicht beantwortet
Am 9. April 2026 meldete die Linux Foundation, dass das Agent-to-Agent-Protokoll in weniger als einem Jahr 150 Organisationen, v1.0-Stabilität und produktive Einsätze erreicht hat 📎. Google initiierte es im April 2025, im Juni 2025 ging es an die Linux Foundation, im August 2025 wurde IBMs konkurrierendes ACP darin aufgenommen. Microsoft hat A2A in Azure AI Foundry und Copilot Studio integriert, AWS über Amazon Bedrock AgentCore Runtime. Für jede Organisation, die heute agentenübergreifende Kommunikation entwirft, ist A2A faktisch alternativlos.
Parallel dazu etablierte die Linux Foundation am 9. Dezember 2025 eine separate Struktur: die Agentic AI Foundation (AAIF) 📎. Co-Founder sind Anthropic, Block und OpenAI, mit Unterstützung von Google, Microsoft, AWS, Bloomberg und Cloudflare. Die drei Gründungsprojekte: Anthropics Model Context Protocol 📎, Blocks Agent-Framework goose, und OpenAIs AGENTS.md-Konvention. A2A bleibt ein eigenständiges Linux-Foundation-Projekt außerhalb der AAIF – die beiden Standards sind komplementär: MCP definiert, wie Agenten auf Werkzeuge zugreifen, A2A definiert, wie Agenten miteinander sprechen.
Beide Standards lösen reale Probleme. A2A liefert Signed Agent Cards für kryptografische Identität, Capability Discovery für strukturierte Fähigkeitsverhandlung, eine web-aligned Architektur, die mit existierender Sicherheits- und Lastverteilung kompatibel ist. Das ist solide Ingenieurarbeit.
Was A2A nicht liefert, ist die Delegationssemantik.
Das Protokoll definiert, wie Agent A den Agenten B findet, wie er sich identifiziert, wie er eine Aufgabe übergibt. Es definiert nicht, welche Berechtigungen bei dieser Übergabe verengt werden müssen. Es definiert nicht, wie Agent B prüfen soll, ob der Auftrag, den er aus Agent A erhält, auf einen autorisierten Ursprung zurückführbar ist. Und es definiert nicht, wie der ursprüngliche Nutzerauftrag über drei, vier, sieben Delegationsschritte hinweg nachweisbar bleibt.
Das ist keine Kritik am Protokoll. A2A ist ein Transport- und Kommunikationsstandard. Die Delegationssemantik ist eine Architekturschicht darüber.
Aber: Diese Schicht existiert öffentlich nicht als Standard. Und solange sie nicht existiert, bedeutet jede A2A-Einführung in KRITIS-Umgebungen, dass der Betreiber diese Schicht selbst definieren muss – auf Eigenverantwortung, ohne Referenzarchitektur, ohne Prüfmaßstab.
Der überlistete Stellvertreter skaliert
Das strukturelle Problem ist nicht neu. Es trägt seit Norm Hardys Arbeit von 1988 den Namen „Confused Deputy“. Was neu ist, ist seine Wirkkraft in Mehr-Agenten-Architekturen.
Die Cloud Security Alliance hat am 23. März 2026 eine Research Note veröffentlicht 📎, die das Problem in vier Stadien beschreibt und Clinejection als Referenzfall heranzieht. Im ersten Stadium – Injection Vector – erreicht eine manipulierte Eingabe das Kontextfenster eines Agenten über einen Kanal, den dieser regulär verarbeitet. Bei Cline war das ein GitHub-Issue-Titel. Im zweiten Stadium – Authority Inheritance – führt der Agent die injizierte Instruktion mit seinen legitimen Berechtigungen aus. Die Ausnutzung erfolgt nicht durch Speichersicherheitslücken oder Authentifizierungs-Bypass. Sie erfolgt, weil der Agent tut, wofür er gebaut ist. Im dritten Stadium – Action Propagation – wandert die Wirkung durch mehrere Ausführungsumgebungen. Bei Cline waren es drei: der GitHub-Issue-Triage-Workflow, eine Claude-Coding-Session, die Release-Pipeline. Jeder einzelne Schritt war plausibel. Die Überraschung lag in der Kette.
Das vierte Stadium ist der Punkt, an dem Einzel-Agent-Sicherheit aufhört zu funktionieren: Authority Re-Delegation. Der kompromittierte Agent oder seine Artefakte injizieren ihrerseits in nachfolgende Systeme. Ein kompromittierter Coding-Agent erzeugt Code, den ein Review-Agent später liest. Ein installiertes Paket enthält weitere Prompt Injections für den nächsten Agenten, der es verarbeitet. Im Cline-Fall war das nachgelagerte System die Entwicklermaschine selbst – auf jeder wurde OpenClaw installiert, ein autonomer KI-Agent mit Zugriff auf E-Mail, Kalender, ausgeführte Programme und Kommunikationsplattformen wie Discord, Signal, Teams und WhatsApp. Aus einem kompromittierten Triage-Bot wurden 4.000 kompromittierte Endgeräte mit je einem autonomen Agenten. Die technische Angriffsflächen-Analyse dieser Agent-Klasse 📎, die ich zehn Tage vor dem Vorfall veröffentlicht hatte, benannte Supply Chain Compromise (T1195) und Confused Deputy als genau jene Muster, die Clinejection im Februar dann operativ vorführte – nicht als Prognose, sondern als Beschreibung einer bereits existierenden Risikoklasse, die nur noch auf ihren ersten breit dokumentierten Anwendungsfall wartete.
Ein arXiv-Preprint vom 17. Januar 2026 📎 – Zimo Ji et al., „Taming Various Privilege Escalation in LLM-Based Agent Systems“ – beschreibt das systematisch. Die Autoren identifizieren fünf distinkte Privilege-Escalation-Vektoren in LLM-basierten Agentensystemen: direkte Prompt Injection, indirekte Prompt Injection, RAG Poisoning, untrusted Agents, und – neu in Multi-Agent-Systemen – den Confused-Deputy-Angriff zwischen Agenten. Ihr Testszenario ist ein Smart-Home-System, in dem ein Low-Privilege-Agent einen Smart-Lock-Agent mit höheren Rechten dazu bringt, die Haustür zu öffnen. Der Smart-Lock-Agent handelt innerhalb seiner Berechtigungen. Die Tür öffnet sich ohne expliziten Nutzerauftrag.
Was ein Smart-Lock im Paper ist, ist in KRITIS eine Kalibrierungsschnittstelle. Oder eine Lastflusssteuerung. Oder ein Zahlungsverkehrsagent.
Die Autoren kommen zu einem eindeutigen Befund: Selbst mit aktuellen, dem Stand der Technik entsprechenden Schutzmechanismen wie IsolateGPT bleibt Privilege Escalation in Mehr-Agenten-Systemen bestehen. Das ist kein Implementierungsproblem einzelner Frameworks. Es ist die Folge davon, dass kein verbreiteter Mechanismus existiert, der die Kommunikation zwischen Agenten einer verpflichtenden Zugriffskontrolle unterwirft. Der Fachausdruck der Autoren: Mandatory Access Control für Agent-zu-Agent-Interaktionen. Das ist die akademisch klare Antwort. Eine marktverfügbare Antwort ist sie noch nicht.
Warum Kontext allein nicht ausreicht
Eine Nebenbeobachtung, die selten gemacht wird: Die Verschiebung ist nicht nur adversarial. Auch ohne Angreifer entstehen diese Probleme.
Acuvity hat das im Februar 2026 unter dem Begriff Semantic Privilege Escalation beschrieben 📎: Ein Agent interpretiert eine Aufgabe breiter als beabsichtigt, zieht dabei Daten heran, die semantisch passen, aber autorisatorisch nicht gedeckt sind. Bei Multi-Agent-Handoffs verschärft sich das: Der delegierte Agent erhält eine Teilaufgabe ohne den vollen Kontext der ursprünglichen Nutzerabsicht. Seine Interpretation weicht systematisch von dem ab, was der Nutzer ursprünglich wollte.
Das ist nicht böswillig. Es ist das natürliche Ergebnis einer Architektur, in der Handlungsabsicht zwischen Systemgrenzen verloren geht.
Context-Aware Authorization auf Einzelagenten-Ebene – die zweite der fünf Komponenten – löst das nicht. Sie prüft, ob eine Aktion zum Kontext der Aufgabe passt. Sie prüft nicht, ob die Aufgabe selbst noch im Rahmen dessen ist, was der ursprüngliche Nutzerauftrag abgedeckt hat, nachdem drei Agenten sie umformuliert haben.
Die Frage ist also nicht nur: Hat der Agent, der gerade handelt, die Berechtigung? Sondern: Hat die gesamte Delegationskette, die zu dieser Handlung geführt hat, einen autorisierten Ursprung – und wurden die Rechte in jedem Schritt nur enger, nie weiter?
Die zweite Bedingung ist das, was heute strukturell nicht erzwungen wird.
Was Betreiber heute tatsächlich tragen können
Es gibt keine marktreife Standardarchitektur, die das Delegationsproblem vollständig löst. Es gibt aber drei Bausteine, die zusammen heute mehr leisten als jede Einzel-Agent-Lösung – wenn ein Betreiber sie diszipliniert anwendet.
Der erste Baustein ist architektonisch: die Trennung von Agenten in Vertrauenszonen. Ein Agent, der externe Eingaben verarbeitet – Web, E-Mail, Dokumente, Issue-Trackers aus unbekannten Quellen – hat in KRITIS keine direkte Kommunikationsbefugnis mit Agenten, die schreibende Aktionen auf kritischen Systemen ausführen. Zwischen den Zonen stehen definierte, überwachte Kanäle, die Eingaben bereinigen, Richtlinien prüfen und Aufrufe dokumentieren. Das ist keine neue Idee. Es ist die Übertragung der Zonenarchitektur aus der klassischen OT-Sicherheit – die in deutschen KRITIS-Umgebungen seit Jahren ohnehin existiert – auf die agentische Ebene. Hätte der Cline-Issue-Triage-Workflow keine direkte Schreibberechtigung auf das Release-Artefakt-System gehabt, wäre Clinejection an dieser Zonengrenze gescheitert.
Der zweite Baustein ist technisch und heute partiell verfügbar: Execution Rings. Microsoft hat im April 2026 sein Agent Governance Toolkit als Open Source veröffentlicht 📎 und darin ein Privilegierungsmodell nach Vorbild der CPU-Rings implementiert. Neue Agenten starten eingeschränkt. Delegation zwischen Ringen folgt festen Regeln: Ein Agent in Ring 2 kann Aufgaben an einen Agenten in Ring 3 delegieren, nicht umgekehrt. Versuche, diese Grenze zu überschreiten, werden in unter 0,1 Millisekunden blockiert. Das adressiert die Delegationsrichtung – also, dass Rechte sich im Zuge einer Kette nicht ausweiten dürfen. Es adressiert nicht die Herkunftsdokumentation, also die Frage, ob die Delegationskette auf einen autorisierten Ursprung zurückführbar ist.
Der dritte Baustein ist regulatorisch und liegt vollständig in der Verantwortung des Betreibers: die explizite Dokumentation, welche Agent-zu-Agent-Übergaben überhaupt zulässig sind. Das ist keine technische Komponente. Es ist eine architektonische Entscheidung, die in das Zugangskontrollkonzept nach §30 Abs. 2 Nr. 9 BSIG eingehen muss. Jede erlaubte Delegationsbeziehung wird als Konfiguration festgelegt, jede nicht explizit erlaubte Beziehung ist verboten. Das ist mühsam. Es ist die einzige Methode, die heute prüferisch belastbar ist.
Diese drei Bausteine zusammen ergeben keine vollständige Antwort. Sie ergeben die belastbarste Antwort, die heute verfügbar ist – und damit das, was die Geschäftsführung nach §38 BSIG nachweislich verantworten kann.
Zugriff als Zustand. Zugriff als Kette.
§30 Abs. 2 Nr. 9 BSIG verlangt ein Konzept für die Zugriffskontrolle. Ich habe im Vorgängerartikel ausgeführt 📎, dass „Konzept“ in dieser Norm keine Dokumentenpflicht bedeutet, sondern abbildbare Steuerungslogik. Das Konzept muss die Realität des Systems beschreiben, nicht eine Idealvorstellung. Genau dieser Punkt wird in Multi-Agenten-Architekturen zur Bruchstelle.
In klassischen Systemen ist Zugriff ein Zustand, den eine Identität besitzt oder nicht besitzt. Eine Rolle hat Rechte, ein Token ist gültig oder abgelaufen, eine Berechtigung greift oder greift nicht. Zugriffskontrolle prüft diesen Zustand – im Moment der Anfrage, am Tor zum System. Das ist das Modell, für das §30 ursprünglich gedacht war, und das klassisches IAM implementiert.
In agentischen Mehrschichtsystemen ist Zugriff keine Zustandsfrage mehr. Er ist eine Kette. Eine Handlung am Ende der Kette entsteht aus einer Anweisung am Anfang, die über mehrere Agenten, Umformulierungen und Delegationsschritte hinweg transformiert wurde. Wer nur den Zustand am Ende prüft, prüft nichts Relevantes. Die Zugriffsrealität entsteht nicht aus den Einzelprofilen. Sie entsteht aus ihrer Verkettung.
Und jede Kette ist ein Angriffspfad.
Daraus folgen vier Prüfkriterien für Delegationsketten nach §30 BSIG – eine prüfbare Negativdefinition der Zugriffskontrollpflicht in Multi-Agent-Systemen. Ein Mehr-Agenten-System in einem unter §30 fallenden Prozess erfüllt die Pflicht nicht, wenn auch nur eine der folgenden vier Bedingungen zutrifft.
Erstens: Die Delegationsbeziehungen zwischen Agenten sind nicht explizit modelliert. Welcher Agent darf welchen anderen Agenten in welchem Kontext beauftragen? Wer diese Frage nicht beantworten kann – nicht in einer Dokumentation, sondern in der tatsächlichen Konfiguration des Systems –, hat keine Zugriffskontrolle. Er hat ein Vertrauensverhältnis.
Zweitens: Es existiert kein technisch erzwungener Mechanismus zur Bereichseinschränkung. Wenn ein Agent mit breiten Rechten einen Unterauftrag an einen anderen Agenten weitergibt, müssen die an diesen weitergegebenen Rechte zwingend enger sein als seine eigenen, nie weiter. Was nicht technisch durchgesetzt wird, wird irgendwann verletzt – versehentlich, durch Fehlkonfiguration oder durch Prompt Injection.
Drittens: Die Handlungsherkunft ist über die gesamte Kette nicht rekonstruierbar. Ein Prüfer muss für jede in einem KRITIS-System ausgeführte Aktion zurückverfolgen können, welcher autorisierte Nutzer- oder Systemauftrag sie ausgelöst hat – auch wenn zwischen Ursprung und Aktion drei, fünf oder sieben Agentenwechsel liegen. Fehlt diese durchgehende Herkunftsdokumentation, fehlt die Zugriffsrealität selbst. Die strukturelle Beobachtungslücke, die bereits heute in Security Operations Centern existiert 📎, ist in agentischen Mehrschichtsystemen kein SOC-Problem mehr, sondern ein §30-Problem: Was das SOC nicht sieht, kann der Prüfer nicht bestätigen. Die OpenTelemetry GenAI Semantic Conventions, auf die ich im Vorgängerartikel als interoperablen Bezugspunkt hingewiesen habe, sind zum Zeitpunkt dieses Artikels weiterhin im Status „Development“, also ausdrücklich nicht stabil; auch die inzwischen veröffentlichten Konventionen für GenAI Agent and Framework Spans tragen denselben Status. Sie existieren – aber sie sind noch kein stabiler, prüferisch belastbarer Interoperabilitätsanker. Wer darauf wartet, wartet auf einen Standard, der noch nicht belastbar ist.
Viertens: Die Revocation wirkt nicht transitiv. Wird ein Agent in einer Kette blockiert – weil eine Richtlinie einen Verstoß erkennt –, müssen alle von ihm initiierten nachgelagerten Aufträge kontrolliert beendet werden. Ein Blockademechanismus, der nur auf den Einzelagenten wirkt, lässt die Folgewirkungen einer kompromittierten Kette weiterlaufen – mit Zugangsdaten, die formal noch gültig sind, und mit Aufträgen, die formal noch autorisiert wirken.
Wer auch nur einen dieser vier Punkte nicht abdecken kann, hat aus prüferischer Sicht Zugriffskontrolle im Sinne von §30 nicht implementiert. Er hat sie simuliert. Das ist kein metaphorischer Vorwurf. Es ist das Muster, das ich in „Audit bestanden. Betrieb tot.“ 📎 für Europas Cybersicherheitslandschaft allgemein beschrieben habe: formal konform, operativ entkernt. In agentischen Mehrschichtsystemen ist dieses Muster nicht die Ausnahme – es ist der Default, solange Delegationssemantik nicht explizit erzwungen wird.
Das ist keine rhetorische Zuspitzung. Es ist der operative Ausfluss einer Norm, die Zugriffskontrolle nicht als Identitätsprüfung definiert, sondern als Steuerungslogik über die tatsächliche Zugriffsrealität. Und in agentischen Mehrschichtsystemen ist diese Realität keine Frage von Identitäten mehr. Sie ist eine Frage von Ketten.
Was das für die Geschäftsführung heißt
§38 BSIG adressiert die Geschäftsleitung direkt. Die Leitungsorgane besonders wichtiger und wichtiger Einrichtungen müssen die Risikomanagementmaßnahmen billigen und ihre Umsetzung überwachen. Bei Pflichtverletzungen haftet die Leitung persönlich.
Die unbequeme Konsequenz: Wer heute Multi-Agenten-Systeme in KRITIS-Prozessen einsetzt, ohne die vier Prüfkriterien für Delegationsketten nach §30 BSIG nachweislich zu erfüllen, trägt diese Haftung aktiv. „Der Markt bietet keine Lösung“ ist keine Entlastung. Der Stand der Technik muss für die Risikoklasse geeignet sein. Die Haftungsfolge greift nicht erst beim Bußgeld 📎 – sie greift in dem Moment, in dem ein Prüfer oder Staatsanwalt die Frage stellt, warum ein System mit nicht belegbarer Delegationskontrolle in einem KRITIS-Kernprozess produktiv lief. Wer Systeme einsetzt, deren Delegationsverhalten nicht prüferisch belegbar ist, hat sie in dieser Einsatzklasse zu früh eingesetzt.
Es gibt nur drei handlungslogische Positionen.
Die erste: Multi-Agenten-Systeme in KRITIS-Kernprozessen bis auf Weiteres nicht einsetzen. Einzelagenten mit den vier verfügbaren Komponenten betreiben. Warten, bis eine marktreife Standardarchitektur für Delegationsketten existiert. Das ist die risikoärmste, aber auch die wettbewerbsärmste Position.
Die zweite: Multi-Agenten-Systeme einsetzen, aber das Delegationsmodell auf Eigenverantwortung architektonisch definieren, technisch durchsetzen und gegenüber Prüfern dokumentieren. Das ist die anspruchsvollste Position. Sie setzt voraus, dass die Organisation die architektonische Kompetenz aufbaut, die Frameworks und Infrastrukturanbieter heute nicht liefern.
Die dritte: Hersteller verpflichten, auf konkrete Fragen zur Delegationssemantik konkrete Antworten zu geben – vor der Beschaffung, nicht nach dem ersten Incident. Welche Delegationsbeziehungen sind in der gelieferten Architektur möglich? Wie wird Bereichseinschränkung erzwungen? Wie wird die Herkunft der Handlungsabsicht über die Kette hinweg dokumentiert? Wer diese Fragen nicht stellt, schafft eine Nachweislücke, die sich später nicht mehr schließen lässt.
Was der Anwendungsstart daran ändert – und was nicht
Der EU AI Act verbindet mit dem Anwendungsstart der spezifischen Pflichten für Hochrisiko-KI-Systeme nach Anhang III unter anderem die Anforderungen aus Art. 12 – automatisches Logging, das Rückverfolgung ermöglicht – und Art. 14 – wirksame menschliche Aufsicht. Mit dem Digital Omnibus vom 19. November 2025 📎 hat die Kommission vorgeschlagen, den Anwendungsstart an die Verfügbarkeit von Unterstützungsinstrumenten – einschließlich harmonisierter Standards – zu koppeln. Nach aktueller Darstellung greifen die Regeln für Annex-III-Systeme spätestens am 2. Dezember 2027, gegebenenfalls früher, sobald die Unterstützungsinstrumente verfügbar sind. Was das konkret für Anbieter aus Nicht-EU-Märkten bedeutet 📎, habe ich an anderer Stelle ausgeführt: Die Omnibus-Erleichterung ist strategisch keine Entspannung, sondern eine Verschiebung der Beweislast ins Ungewisse.
Beide Artikel sind für Einzelagenten bereits anspruchsvoll. In Multi-Agent-Systemen mit dynamischen Delegationsketten werden sie zur architektonischen Voraussetzung für Betriebsfähigkeit. Ein System, das nicht belegen kann, welche Delegationskette zu welcher Aktion geführt hat, kann nicht rückverfolgbar geloggt sein. Ein System, in dem menschliche Aufsicht nach einer Kaskade von Agent-zu-Agent-Übergaben nur noch das Endergebnis sieht, erfüllt die Anforderung an wirksame Aufsicht nicht.
Die Omnibus-Logik verschiebt die Frage nicht in die Zukunft. Sie macht sie unausweichlich – und anders als bisher auch ohne festes Zieldatum. Wer darauf setzt, dass sich der Anwendungsstart verzögert, kalkuliert falsch: Entweder greift der Annex-III-Start früher, weil die Standards schneller kommen, oder er greift spätestens Ende 2027. Beides bedeutet, dass die Architekturfrage jetzt beantwortet werden muss. Die Pflichten aus §30 BSIG gelten ohnehin bereits heute.
Was zwischen jetzt und dem Anwendungsstart entschieden werden muss, ist keine Frage der Technologie. Es ist die Frage, ob die Organisation bereit ist, die Architektur ihrer agentischen Systeme so zu bauen, dass sie die vier Prüfkriterien für Delegationsketten nach §30 belegbar erfüllt – bevor der nächste Clinejection diese Frage unter Zeitdruck beantwortet.
In meiner Arbeit als leitender Sicherheitsarchitekt sehe ich Multi-Agenten-Architekturen zunehmend auch dort, wo die Geschäftsführung den Übergang vom Einzel- zum Mehr-Agent-System nicht bewusst getroffen hat. Frameworks wie LangGraph, AutoGen oder die A2A-basierten Integrationen der großen Cloudanbieter machen diesen Übergang technisch so einfach, dass er oft aus Effizienzgründen passiert, bevor die Architekturfrage gestellt ist. Das ist der häufigste Fall, in dem §30 zur Haftungslage wird, ohne dass jemand eine bewusste Entscheidung getroffen hat.
Sie setzen Multi-Agent-Systeme ein – oder Ihre Fachbereiche bauen sie gerade auf – und fragen sich, welche Delegationsbeziehungen unter §30 dokumentierbar sein müssen? Dann ist jetzt der Zeitpunkt, darüber zu sprechen. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar