Von Intelligenz zu Handlungsvollmacht

Künstliche Intelligenz beschränkt sich nicht mehr darauf, Fragen zu beantworten und Inhalte zu erstellen. KI-Systeme können zunehmend Anweisungen auslegen, Pläne entwickeln, Werkzeuge auswählen und Aufgaben ohne fortlaufende menschliche Anleitung ausführen.

Dieser Unterschied ist entscheidend.

Ein KI-System, das Handlungen empfiehlt, unterscheidet sich von einem, das befugt ist, sie auszuführen. Der Unterschied liegt nicht unbedingt in der Intelligenz oder Leistungsfähigkeit. Er liegt in der Handlungsvollmacht.

Autonome Systeme beschränken sich nicht auf führende große Sprachmodelle. Dazu zählen spezialisierte Systeme des maschinellen Lernens, Robotik, autonome Fahrzeuge, Softwareagenten und Kombinationen verschiedener Technologien, die innerhalb festgelegter Betriebsbedingungen selbstständig Entscheidungen treffen oder Handlungen ausführen.

Ihr potenzieller Nutzen ist beträchtlich. Sie können die wissenschaftliche Forschung, industrielle Abläufe, das Gesundheitswesen, die Softwareentwicklung und die Cybersicherheit unterstützen. Sie können aber auch unbeabsichtigte Folgen haben, sensible Informationen offenlegen oder Handlungen auslösen, die über die Absichten ihrer Betreiber hinausgehen.

In Sicherheitsherausforderungen beim Entwurf autonomer Systeme untersuchen Mohammad Hamad und Sebastian Steinhorst Sicherheitsherausforderungen im Zusammenhang mit der autonomen Reaktion auf Vorfälle, der Risikobewertung, der Zugriffskontrolle, der Vertrauenswürdigkeit von Daten und dem Zusammenspiel autonomer Systeme. Ihre Forschung, die sich zu großen Teilen mit cyberphysischen Systemen befasst, zeigt, dass die Herausforderungen beim Absichern selbstständigen maschinellen Handelns über die heutigen LLM-Agenten hinausgehen.

Die weiterreichenden Folgen der Autonomie müssen ernsthaft untersucht werden, einschließlich möglicher körperlicher Schäden. Belege müssen jedoch sorgfältig ausgewertet werden. Vorfälle mit automatisierten Fahrzeugen lassen sich beispielsweise nicht automatisch denselben Mechanismen zuschreiben, die autonome Cybersicherheitsagenten betreffen. Entscheidend sind der Grad der Autonomie, die Betriebsbedingungen, die menschliche Beteiligung und die Beweislage hinsichtlich der Ursache.

Ebenso belegt der Nachweis, dass autonome KI Schaden verursachen kann, nicht, dass die Governance zwangsläufig hinterherhinkt. Wir sollten auch nicht davon ausgehen, dass autonome Systeme grundsätzlich schwer abzusichern sind.

Die zentrale Frage ist nicht, ob KI komplexe Aufgaben ausführen kann, sondern ob die architektonischen, sicherheitstechnischen und organisatorischen Rahmenbedingungen für autonome Systeme angemessene Grenzen für übertragene Handlungsvollmachten festlegen und überprüfbare Nachweise dafür liefern können, dass diese Grenzen eingehalten werden.

Die Cybersicherheit bietet eine besonders hilfreiche Perspektive auf diese Frage, denn Sicherheitsexperten hinterfragen seit Jahrzehnten Annahmen zu Vertrauen, Berechtigungen, Zugriffen und Systemverhalten.

Das Katz-und-Maus-Spiel im Maschinentempo

Cybersicherheit wird seit Langem als Katz-und-Maus-Spiel beschrieben.

Angreifer entdecken Schwachstellen, Verteidiger führen Schutzmaßnahmen ein, und beide Seiten passen sich an. Dieser Kreislauf setzt sich fort, während sich Technologien, Taktiken und Betriebsumgebungen verändern.

