Wie normative Anforderungen zu technischen Grenzen für KI-gestützte Security-Tests werden
Vor ein paar Jahren war der Begriff “Tech Law” in der Szene wie eine Seuche: Zum einen waren da die Old School-Juristen, die endlich einen Chance witterten, mit ihren Themenfeldern wieder in alle Munde zu kommen: angefangen vom angestaubten Gewerblichen Rechtsschutz über das Urheber- und das Datenschutzrecht bis hin zum IT-Recht (Softwareverträge, E-Commerce-Recht, Cloud Computing, IT-Sicherheitsrecht) – man gab sich jung, frisch und am Puls der Zeit. Und dann bogen die Hipster unter den Tech Lawyers um die Ecke, die ihre Blogs mit Begriffen wir Block Chain, Code ist Law, Smart Contracts, Tokenisierung und NFTs, DAOs, Oracles fluteten – einmal mehr beseelt vom Wunsch, die Aufmerksamkeitswelle auch mal mit ein paar juristischen Themen reiten zu können.
Wenn man heute die juristischen Frontier- oder Edge-Themen auf einer Perlenkette aufreihen wollte, finden sich dann solche Schlagworte wie KI-Agenten als Vertragspartner, Rules-as-Code, Agent-Kartelle (bspw. im Kontext von Preisabsprachen), Digital Twins, Quantencomputing und digitale Signatur und Neurorights. All diesen Themen ist gemein, dass man auf diese im Rahmen des hergebrachten Rechtsrahmens keine verlässlichen Antworten geben kann. Verengt man den Blick auf potentielle Fallgestaltungen im Kontext eines OEMs, sind wir diesbezüglich auch mit hinreichend Potential für juristische Aufarbeitung gesegnet. Beispielhaft seien an dieser Stelle folgende Themen genannt:
- LLM-gestütztes Pentesting: Was gilt, wenn der Agent den vereinbarten Scope verlässt? Offen sind Autorisierung, Hackerparagraf und Haftung zwischen Auftraggeber, Supplier und Tool-Anbieter.
- KI-generierter Code im CRA: Wer ist Hersteller, wer schuldet die Sorgfalt, und gehört das Modell in die SBOM?
- Scope-Kollision CRA und R155: Das Fahrzeug ist ausgenommen, aber was ist mit Aftermarket, Ladeinfrastruktur und Backend?
- Data Act gegen Cybersecurity: Die Pflicht zum Datenzugang trifft auf die Pflicht zur Abschottung.
- Kollidierende Meldepflichten für Schwachstellen: EU und China verlangen jeweils zuerst die Meldung an die eigene Behörde.
- OTA-Updates und Typgenehmigung: Ab wann ist ein Update ein neues Fahrzeug?
- Herkunft als Rechtskriterium: Bei ICTS-Regeln und Connected-Vehicle-Verboten wird Geopolitik zur Compliance-Frage.
- “Stand der Technik” und Post-Quantum: Ab wann ist fehlende Krypto-Agilität ein Rechtsverstoß?
Der vorliegende Blogbeitrag beschäftigt sich in der Frage, wie man als Produktverantwortlicher die normative Verpflichtung zur Validierung (nachfolgend i.S.d. Pentestings) des eigenen Produkts bzgl. Schwachstellen unter Nutzung von LLM-Modellen so designed, orchestriert und dokumentiert, dass man weder zu kurz (“Nein! Sie haben nicht alles getan, um Schwachstellen in ihrem Fahrzeug zu finden.”) noch zu weit (Schade, dass ihre Pentester diese unscheinbare Drittbibliothek im Code des Suppliers auch noch getestet haben und dabei auch noch Lastenhefte, Specs usw. in die Cloud des LLM-Abieters hochgeladen haben) springt. Dies ist mithin ein Tanz auf der Rasierklinge, der natürlich in einem Umfeld, welches durch die Neugier von Ingenieuren vorangetrieben wird, häufig immer erst zu einer technischen Lösungen/Implementierung führt und dann erst im zweiten Schritt die normativen Regeln nachzieht.
Doch nun genug des Vorspiels. Starten wir zunächst mit einem kleinen Beispiel, um das Problem zur verdeutlichen:
Stellen wir uns vor, ein KI-Agent untersucht die Software eines Steuergeräts im Testlabor. Er entdeckt Zugangsdaten und schlägt vor, sie gleich am Backend eines Suppliers auszuprobieren. Technisch ist das eine naheliegende Anschlussfrage. Für den Testauftrag kann es ein Sprung über die Grenze sein: War das Backend freigegeben? Wer dürfte einen solchen Zugriff erlauben? Und welche Informationen hat der Agent bis dahin bereits verarbeitet?
Diese Fragen lassen sich nicht erst im Abschlussbericht beantworten. Eine Plattform für agentische Security-Tests muss den zulässigen Handlungsrahmen kennen, bevor der erste Toolaufruf erfolgt.
Die Übersetzungslücke zwischen Anforderung und Test
In der Automotive Cybersecurity (ACS) sind wir gewohnt, Risiken, Maßnahmen und Nachweise über den Lebenszyklus eines Fahrzeugs zu betrachten. Die UN-R155 verlangt unter anderem Prozesse für Cybersecurity-Tests und den Umgang mit Risiken und Abhängigkeiten in der Lieferkette. Sie schreibt keine KI-Agenten vor. Sie stellt aber eine Frage, die mit wachsender Testautomatisierung konkreter wird: Wie lässt sich nachweisen, dass Prüfungen wirksam, nachvollziehbar und innerhalb ihres zulässigen Rahmens durchgeführt wurden? Der hierfür einschlägige Rahmen wird dabei nicht (nur) durch die ACS-Hom-Anforderungen determiniert. Vielmehr treffen diese dann auf Normen des Strafsanktionsrechts, der Urheber-, Datenschschutz und Geschäftsgeheimnisschutzes. Erst im ausbalancierten Verhältnis der vorgenannten Normen mit den homologationsrechtlichen Anforderungen kann eine Antwort auf die Frage gefunden werden, wie man die Idee des LLM-basierten Pentestings praktisch umzusetzen vermag.
Was den hierfür erforderlichen Rahmen angeht: Für die Homologation über verschiedene Märkte hinweg gibt es darauf keine weltweit einheitliche Checkliste. Schon innerhalb des UNECE-Systems wenden Vertragsparteien nicht automatisch jede UN-Regelung an. Eine gemeinsame Testplattform kann dennoch einen stabilen Kern schaffen und die jeweils geltenden Anforderungen als überprüfbare Regeln und Nachweise abbilden.
Dazwischen liegt die eigentliche Arbeit. Eine normative Vorgabe oder ein Supplier-Vertrag sagt noch nicht, ob ein Agent jetzt, gegen dieses Steuergerät und mit diesen Parametern einen bestimmten Test ausführen darf.
Das Engagement schreibt den Handlungsrahmen fest
Ausgangspunkt jedes Testlaufs sollte deshalb ein freigegebenes Testing Engagement sein. Es beschreibt das Testobjekt einschließlich Softwareversion und Umgebung, die zulässigen Targets und Methoden, die Eingriffstiefe, zeitliche und technische Grenzen sowie den Umgang mit Daten. Ebenso hält es fest, auf welcher Befugnis der Test beruht und wer eine Erweiterung freigeben kann.
Diese Festschreibung ist mehr als ein Ticket mit dem Vermerk „Pentesting erlaubt“. Gerade bei Supplier-Software können Beobachtung und Test, Programmkopien, Bearbeitung oder Dekompilierung unterschiedlich zu beurteilen sein; das zeigen bereits die §§ 69c bis 69e UrhG. Auch eine Freigabe für ein Steuergerät umfasst nicht automatisch ein Supplier-Backend, Systeme von Unterlieferanten oder die Übermittlung vertraulicher Artefakte an einen externen KI-Dienst.
Hier liegt zugleich die mögliche Erlaubniswirkung gegenüber Suppliern: Soweit die zuständigen Parteien einen konkreten Testumfang wirksam vereinbart oder freigegeben haben, kann das Engagement diese Befugnis eindeutig dokumentieren. Der Plattformdatensatz erteilt selbst keine Rechte. Er sorgt allerdings dafür, dass sich die tatsächlich erteilte Erlaubnis in den ausführbaren Aktionen wiederfindet. Wird der Scope erweitert, braucht auch die Freigabe eine erneute Prüfung.
Aus der Freigabe wird eine Laufzeitentscheidung
Ein Agent auf Basis eines großen Sprachmodells kann Hypothesen entwickeln, Tests planen und den nächsten sinnvollen Schritt vorschlagen. Ob er ihn ausführen darf, entscheidet eine Kontrollschicht außerhalb des Modells.
Dafür werden Testhandlungen typischer Weise in einer gemeinsamen Capability Matrix beschrieben. Diese Capability_matrix definiert dann, was bei welchem Target, in welcher Umgebung und mit welcher Wirkung zulässig ist. Die daraus abgeleiteten Plattformregeln beantworten einen konkreten Toolaufruf sodann mit ALLOW, DENY oder STEP-UP – also Ausführen, Sperren oder zusätzliche Freigabe einholen.
Nun aber zurück zu unserem ursprünglichen Beispiel: Begrenzte Diagnoseaufrufe am freigegebenen Steuergerät können erlaubt sein. Das Schreiben in den Speicher kann gesperrt sein. Der Wechsel zu einem Backend auf der anderen Seite löst aber mindestens eine neue Scope- und Berechtigungsprüfung aus. Der Agent kann diesen Wechsel zwar vorschlagen; seine eigene Einschätzung erweitert den Auftrag aber eben nicht automatisch.
Dies ist letztlich die technisierte Implementierung von Governance: Fachliche und rechtliche Entscheidungen werden zunächst von Menschen getroffen und anschließend als Regeln im Ausführungspfad wirksam. Die KI dageben bleibt für Analyse und Anpassung flexibel einsetzbar. Ihre Werkzeuge allerdings bleiben an den freigegebenen Rahmen gebunden.
Der Scope umfasst auch Informationen
Ein weiterer interessanter Punkt: Bei KI-gestützten Tests endet die Governance nicht an der Netzwerkschnittstelle. Supplier-Dokumentation, Quellcode, Tickets, Logs und frühere Findings können für einen Test wertvoll sein. Sie können aber zugleich auch vertrauliche oder personenbezogene Informationen enthalten. Das Engagement muss also festlegen, welche Daten ein Agent sehen darf, welches Modell sie verarbeiten darf und ob eine externe Verarbeitung überhaupt freigegeben ist. Bei personenbezogenen Daten kommen noch die Anforderungen der DSGVO hinzu.
Hinzu kommt ein technisches Problem: Ein Dokument kann Anweisungen enthalten, die ein Sprachmodell fehlleiten sollen (sog. AI-Prompt Injection). Solche Inhalte sind mithin Testdaten und keine Befehle an den Agenten. OWASP beschreibt Prompt Injection und zu weitreichende Agentenrechte als eigenständige Risiken. Datenklassifizierung, begrenzte Toolrechte und eine vom Modell unabhängige Freigabeentscheidung gehören deshalb zusammen.
Schließlich muss die Plattform den Ablauf rekonstruierbar halten: Welches Engagement galt? Welche Information führte zu welcher Testhypothese? Welche Aktion wurde beantragt, erlaubt und tatsächlich ausgeführt? So entsteht neben dem Finding auch ein belastbarer Nachweis über seinen Entstehungsweg.
Auf dem Weg zu einer gemeinsamen Sprache
Eine KI-Validierungs- oder Pentesting-Plattform beginnt nicht mit einem allmächtigen Pentesting-Agenten. Sie beginnt mit einer Capability Matrix, an der Cybersecurity, Engineering, Supplier Management, Datenschutz und Legal beziehungsweise Homologation gemeinsam arbeiten. Für Analyse, Fuzzing, Exploit-Verifikation, Zugriff auf weitere Systeme und Nutzung externer Modelle muss jeweils klar sein, welche Befugnis, Grenze und Freigabe gilt.
Nicht jede normative Frage lässt sich mit technischen Mittel abbilden oder automatisieren. Eine geklärte Entscheidung in normativen Sinne lässt sich aber technisch durchsetzen und später belegen. Genau darin liegt der Gewinn einer Plattform, auf der entsprechende Engagements nach festehenden Rahmenbedingungen definiert werden: Mehr adaptive Testintelligenz wird möglich, weil der erlaubte Handlungsrahmen vor dem Test feststeht, während des Tests gilt und danach nachvollziehbar bleibt.
