6 von 6 - Mit GenAI vorankommen
Wicus Ross
Senior Security Researcher
Einstieg
Teil 6 – dieser Blogbeitrag – ist der abschließende Beitrag unserer Reihe. Er befasst sich mit den besonderen Sicherheitsherausforderungen in Systemen, die Generative Künstliche Intelligenz (GenAI) als Teil ihrer Arbeitsabläufe einsetzen.
Die vorherigen Blogbeiträge dieser Serie finden Sie hier:
Teil 1: Rückblick auf das Kapitel über KI im Security Navigator 2025
Teil 2: Die potenziellen Auswirkungen von GenAI auf die Welt
Teil 3: Überblick darüber, wie Large Language Models (LLMs) funktionieren
Teil 4: Fortsetzung und Abschluss von Teil 3
Teil 5:Untersuchung von Agentic AI und den verschiedenen Komponenten dieses neuen Paradigmas
Jeder ist ein Programmierer
Am 17. Juni 2025 hielt Andrej Karpathy auf der Y Combinator AI Startup School in San Francisco eine Keynote, in der er erklärte, dass LLMs im Grunde eine neue Art von Betriebssystem (OS)1 darstellen.
Karpathy argumentiert, dass dieses neue Paradigma aus der Evolution von Software entstanden ist.
Ursprünglich wurden Programme in einer Programmiersprache oder in Computercode geschrieben und direkt auf einem Rechner ausgeführt – Karpathy bezeichnet dies als „Software 1.0“. Mit der Einführung neuronaler Netze kam die nächste Entwicklungsstufe: Gewichte werden trainiert und vom neuronalen Netz „ausgeführt“ – die Ära der „Software 2.0“ begann. Nun, so Karpathy, schreiben wir Programme in natürlicher Sprache in Form von Prompts, die von LLMs interpretiert werden, um Handlungen und Ergebnisse zu erzeugen. Diese Art, „Programme“ oder „Anweisungen“ zu erstellen, bedeutet, dass LLMs im Grunde wie ein Betriebssystem fungieren können.
Natürliche Sprache ist ein mächtiges und reichhaltiges Medium, um mit Maschinen über LLMs zu interagieren. Doch sie bringt auch Herausforderungen mit sich – insbesondere Mehrdeutigkeit und Fehlinterpretationen. Um die Absichten des Nutzers richtig zu verstehen und Erwartungen zu erfüllen, benötigt das LLM einen klaren Kontext. Menschen sind jedoch oft vage, manipulierend, unachtsam oder schlicht nachlässig in ihrer Ausdrucksweise.
Klassische Programmiersprachen – also das „Software 1.0“-Paradigma – folgen strengen Syntaxregeln, die durch Compiler oder Laufzeitumgebungen überprüft werden. Diese Regeln sorgen in der Regel für ein vorhersehbares Systemverhalten. Mit der Zeit hat sich gezeigt, dass defensive Programmierpraktiken notwendig sind, um Fehler oder Ausnutzungen zu verhindern.
LLMs hingegen, im „Software 3.0“-Paradigma, sind wesentlich weniger strikt. Die „Programme“, die sie ausführen, sind flexibel und oft unscharf definiert. Das kann – insbesondere in Kombination mit anderen unklaren Elementen – zu einer Vielzahl von Ergebnissen führen. Die nicht-deterministischen und stochastischen Eigenschaften neuronaler Netze sowie die Gewichtungen und Ausführungsparameter führen zu dem, was als „emergentes Verhalten“ bezeichnet wird.
George Dyson definiert dieses Phänomen folgendermaßen:
„Emergentes Verhalten ist jenes, das nicht vorhergesagt werden kann, wenn man das System auf einer einfacheren Ebene als der des Gesamtsystems analysiert. Emergentes Verhalten ist per Definition das, was übrig bleibt, nachdem alles andere erklärt wurde.“2
Dan Geer und Dave Aitel weisen auf die sicherheitstechnischen Herausforderungen hin, die dadurch entstehen:
„Aktuelle Cybersicherheitsrahmenwerke – wie das Secure Software Development Framework des National Institute of Standards and Technology oder die Richtlinien des Open Worldwide Application Security Project – basieren auf vorhersehbarem menschlichem Verhalten und klarer Verantwortlichkeit.
Diese Annahmen brechen unter dem Gewicht von KI-Geschwindigkeit, Intransparenz und Autonomie zusammen.“3
LLMs bilden die Grundlage des aktuellen Agentic-AI-Ökosystems. Wenn mehrere Agentic-AI-Dienste miteinander verknüpft werden, entsteht ein großes, komplexes System mit potenziell unvorhersehbaren Ergebnissen. Das liegt vor allem daran, dass LLMs natürliche Sprache gleichzeitig als „Anweisung“ und als „Daten“ verarbeiten. Die Vermischung dieser beiden Ebenen im gleichen Ausführungskontext verstärkt das emergente Verhalten.
Doch was passiert, wenn ein solches autonomes System unerwünschte Ergebnisse liefert?
Können Nutzer mit Entschädigung rechnen, und wer trägt die Verantwortung?
Sicher ist: böswillige Akteure werden versuchen, Schwachstellen in diesen Systemen zu finden und auszunutzen – oft auf Kosten anderer.
Heute kann nahezu jeder mit wenigen Worten ein Agentic-AI-System „programmieren“, das mehrere Aufgaben automatisiert übernimmt – Aufgaben, die früher erfahrenen Entwicklern vorbehalten waren.
Mit anderen Worten: Jeder ist jetzt ein Programmierer.
1 https://www.youtube.com/watch?v=LCEmiRjPEtQ
2 George Dyson, Darwin Among the Machines, Addison-Wesley, 1997
3 https://www.lawfaremedia.org/article/ai-and-secure-code-generation
Laufende Bestrebungen
Die Praktiken der sicheren Softwareentwicklung haben sich seit den frühen Tagen des Internets stark weiterentwickelt. Die Entwicklercommunity hat schnell erkannt, dass Generative KI großes Potenzial besitzt, zugleich aber Bereiche der Technologie definierte Best Practices und Gegenmaßnahmen erfordern, um die Auswirkungen böswilliger Nutzer zu begrenzen und unbeabsichtigte Nebenwirkungen zu vermeiden.
Community-Gruppen wie OWASP und die Cloud Security Alliance (CSA) gehörten zu den ersten, die Leitlinien zur Absicherung generativer KI-Anwendungen veröffentlicht haben. Hier ist eine (unvollständige) Auswahl prominenter Projekte, die Herausforderungen in diesem Bereich adressieren:
OWASP Top 10 for LLM Application 4
OWASP Securing Agentic Application Guide 1.0 5
OWASP Multi-Agentic system Threat Modelling Guide v1.0 6
OWASP Agentic AI – Threats and Mitigations 7
CSA Agentic AI Red Teaming Guide 8
CSA Agentic AI Identity & Access Management 9
CSA Secure Agentic System Design: A Trait-Based Approach 10
CAS Agentic AI Threat Modeling Framework: MAESTRO 11
MITRE ATLAS (Adversarial Threat Landscape for Artificial Intelligence Systems) 12
Die Zahl der Ressourcen wächst; einige behandeln sehr spezifische Elemente von Agentic-AI-Systemen, etwa Schwachstellen im Model Context Protocol (MCP) selbst. 13
Jede dieser Ressourcen bietet sinnvolle Leitlinien auf Basis der aktuellen Fähigkeiten von LLMs und ihrer Ökosysteme. Da sich LLMs rasant weiterentwickeln und starker Wettbewerb zusätzliche Investitionen anstößt, müssen die Autorenteams dieses Materials Schritt halten – sowohl mit der Bedrohungslage als auch mit den Modellfähigkeiten.
Diese Leitlinien und Best Practices beruhen auf einem gemeinsamen Verständnis darüber, wie Systeme funktionieren und welche Auswirkungen zu erwarten sind. Prüfen Sie sie gegenüber Ihrem konkreten Use Case und Ihren Implementierungen, um ein tragfähiges Gleichgewicht zwischen Risikominderung und Bedrohungserkennung zu finden.
4https://genai.owasp.org/llm-top-10/
5https://genai.owasp.org/resource/securing-agentic-applications-guide-1-0/
6https://genai.owasp.org/resource/multi-agentic-system-threat-modeling-guide-v1-0/
7https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
8https://csa-website-production.herokuapp.com/artifacts/agentic-ai-red-teaming-guide
9https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new- approach
10https://cloudsecurityalliance.org/artifacts/secure-agentic-system-design
11https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
12https://atlas.mitre.org/
13https://adversa.ai/mcp-security-top-25-mcp-vulnerabilities/
Threat modeling (Bedrohungsmodellierung)
Ein Sicherheitsmodell muss – einfach gesagt – Identität und zugehörige Berechtigungen, die Sensibilität der genutzten Daten, die Ausführungsumgebung, in der Operationen auf diesen Daten stattfinden, sowie die Sensibilität und den Speicherort der erzeugten Ausgaben berücksichtigen. Dieses Modell ist nicht vollständig, soll aber daran erinnern, dass beim Design und der Implementierung von Informationssystemen viele Aspekte zusammenspielen.
Die im vorherigen Abschnitt aufgeführten Ressourcen teilen zahlreiche überlappende Ideen und Konzepte. Zusammengenommen bieten sie eine solide Ausgangsbasis. Nachfolgend eine Zusammenfassung zentraler Sicherheitsthemen aus dem OWASP AI Multi-Agent Threat Model Guide:
Nicht vertrauenswürdige Eingaben sind gefährlich und müssen sorgfältig behandelt werden.
Vertrauensgrenzen sind dynamisch und erstrecken sich über mehrere Systeme.
Verhaltensweisen werden von selbstorganisierenden, heterogenen Komponenten ohne zentrale Kontrolle beeinflusst.
Informationsflüsse sind dynamisch.
Speicher und Lernen können eine Rolle bei zukünftigen, kontextabhängigen Interaktionen spielen.
Kontrollen sind notwendig aufgrund von:
Erweiterten Angriffsflächen
Vertrauen, Verzerrung und gegnerischer Manipulation
Koordinationsfehlern zwischen Agenten in dynamischen Umgebungen
„Attacker-in-the-middle“-Szenarien
Fehlender Nachvollziehbarkeit und Verantwortlichkeit bei Entscheidungen
Zunehmender Komplexität von Identitäts- und Zugriffssteuerungen
Das Dokument OWASP Agentic AI – Bedrohungen und Gegenmaßnahmen definiert 15 Bedrohungen im Rahmen der Agentic Security Initiative (ASI), mit passenden Gegenmaßnahmen, die den sieben Schichten des MAESTRO-Frameworks (Multi-Agent Security Threat Risk and Outcome) der CSA zugeordnet sind.
| MAESTRO-Schicht | OWASP ASI Threat ID |
|---|---|
| 1. Fundamentales Modell (Foundational Model) | T1 – Speichervergiftung (Memory poisoning) T7 – Fehlgeleitetes und täuschendes Verhalten (Misaligned and deceptive behavior) |
| 2. Datenverarbeitungsvorgänge (Data Operations) | T1 – Speichervergiftung (Memory poisoning) T12 – Vergiftung der Agentenkommunikation (Agent Communication poisoning) |
| 3. Agenten Frameworks (Agent Frameworks) | T2 – Missbrauch von Werkzeugen (Tool misuse) T6 – Absichtsverletzung und Zielmanipulation (Intent breaking and goal manipulation) T5 – Kaskadierende Halluzinationen (Cascading hallucinations) |
| 4. Bereitstellungsinfrastruktur (Deployment Infrastructure) | T3 – Rechtekompromittierung (Privilege compromise) T4 – Ressourcenüberlastung (Resource overload) T13 – Abtrünnige Agenten (Rogue agents) T14 – Menschlicher Angriff auf Multi-Agenten-Systeme (Human attack on multi-agent system) |
| 5. Evaluierung & Beobachtbarkeit (Evaluation & Observability) | T8 – Leugnung und Nichtnachverfolgbarkeit (Repudiation and untraceability) T10 – Überlastung des Menschen in der Schleife (Overwhelming human in the loop) |
| 6. Sicherheit & Compliance (Security & Compliance) | T3 – Rechte-Kompromittierung (Privilege compromise) T7 – Fehlgeleitetes und täuschendes Verhalten (Misaligned and deceptive behavior) |
| 7. Agenten-Ökosystem (Agent Ecosystem) | T9 – Identitätsspoofing (Identity spoofing) T13 – Abtrünnige Agenten (Rogue agents) T14 – Menschliche Angriffe auf Multi-Agenten-Systeme (Human attacks on multi-agent systems) T15 – Manipulation des menschlichen Vertrauens (Human trust manipulation) |
Das MAESTRO-Framework ist flexibler und geht über die ASI-Bedrohungszuordnungen hinaus. Die schichtübergreifende Abbildung verdeutlicht ein zentrales Prinzip des Bedrohungsmodells für Agentic-AI-Systeme: Bedrohungen sind dynamisch und können sich erst mit der Zeit manifestieren – etwa durch schrittweisen Aufbau von Schwachstellen oder durch „Ansteckung“ über unsichere Komponenten.
Solche Szenarien werden als 'Cascading Trust Failures' bezeichnet – wenn ein einzelner Fehler eine Kette von Vertrauensbrüchen auslöst. Daher darf Vertrauen niemals implizit sein: Jede Interaktion zwischen Systemen muss im jeweiligen Kontext explizit verifiziert werden – insbesondere angesichts emergenter Verhaltensweisen.
| MAESTRO schichtübergreifende Bedrohung (MAESTRO Cross-layer Threat) | OWASP Bedrohungs-ID (OWASP Threat ID) |
|---|---|
| Kaskade von Datenlecks zwischen Agenten und Ziel-Fehlausrichtungen (Inter-agent data leakage cascade and goal misalignment cascades) | T1 – Speichervergiftung (Memory poisoning) T3 – Rechtekompromittierung (Privilege compromise) T12 – Vergiftung der Agentenkommunikation (Agent communication poisoning) |
| Rechtekompromittierung und laterale Bewegung (Privilege compromise and lateral movement) | T3 – Rechtekompromittierung (Privilege compromise) T14 – Menschliche Angriffe auf Multi-Agenten-Systeme (Human attacks on multi-agent system) |
| Ausnutzung von Planung und Reflexion (Planning and reflection exploitation) | T6 – Absichtsverletzung und Zielmanipulation (Intent breaking and goal manipulation) T7 – Fehlgeleitetes und täuschendes Verhalten (Misaligned and deceptive behaviors) |
| Lieferkettenangriffe (Supply Chain Attacks) | Kompromittierung einer Komponente (Bibliothek oder Modul) auf einer Ebene, um andere Ebenen zu beeinflussen |
Das MAESTRO-Framework beschreibt einen schrittweisen Ansatz zur Implementierung. Doch wie so oft steckt der Teufel im Detail: Jedes System hat seine Eigenheiten, die identifiziert werden müssen, und auf Unternehmensebene ist kaum etwas einfach. Auch die Liste der empfohlenen Gegenmaßnahmen bleibt bewusst allgemein – ihre konkrete Umsetzung hängt vollständig vom jeweiligen Anwendungsfall der Agenten ab.
Trait-basierter Ansatz
Die Bewertung dieser Ressourcen zeigt vor allem eines: Es gibt nicht den einen richtigen Weg, um ein Problem zu lösen.
Wie bei klassischen „Software 1.0“-Anwendungen müssen Umgebung und Implementierung stets im Kontext des jeweiligen Use Cases betrachtet und der Geltungsbereich klar definiert werden.
Das emergente Verhalten generativer KI stellt dabei eine besondere Herausforderung für bestehende, perimeterbasierte Sicherheitsmodelle und deterministische Annahmen klassischer Software dar.
Die Veröffentlichung der Cloud Security Alliance (CSA) mit dem Titel “Secure Agentic System Design: A Trait-Based Approach” geht dieses Problem an, indem sie bestehende Sicherheitsstandards und -methoden ergänzt, statt sie zu ersetzen.
Dieser Ansatz ist sinnvoll, da er folgende Vorteile bietet:
Verbesserte Entscheidungsfindung durch ein transparentes mentales Modell
Proaktives Risikomanagement
Skalierbarkeit und Anpassungsfähigkeit
Flexibleres Sicherheitsdesign
Förderung modularen Denkens, ohne Wiederverwendung zu erzwingen
Vereinfachte Bedrohungsmodellierung und Sicherheitsprüfungen
Die sogenannten Traits sind in sieben Kategorien unterteilt:
1. Kontrolle und Orchestrierung
Wie Aktionen zentralisiert oder dezentral verwaltet werden.
2. Interaktion und Kommunikation
Direkter oder indirekter Informationsaustausch zwischen Agenten.
3. Planung
Reaktive oder planbasierte Entscheidungsfindung der Agenten und die Herkunft dieser Entscheidungen.
4. Wahrnehmung und Kontext
Begrenzte, kontextuelle oder absichtsbasierte Interpretation auf Grundlage der Umgebung eines Agenten.
5. Lernen und Wissensaustausch
Lokale oder globale Verbesserung der Fähigkeiten eines Agenten.
6. Vertrauen
Wird Vertrauen explizit definiert oder angenommen, und wie wird es durchgesetzt?
7. Werkzeugnutzung
Gelenkte oder beaufsichtigte Nutzung von Tools.
Diese Maßnahmen ergänzen bestehende Cybersicherheits-Frameworks und helfen, eine widerstandsfähige und vertrauenswürdige Umgebung zu schaffen, indem sie:
Best Practices für Sicherheitsarchitektur über das gesamte System hinweg etablieren,
häufige Schwachstellen und bekannte Angriffsvektoren beseitigen, die als Vorbedingungen oder Verstärker spezifischer Angriffe dienen,
eine Defense-in-Depth-Strategie durch spezifische Maßnahmen aus der trait-basierten Analyse ergänzen.
Darüber hinaus muss das Prinzip der minimalen Berechtigung konsequent im gesamten System umgesetzt werden. Transparenz und Nachvollziehbarkeit von Entscheidungen, ebenso wie Erklärbarkeit, sind entscheidend für effektive Incident Response und System-Triage. Eingabevalidierung und -bereinigung bleiben essenziell, um umfassenden Schutz zu gewährleisten.
Ressourcenüberwachung und Begrenzung der Agentenaktivitäten sind wichtig, um Anomalien oder Missbrauch frühzeitig zu erkennen. Ebenso bleiben Anomalieerkennung und Verhaltensüberwachung zentrale Bestandteile jedes modernen Systems.
Schritt-für-Schritt-Ansatz für eine trait-basierte Sicherheitsanalyse
Die trait-basierte Sicherheitsanalyse ist ein iterativer Prozess, der es Systemdesignern und Implementierern ermöglicht, Anforderungen und den anfänglichen Geltungsbereich zu bestimmen, indem Fragen gestellt werden wie:
Was ist der Zweck des Systems?
Welche Kernfunktionen besitzt es?
Wer sind die Stakeholder und Nutzer des Systems?
Welche betrieblichen Einschränkungen bestehen?
Wie sensibel sind die Daten, und welche Datenschutzaspekte müssen berücksichtigt werden?
Was sind die übergeordneten Sicherheitsziele?
Welche Fail-Safe-Mechanismen müssen vorhanden sein?
Als Nächstes müssen die wichtigsten agentischen Traits und ihre Muster identifiziert werden. Dazu werden passende Traits aus den sieben Kategorien ausgewählt.
Sobald Traits und Muster identifiziert sind, werden die Interaktionen analysiert und die damit verbundenen Risiken bewertet. Jedes Muster und jeder Trait ist mit bekannten Risiken verknüpft, die dem jeweiligen Merkmal zugeordnet sind. Interaktionen, die Systemgrenzen überschreiten und andere Traits beeinflussen, werden ebenfalls hervorgehoben.
Nach Abschluss dieser Aufgabe werden Gegenmaßnahmen entworfen und implementiert. Jedes Trait-Muster verfügt über eine Liste bekannter Risiken und geeigneter Maßnahmen. Risiken müssen anhand ihrer Eintrittswahrscheinlichkeit und ihres potenziellen Einflusses auf das untersuchte System priorisiert werden.
Abschließend folgt die Phase „Überwachen, Bewerten und Anpassen“, in der Bereiche identifiziert werden, die verbessert oder korrigiert werden müssen. Dieser Schritt schließt den Feedback-Zyklus und ermöglicht es, die Sicherheitslage kontinuierlich zu optimieren. Dies erfordert regelmäßige Überprüfungen und Analysen des Systems.
Trait-basierte Sicherheitsanalyse und Threat modeling (Bedrohungsmodellierung)
Die trait-basierte Analyse eignet sich gut zur Zusammenarbeit mit bestehenden Sicherheitspraktiken, Softwareentwicklungslebenszyklen usw., einschließlich der Bedrohungsmodellierung. Es ist möglich, das MAESTRO-Framework und die trait-basierten Kategorien zuzuordnen, um eine Systemzerlegung der agentischen Traits im Hinblick auf potenzielle Bedrohungen für ein bestimmtes System durchzuführen. Das folgende Beispiel stammt aus dem im Abschnitt „Efforts afoot“ erwähnten Dokument CSA Secure Agentic System Design: A Trait-Based Approach:
| Trait-Kategorie | Relevante MAESTRO-Schichten |
|---|---|
| Control & Orchestration | Layer 3 (Agent Frameworks), Layer 4 (Deployment) |
| Interaction & Communication | Layer 7 (Agent Ecosystem), Layer 5 (Evaluation & Observability) |
| Planning | Layer 1 (Foundation Models), Layer 3 (Agent Frameworks) |
| Perception & Context | Layer 2 (Data Operations), Layer 5 (Evaluation & Observability) |
| Learning & Knowledge Sharing | Layer 1 (Foundation Models), Layer 2 (Data Operations) |
| Trust | Layer 6 (Security & Compliance), Layer 7 (Agent Ecosystem) |
Diese Zuordnung kann auch nützlich sein, wenn andere Tools wie die MITRE-ATLAS-Matrix verwendet werden, um spezifische Taktiken für eine bestimmte Trait-Kategorie zu identifizieren.
Zum Beispiel könnte „Decentralized Control“, das unter die Kategorie Control & Orchestration fällt, mit den MITRE-ATLAS-Taktiken „Takeover Attacks“ oder „Policy Bypassing“ verknüpft werden.
Der Abschnitt „Traits and Patterns“ wurde hier nicht im Detail behandelt und könnte leicht einen eigenen Blogbeitrag füllen. Dieser Abschnitt beschreibt Risiken, die sowohl von außerhalb des Systems stammen können, als auch Risiken, die durch Design- oder Implementierungsfehler entstehen.
Agentic AI und Identität
Authentifizierung (Authn) und Autorisierung (Authz) sind grundlegende Sicherheitsbausteine der Cybersicherheit. Die Fähigkeit, jemanden oder etwas zu identifizieren (Authn), ermöglicht es, ein gewisses Maß an Vertrauen aufzubauen und Berechtigungen (Authz) für den Zugriff auf bestimmte Ressourcen zu erteilen. Eine eindeutige Identität ist entscheidend, um Zero-Trust-Prinzipien umzusetzen.
Die OAuth-2.0-Spezifikation gilt als empfohlene Best Practice für Multi-Context-Protocol-(MCP)-Server.¹⁴ Diese Vorgabe ist für einfache Endnutzerinteraktionen zwischen Client- und Server-Schnittstellen geeignet. Sie deckt jedoch keine Anwendungsfälle ab, bei denen ein MCP-Server mit einem anderen Agenten interagieren muss. Wie authentifiziert sich dieser erste MCP-Server gegenüber den nachgelagerten MCP-Servern? Wessen Identität wird dabei verwendet? Und werden die Anmeldeinformationen der Nutzer an die nachgelagerten Server weitergegeben?
Dienstkonten oder nicht-menschliche Identitäten (Non-Human Identities, NHI) werden Diensten zugewiesen, die bestimmte Berechtigungen benötigen. Eine NHI eines Dienstes wird entweder vom Konto abgeleitet, das den Dienst installiert hat, oder explizit erstellt. Die Publikation CSA Agentic AI Identity & Access Management hebt mehrere Schwachstellen der derzeitigen Ansätze hervor. OAuth-2.0-Zugangsdaten können von NHIs zur Authentifizierung bei APIs verwendet werden, allerdings fehlt dabei das Bewusstsein für das Verhalten und die Integrität der Sitzung. Ersatzschlüssel oder Zertifikate können ebenfalls als Authentifizierungsmaterial dienen, doch ihnen fehlt die Echtzeit-Verhaltensüberprüfung, und sie erfordern zusätzliche Erweiterungen – insbesondere in dynamischen Umgebungen. Außerdem kann rollenbasierte Zugriffskontrolle (RBAC), die an menschliche Konten gebunden ist, leicht missbraucht werden, da sie häufig zu weitreichende Berechtigungen gewährt und in der Regel statisch bleibt.
Das bestehende Identity- und Access-Management (IAM) muss sich an die besonderen Anforderungen von Agentic AI anpassen. Die CSA betont die Notwendigkeit von NHIs in Agentic-AI-Systemen aus folgenden Gründen:
Emergentes Verhalten von LLMs führt zu unvorhersehbarem Verhalten autonomer Systeme.
Kurzlebigkeit und dynamische Lebenszyklen in flexiblen Umgebungen, insbesondere durch den Einsatz von Tools.
Neue und sich weiterentwickelnde Fähigkeiten mit unkontrollierter Absicht.
Die Notwendigkeit überprüfbarer Herkunft und Verantwortlichkeit, wenn Systeme Entscheidungen treffen, die Auswirkungen auf Kunden haben.
Das Risiko autonomer Rechteausweitung, das durch Design verhindert werden muss.
Übermäßig weitreichende Zugriffsrechte in Kombination mit Unvorhersehbarkeit können zu gravierenden Sicherheitsvorfällen führen.
Sichere, effiziente Kommunikation und Zusammenarbeit zwischen Agenten müssen ausdrücklich durch kryptografisch überprüfbare Protokolle wie Mutual TLS (mTLS) erzwungen werden.
Das Risiko, dass Aktionen autonomer Systeme nicht auf einer menschlichen Anfrage basieren.
Die CSA schlägt einen neuen Standard vor und nennt die folgenden wesentlichen Komponenten für eine Agenten-Identität (Agent ID):
Kryptografischer Anker und Verifizierer
Kernattribute und Metadaten
Fähigkeiten, Umfang und Verhalten
Betriebs- und Sicherheitsparameter
Überprüfbare Anmeldedaten (Verifiable Credentials, VCs), die der Schlüssel zu dynamischen Attributen und Vertrauen sind
Damit entsteht Eigentum und Kontrolle über die Agent ID, was die Prinzipien der Self-Sovereign Identity (SSI) beschreibt. Schließlich umfasst der Prozess auch die Erstellung, Zuweisung und das Lebenszyklusmanagement der ID, um zu regeln, wie die Agent ID während ihres Einsatzes verwendet, widerrufen oder erneuert wird.
¹⁵ https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach
All dies ist notwendig, um die neue Architektur des Agentic AI Identity and Access Management Frameworks zu unterstützen, die aus folgenden Elementen besteht:
Zero-Trust-Architektur für Agentic AI
Dezentralisiertes Identitätsmanagement
Dynamische, richtlinienbasierte Zugriffskontrolle (PBAC)
Framework zur Authentifizierungsdelegation
Kontinuierliches Monitoring und Verhaltensanalyse
Sichere Kommunikationsprotokolle
Es existieren Proof-of-Concept-Codes zu diesen Vorschlägen¹⁶ ¹⁷, doch zum Zeitpunkt der Veröffentlichung wurde keiner davon als Standard übernommen. Das deutet darauf hin, dass es zunächst viele individuelle („roll-your-own“) Lösungen geben wird – oder gar keine.
¹⁶ https://github.com/akramIOT/Agentic-IAM
¹⁷ https://github.com/kenhuangus/agent-id-sdk
Governance und Agentic AI
Sicherheit ohne Aufsicht wird immer ineffektiv sein und in Konflikt mit dem Geschäft stehen, dem sie dienen soll. Es ist wichtig, dass Geschäftsführung und Sicherheitsteams zusammenarbeiten, um den größtmöglichen Nutzen aus Projekten zu ziehen, die Automatisierung durch Generative KI vorantreiben.¹⁸ Gleichzeitig ist es entscheidend, die Risiken zu verstehen, aus Fehlern zu lernen – aber auch aus dem, was funktioniert.
Jedes Unternehmen sollte ein Agentic-AI-Komitee oder -Team einrichten. Dieses Team ist verantwortlich für die gesamte Agentic-AI-Strategie und die Aufsicht, damit das Unternehmen den Einfluss von Agentic AI auf das Geschäft steuern und messen kann. Idealerweise sollte dieses Team von Stakeholdern geleitet werden, die direkt an den Vorstand berichten, und mit Fachleuten aus verschiedenen Bereichen besetzt sein, um ein interdisziplinäres Team zu bilden.
Das Agentic-AI-Team muss ein aktuelles Register aller Agenten und ihrer Anwendungsfälle führen, nachverfolgen, auf welche Daten die Agenten Zugriff haben, und dokumentieren, welche Kontrollen für diese Anwendungsfälle gelten.
Darüber hinaus ist das Team verantwortlich für die Bewertung der Sicherheitslage dieser Agentic-AI-Anwendungsfälle – idealerweise, bevor diese produktiv eingesetzt werden.
Das Team sollte regelmäßige Feedback- und Nachbesprechungssitzungen durchführen, um aus Erfolgen und Misserfolgen zu lernen und sicherzustellen, dass die Erkenntnisse mit der gesamten Organisation – insbesondere dem Vorstand – geteilt werden. Diese Erfahrungen sollten in Benchmarks für zukünftige Anwendungsfälle überführt werden.
Das Agentic-AI-Team muss außerdem Richtlinien für Schutzmechanismen und menschliches Eingreifen festlegen. Es sollte Leitlinien für Anwendungsfälle definieren und diese mit den gewünschten Ergebnissen abgleichen. Szenarien, die Kunden betreffen, müssen besonders geprüft werden, um sicherzustellen, dass rechtzeitig und angemessen menschlich eingegriffen wird, um unerwünschte Ergebnisse zu vermeiden.
Bestehende Strategien und Sicherheitsprinzipien können genutzt werden, um Richtlinien zu definieren für:
Menschliche und nicht-menschliche Identitäten und deren Überwachung sowie Alarmierung
Prinzip des geringsten Privilegs – Konten mit minimalen Rechten auf Daten und Systeme
Erzwingung von ablaufenden Anmeldeinformationen und Zugriffstokens
Nachvollziehbarkeit und Verantwortlichkeit aller Aktivitäten im Zusammenhang mit Agentic-AI-basierten Systemen
Es ist die Verantwortung des Agentic-AI-Teams sicherzustellen, dass Zero-Trust-Prinzipien von Beginn an in alle Agentic-AI-Anwendungsfälle integriert sind.
¹⁸ https://www.paloaltonetworks.com/blog/2025/09/agentic-ai-looming-security-crisis/
Fazit
Der Informationsfluss ist entscheidend für Volkswirtschaften, und der Bedarf an Informationsverarbeitung wächst täglich. Gleichzeitig steigt der Bedarf an tieferen Einblicken und einer schnelleren Synthese von Informationen – wenn nicht sogar noch stärker. LLMs sind ein Durchbruch, der genau dieses Bedürfnis erfüllt.
Dies führt zu immer komplexeren Informationsflüssen, die umfangreichere und anspruchsvollere Kontrollen erfordern, um den legitimen Zugriff auf Informationen zu dem vorgesehenen Zweck sicherzustellen. Agentische Identität wird dabei eine zentrale Rolle spielen, da sie es Systemdesignern ermöglicht, Konzepte wie das Prinzip des geringsten Privilegs durchzusetzen und relevante Parteien zur Verantwortung zu ziehen.
Sicherheitsmodelle müssen sich weiterentwickeln, um eine neue Art von Risiko zu berücksichtigen, das aus dem nicht-deterministischen Verhalten agentischer KI-Systeme entsteht. Emergentes Verhalten erschwert es Systemdesignern und Administratoren, die Auswirkungen unvorhersehbaren Verhaltens oder böswilliger Manipulationen zu begrenzen. Trait-basierte Sicherheitsmodelle arbeiten mit bestehenden Prozessen zusammen, um den Umfang, die Definition und die Abschwächung potenziell unerwünschter Ereignisse besser zu gestalten – und sie im besten Fall ganz zu vermeiden.
„Secure by Design“ und „Secure by Default“ müssen für alle Unternehmen oberste Priorität haben – insbesondere jetzt, da im Grunde jeder zum Programmierer geworden ist