Autonome KI ändert nicht unbedingt die grundlegenden Spielregeln. Sie kann verändern, wer – oder was – mitspielt, wie schnell gehandelt wird und wie viel Arbeit ohne fortlaufendes menschliches Eingreifen erledigt werden kann.

Ein autonomes System für offensive Sicherheitsprüfungen könnte exponierte Dienste aufspüren, Schwachstellen untersuchen, mögliche Angriffspfade entwickeln und testen, ob sich diese ausnutzen lassen. Ein defensives System könnte ähnliche Fähigkeiten einsetzen, um Bedrohungen zu untersuchen, Schwachstellen zu erkennen und Abhilfemaßnahmen zu überprüfen.

Dieses Potenzial zur doppelten Nutzung ist entscheidend für das Verständnis der sicherheitlichen Auswirkungen autonomer KI.

Anthropics Project Glasswing ist ein Beispiel für KI-gestützte Schwachstellensuche. In seinem Forschungsupdate vom Mai 2026 berichtete Anthropic von umfangreichen Ergebnissen bei der Entdeckung von Schwachstellen und betonte zugleich die praktischen Herausforderungen bei deren Überprüfung, Offenlegung und Behebung durch Patches.

Dieser Unterschied ist entscheidend. Eine Schwachstelle zu entdecken ist nicht dasselbe, wie zu bestätigen, dass sie ausgenutzt werden kann, sie zu beheben oder nachzuweisen, dass das betroffene System sicher ist.

Mehr Erkenntnisse können die Übersicht verbessern und gleichzeitig die Anforderungen an die Menschen und Prozesse erhöhen, die für die Behebung der gefundenen Probleme zuständig sind.

Für das Sicherheitsergebnis kommt es darauf an, was als Nächstes geschieht.

Wenn Angreifer und Verteidiger Teile ihrer Arbeit automatisieren können, lautet die entscheidende Frage nicht einfach, welche Seite über das leistungsfähigste Modell verfügt. Entscheidend ist, ob die Verteidiger Entdeckungen in wirksame Abhilfemaßnahmen umsetzen und die Ergebnisse unabhängig überprüfen können.

Klassische Penetrationstests werden nicht überflüssig, nur weil KI offensive Aufgaben ausführen kann. Ihr Umfang muss Systeme einschließen, die Anweisungen auslegen, Werkzeuge aufrufen, Berechtigungen kombinieren und über mehrere Schritte hinweg Ziele verfolgen.

Das Ziel bleibt vertraut: Schwachstellen finden, ihre Bedeutung feststellen, sie beheben und nachweisen, dass die Schutzmaßnahmen funktionieren.

Architektonische Nahtstellen: Wo Sicherheitsgrenzen aufeinandertreffen

Eines der subtileren Risiken autonomer Systeme entsteht, wenn einzeln autorisierte Komponenten so zusammenwirken, dass unbeabsichtigte Folgen entstehen.

Ich bezeichne solche Schnittstellenpunkte als architektonische Nahtstellen.

Betrachten wir ein herkömmliches Beispiel. Eine Organisation beschränkt den Zugriff auf eine Datei mithilfe von NTFS-Berechtigungen. Ein separater Cloud-Freigabedienst ermöglicht es einem autorisierten Benutzer, diese Informationen extern zu teilen.

Jedes System kann nach seinen eigenen Regeln funktionieren. Ihr Zusammenspiel kann jedoch dazu führen, dass Informationen auf eine Weise geteilt werden, die die von der Organisation beabsichtigte Sicherheitsgrenze verletzt.

Dies veranschaulicht potenziell widersprüchliche Richtlinien und ist keine Behauptung, dass ein bestimmtes Produkt zur Dateifreigabe Sicherheitslücken aufweist.

Das Problem muss nicht in einem einzelnen der beiden Kontrollmechanismen liegen. Es kann vielmehr daran liegen, dass die beabsichtigte Sicherheitsrichtlinie nicht über den gesamten Arbeitsablauf hinweg durchgesetzt wird.

Ähnliche Situationen können bei autonomer KI auftreten, wenn Modelle, Anwendungen, Identitäten, Tools, Repositories und externe Dienste miteinander verbunden werden.

Ein Agent kann die Berechtigung haben, ein Dokument zu lesen, ein Repository anzulegen und Dateien hochzuladen. Daraus folgt nicht zwangsläufig, dass er befugt ist, diese Vorgänge so zu kombinieren, dass vertrauliche Informationen offengelegt werden.

Die Forschung liefert einen praktischen Grund, diese Wechselwirkungen genauer zu untersuchen.

In AgentDojo untersuchten Forschende Prompt-Injection-Angriffe auf KI-Agenten, die Tools verwenden. Dabei prüften sie 97 realitätsnahe Aufgaben und 629 Sicherheitstestfälle. Ihre Ergebnisse zeigten, dass bösartige Anweisungen, die über nicht vertrauenswürdige Tool-Ausgaben eingeschleust wurden, bestimmte Sicherheitseigenschaften beeinträchtigen konnten. Allerdings waren weder die Angriffe noch die Agenten durchweg erfolgreich.

Aus der Forschung geht nicht hervor, wie häufig solche Angriffe in Produktionsumgebungen erfolgreich sind. Sie zeigt jedoch, warum es nicht ausreicht, ausschließlich die Antworten eines Modells zu bewerten, um das Verhalten eines mit Tools verbundenen Systems zu verstehen.

Ein verwandtes Risiko wird mitunter als Berechtigungswäsche bezeichnet: Eine Handlung erscheint legitim, weil sie über ein autorisiertes Tool oder einen Vermittler ausgeführt wird, obwohl das daraus entstehende Gesamtverhalten die beabsichtigte Berechtigungsgrenze verletzt.

Wenn mehrere Agenten zusammenarbeiten, müssen diese Beziehungen durch ausdrückliche Regeln für die Beteiligung, den Informationsaustausch und zulässige Handlungen geregelt werden.

Auch die Zuständigkeiten müssen über die gesamte Architektur hinweg festgelegt werden.

Modellanbieter, Plattformbetreiber, Agentenentwickler und einsetzende Organisationen können jeweils unterschiedliche Teile des Systems kontrollieren. Ein zweckmäßiges Modell gemeinsamer Verantwortung legt fest, wer welche Grenze kontrolliert, wer Ausnahmen genehmigen kann, wer die Ausführung überwacht und wer reagiert, wenn etwas schiefgeht.

Autonomie hebt Verantwortung nicht auf. Sie macht es umso wichtiger zu wissen, wo diese Verantwortung liegt.

Offensive Gründlichkeit: Prüfen, was wir zu wissen glauben

Damit kommen wir zu einem Konzept, das ich als offensive Gründlichkeit bezeichne.

Offensive Gründlichkeit ist ein disziplinierter Ansatz für adversative Tests, kritisches Hinterfragen und evidenzbasierte Validierung, der Sicherheitsannahmen auf den Prüfstand stellt. Dabei wird untersucht, wie sich Systeme unter realistischen Bedingungen verhalten, anstatt sich ausschließlich auf Architekturentwürfe, dokumentierte Kontrollen oder vermeintliche Schutzmaßnahmen zu verlassen.

Die zugrunde liegenden Verfahren sind etabliert. Penetrationstests, Bedrohungsmodellierung, Red Teaming und Sicherheitsvalidierung stellen defensive Annahmen seit Langem infrage.

Offensive Gründlichkeit verbindet diese Verfahren anhand einer zentralen Frage:

Welche Belege zeigen, dass die beabsichtigte Sicherheitsgrenze hält?

Eine Organisation kann Richtlinien zum Schutz sensibler Informationen haben, ein Modell so konfigurieren, dass es unzulässige Anfragen ablehnt, und einen Agenten mit eingeschränkten Berechtigungen einsetzen.

Das sind sinnvolle Schutzmaßnahmen. Ihr bloßes Vorhandensein belegt jedoch nicht, dass sich das Gesamtsystem unter adversativen Bedingungen sicher verhält.

Ein Modell könnte eine bösartige Anweisung ablehnen, während ein autorisiertes Tool dennoch eine unbeabsichtigte Handlung ermöglicht. Eine Richtlinie könnte korrekt erscheinen, während das Zusammenspiel der Systeme einen unerwarteten Weg eröffnet, sie zu umgehen.

Manchmal nenne ich das eine „Leitplankenillusion“: Man verwechselt das Vorhandensein von Leitplanken mit dem Beleg dafür, dass das System die Grenze, die sie schützen sollen, nicht überschreiten kann.

Leitplanken sind nützlich. Ihre Wirksamkeit muss dennoch nachgewiesen werden.

Betrachten wir einen autonomen Agenten, der einen vermuteten Sicherheitsvorfall untersuchen darf. Er kann Protokolle abrufen, Benutzeraktivitäten prüfen und Maßnahmen zur Eindämmung empfehlen.

Im Rahmen eines autorisierten Sicherheitstests schleust ein Angreifer irreführende Anweisungen in Informationen ein, die der Agent voraussichtlich verarbeitet.

Der Test sollte sich nicht darauf beschränken festzustellen, ob der Agent diesen Anweisungen gefolgt ist.

Untersucht werden sollte, ob der Agent eine unzulässige Handlung versucht hat, ob unabhängige Kontrollen die Ausführung verhindert haben, ob der Versuch protokolliert wurde und ob sich das System angemessen davon erholt hat.

Offensive Gründlichkeit verbindet fünf Aktivitäten:

1. Die Annahme festlegen: Bestimmen, welche Sicherheitseigenschaft die Architektur voraussichtlich gewährleisten soll.
2. Die Annahme hinterfragen: Realistische Angriffswege, manipulierte Eingaben und Kombinationen legitimer Fähigkeiten testen.
3. Belege sammeln: Ermitteln, was das System versucht hat, was ausgeführt wurde und welche Kontrollen gegriffen haben.
4. Die Schwachstelle beheben: Das Modell, den Arbeitsablauf, die Berechtigungen, die Architektur oder den Betriebsprozess korrigieren, der für das Versagen verantwortlich ist.
5. Die Korrektur überprüfen: Den relevanten Angriffsweg erneut testen und bestätigen, dass die vorgesehene Sicherheitseigenschaft gewährleistet ist.

Darin liegt der Unterschied zwischen dem Testen der Reaktion eines Modells und dem Testen der Sicherheit des Gesamtsystems.

Außerdem muss untersucht werden, was nach einem ersten Zugang geschieht. Ein Angreifer kann versuchen, Zugangsdaten zu sammeln, seine Berechtigungen auszuweiten, sich dauerhaft einzunisten oder sich lateral im Netzwerk auszubreiten, indem er bereits in einer Umgebung verfügbare Fähigkeiten missbraucht.

Dass ein Werkzeug legitim ist, bedeutet nicht, dass jede Verwendung dieses Werkzeugs legitim ist.

Offensive Gründlichkeit soll nicht voraussetzen, dass autonome Systeme unsicher sind. Vielmehr soll durch Tests festgestellt werden, wo ihre Sicherheitsgrenzen Bestand haben.

Bedingte Autonomie: Intelligenz und Befugnisse voneinander trennen

Eine architektonische Maßnahme besteht darin, zu unterscheiden, was ein KI-System tun kann und wozu es befugt ist.

Ich bezeichne diesen Ansatz als bedingte Autonomie.

Bedingte Autonomie trägt dem Umstand Rechnung, dass der angemessene Grad an Selbstständigkeit von der Aufgabe, der Betriebsumgebung, den möglichen Folgen, der Unsicherheit und den verfügbaren Belegen abhängt, mit denen sich eine Handlung rechtfertigen lässt.

Ein Agent, der öffentliche Informationen zusammenfasst, benötigt nicht unbedingt dieselbe Aufsicht wie ein Agent, der Konten deaktivieren, Firewall-Regeln ändern oder Produktionsinfrastruktur anpassen darf.

Für Letzteren können ausdrückliche Einsatzregeln, unabhängig durchgesetzte Berechtigungen, strengere Autorisierung und eine menschliche Genehmigung folgenreicher Handlungen erforderlich sein.

Diese Grenzen sollten sich nicht allein deshalb erweitern, weil ein Agent zu dem Schluss kommt, dass weitergehender Zugriff die Erreichung seines Ziels erleichtern würde.

Ein Agent kann überdenken, wie er eine autorisierte Aufgabe ausführt, ohne zusätzliche Befugnisse zu erhalten.

Die OWASP Top 10 für LLM-Anwendungen behandelt dieses Problem in der Kategorie LLM06:2025 Übermäßige Autonomie. OWASP nennt übermäßige Funktionalität, Berechtigungen und Autonomie als Risikofaktoren und empfiehlt, Fähigkeiten einzuschränken und die Autorisierung unabhängig durchzusetzen.

Bedingte Autonomie wendet diese Grundsätze entsprechend dem Betriebsrisiko an.

Der Informationszugriff sollte auf das für eine Aufgabe Erforderliche beschränkt sein. Werkzeugberechtigungen sollten sich auf genehmigte Vorgänge beschränken. Ausführungskontingente, Ratenbegrenzungen, Genehmigungspflichten und Abbruchbedingungen können die Ausführung einschränken.

Diese Schutzmaßnahmen sind besonders wichtig bei autonomen offensiven Tests.

Ein Testagent kann bei der Verfolgung eines autorisierten Ziels berechtigterweise Zugangsdaten oder sensible Informationen entdecken. Die Entdeckung eines Zugangsschlüssels bedeutet jedoch nicht, dass das Modell dessen Klartextwert erhalten muss.

Eine Sicherheitsumgebung kann sensible Zugangsdaten vom Modell trennen und ihre Verwendung über eine unabhängig durchgesetzte Autorisierung vermitteln. Beispielsweise könnte ein Zugangsdaten-Broker ein Geheimnis direkt an einen genehmigten Dienst weitergeben, ohne es dem Modell unnötigerweise offenzulegen.

Dies entspricht den etablierten Grundsätzen der geringsten Berechtigung und der Aufgabentrennung.

Zudem wirft dies eine interessante Frage zur Architektur Bring Your Own Model (BYOM) oder Bring Your Own LLM (BYO-LLM) auf.

Welche Sicherheitsgarantien bleiben bestehen, wenn das zugrunde liegende Modell morgen ersetzt wird?

Die Autorisierung von Aufgaben, die Isolierung von Zugangsdaten, Bereichsbeschränkungen, Protokollierung und die Durchsetzung von Richtlinien können in der umgebenden Sicherheitsumgebung liegen, statt vollständig vom Verhalten des Modells abzuhängen.

Das bedeutet weder, dass die Sicherheitsumgebung automatisch sicher ist, noch, dass Modelle austauschbar sind. Verschiedene Modelle können Anweisungen unterschiedlich auslegen, Werkzeuge unterschiedlich aufrufen und unterschiedliche Fehlerarten verursachen.

Eine aussagekräftige Bewertung muss sowohl die Kontrollen testen, die unverändert bestehen bleiben sollen, als auch die Verhaltensweisen, die sich mit einem Modellwechsel ändern.

Vielleicht gehören einige der beständigsten Sicherheitseigenschaften zu jenen, die sich unabhängig durchsetzen lassen, selbst wenn sich die Komponente für die Verarbeitung von Informationen weiterentwickelt.

Wenn KI auf KI einwirkt: das Verifikationsproblem

Betrachten wir einen hypothetischen Arbeitsablauf im Sicherheitsbetrieb:

Untersuche diesen Vorfall, sammle die Belege, ermittle die betroffenen Identitäten, schlage Eindämmungsmaßnahmen vor, führe die genehmigten Maßnahmen aus und überprüfe das Ergebnis.

Ein Ermittlungsagent analysiert Telemetriedaten. Ein weiterer empfiehlt Maßnahmen zur Eindämmung. Ein autorisierter Ausführungsagent nimmt Änderungen vor. Ein Verifizierungsagent bewertet das Ergebnis.

Dies veranschaulicht eine autonome Incident Response mit geschlossenem Regelkreis, nicht ein dokumentiertes branchenweites Versagen.

Angenommen, der erste Agent identifiziert fälschlicherweise eine Identität als kompromittiert. Ein zweiter Agent übernimmt diese Schlussfolgerung und deaktiviert das Konto. Ein dritter bestätigt, dass das Konto deaktiviert wurde, und meldet den Erfolg.

Die ausgewählte Maßnahme wurde ausgeführt.

War die ursprüngliche Einschätzung jedoch richtig? War die Maßnahme autorisiert? Hat die Eindämmung der tatsächlichen Bedrohung entgegengewirkt? Hat sie unnötige Beeinträchtigungen verursacht?

Eine Verifizierung kann nicht allein darin bestehen, zu bestätigen, dass ein Agent die von ihm ausgewählte Maßnahme ausgeführt hat.

Auch wird das Ergebnis nicht automatisch unabhängig, wenn die Verifizierung einem anderen KI-Agenten übertragen wird.

Verschiedene Agenten können sich auf dieselben ungenauen Telemetriedaten, kompromittierten Informationen oder fehlerhaften Annahmen stützen. Ihre Übereinstimmung belegt die zugrunde liegenden Tatsachen nicht unabhängig.

Je schwerwiegender die Folgen einer autonomen Handlung sind, desto wichtiger ist eine Verifizierung, die unabhängig von dem System erfolgt, das die Entscheidung trifft.

Diese Unabhängigkeit kann durch separat beschaffte Belege, deterministische Richtlinienprüfungen, eingeschränkte Ausführungsumgebungen, eine menschliche Überprüfung oder eine Kombination von Schutzmaßnahmen gewährleistet werden.

Die geeigneten Kontrollen sollten in einem angemessenen Verhältnis zu den Folgen eines Fehlers stehen.

Maßnahmen mit geringen Auswirkungen, die sich rückgängig machen lassen, können sich für eine automatisierte Verifizierung eignen. Maßnahmen mit erheblichen Auswirkungen oder solche, die sich nur schwer rückgängig machen lassen, können eine strengere Autorisierung, eine unabhängige Bestätigung und eine ausdrückliche menschliche Genehmigung erfordern.

Vier Fragen helfen dabei, die relevanten Sicherheitseigenschaften voneinander abzugrenzen:

• Hat das System die beabsichtigte Aufgabe richtig interpretiert?
• Lag die Maßnahme innerhalb der ihm übertragenen Befugnisse?
• Blieb die Ausführung innerhalb der zulässigen Grenzen?
• Entsprach das erzielte Ergebnis dem angestrebten Sicherheitsziel?

Diese Fragen hängen zusammen, sind aber nicht austauschbar.

Ein Agent kann eine autorisierte Maßnahme ausführen, die zu einem unbeabsichtigten Ergebnis führt. Ebenso kann er durch eine nicht autorisierte Maßnahme ein scheinbar vorteilhaftes Ergebnis erzielen.

Keines von beidem sollte automatisch als erfolgreicher Schutz gewertet werden.

Mit den zunehmenden Fähigkeiten autonomer Systeme besteht die Herausforderung nicht einfach darin, sie komplexe Arbeitsabläufe abschließen zu lassen. Vielmehr muss hinreichend belegt werden, dass ihre Handlungen weiterhin autorisiert, angemessen und korrekt sind.

Dazu gehört auch zu wissen, wann das System anhalten, den Fall eskalieren, eine Maßnahme rückgängig machen oder ein begrenztes und ausdrücklich verstandenes Risiko akzeptieren sollte.

Vertrauen muss sich an Belegen orientieren

Die Auswirkungen autonomer KI auf die Sicherheit sind nicht ausschließlich negativ.

Autonome Systeme können Verteidigern dabei helfen, Schwachstellen aufzudecken, Bedrohungen zu untersuchen und Validierungsaufgaben auszuführen, die andernfalls erhebliche menschliche Ressourcen beanspruchen würden.

Bessere Modelle, stärkere externe Kontrollen und ausgereiftere Betriebspraktiken können einige der mit übertragenen Befugnissen verbundenen Risiken mindern.

Es wäre daher verfrüht, zu dem Schluss zu kommen, dass autonome KI grundsätzlich unsicher ist oder dass die Governance mit ihrer Entwicklung nicht Schritt halten kann.

Gegen die Annahme, autonome KI erfordere grundlegend neue Sicherheitsprinzipien, spricht zudem ein ernst zu nehmendes Gegenargument.

Viele der zugrunde liegenden Probleme – übermäßige Berechtigungen, nicht vertrauenswürdige Eingaben, schwache Autorisierung, inkonsistente Durchsetzung von Richtlinien und unzureichende Verifizierung – werden seit Jahrzehnten untersucht.

Bewährte Kontrollen können bereits praktikable Lösungen bieten, wenn sie korrekt implementiert und getestet werden.

Autonomie kann das Tempo, den Umfang und die Komplexität ihrer Anwendung verändern. Sie setzt diese Kontrollen jedoch nicht automatisch außer Kraft.

Die Belege legen eine zielführendere Frage nahe: Unter welchen Bedingungen kann man autonomen Systemen die Ausübung übertragener Befugnisse anvertrauen, und wie weisen wir nach, dass diese Bedingungen erfüllt sind?

Die Antwort ergibt sich nicht allein aus den Fähigkeiten eines Modells.

Erforderlich sind architektonische Grenzen, klar zugewiesene Verantwortlichkeiten, unabhängig durchgesetzte Autorisierung, angemessene Aufsicht und Belege dafür, dass die Schutzmaßnahmen unter realistischen Bedingungen funktionieren.

Außerdem braucht es eine kohärente, aber anpassungsfähige Vorstellung von Sicherheit und Risiko.

Unsere grundlegenden Sicherheitsprinzipien müssen sich nicht mit jedem neuen Modell ändern. Doch unsere Annahmen darüber, wie diese Prinzipien anzuwenden sind, müssen kontinuierlich hinterfragt werden, wenn sich Fähigkeiten, Betriebsumgebungen und übertragene Befugnisse weiterentwickeln.

Das ist der Zweck von Offensive Rigor.

Nicht um zu beweisen, dass KI-Systeme versagen werden, sondern um herauszufinden, wo sie versagen können, die Folgen festzustellen und die Kontrollen zu überprüfen, die solche Ausfälle verhindern oder eindämmen sollen.

Der vielleicht nachhaltigere Vorteil besteht nicht einfach darin, ein leistungsfähigeres Modell auszuwählen, sondern eine Architektur zu schaffen, in der Modelle ausgetauscht werden können, ohne die Grenzen von Vertrauen, Befugnissen und Überprüfbarkeit zu gefährden.

Das Katz-und-Maus-Spiel geht weiter. Zunehmend könnten beide Seiten autonome Akteure einsetzen.

Entscheidend ist, sicherzustellen, dass unsere Fähigkeit, Schwachstellen zu finden, zu beheben und die Ergebnisse nachzuweisen, nicht im Wettlauf darum verloren geht, alles andere zu automatisieren.

Vertrauen muss sich auf Belege stützen.

Anmerkung des Autors: Die in diesem Artikel geäußerten Ansichten und Interpretationen sind meine eigenen und spiegeln nicht notwendigerweise die offiziellen Positionen, Richtlinien oder Produktfunktionen meines Arbeitgebers wider.