Kurz erklärt
Warum sind KI-Agenten sicherheitsrelevanter als reine Chatbots?
Ein Chatbot beantwortet typischerweise Anfragen. Ein KI-Agent kann darüber hinaus planen, Daten abrufen, externe Inhalte verarbeiten, Tools aufrufen und Aktionen in anderen Systemen auslösen. Damit vergrößert sich nicht nur die Funktionalität, sondern auch die Angriffs- und Fehlerfläche. NIST hebt bei Software- und KI-Agenten insbesondere Identifikation, Autorisierung, Auditing, Nichtabstreitbarkeit und den Umgang mit Prompt Injection als zentrale Themen hervor. OWASP nennt zusätzlich Tool-Missbrauch, Datenabfluss und Memory Poisoning als agentenspezifische Risiken.
Entscheidend ist deshalb nicht nur, ob das Sprachmodell „sicher“ antwortet. Ein Sicherheitskonzept muss festlegen, wer der Agent ist, worauf er zugreifen darf, welche Aktionen er ausführen kann, welche externen Inhalte er als Kontext erhält und wo ein Mensch oder eine deterministische Regel eingreifen muss.
Risikomodell
Die wichtigsten Sicherheitsrisiken bei KI-Agenten
Prompt Injection
Manipulierte Anweisungen können direkt vom Nutzer oder indirekt aus Websites, E-Mails, Dokumenten und anderen Datenquellen in den Agentenkontext gelangen. Gefährlich wird das vor allem dann, wenn solche Inhalte Tool-Aufrufe beeinflussen.
Übermäßige Berechtigungen
Ein Agent mit breiten Rollen, langlebigen Tokens oder Zugriff auf mehrere Systeme kann bei Fehlverhalten einen deutlich größeren Schaden verursachen. Microsoft empfiehlt deshalb eindeutige Agentenidentitäten und Least Privilege.
Tool-Missbrauch
Ein legitimes Tool kann für eine falsche Aktion verwendet werden. Schreibende, kaufende, löschende oder kommunizierende Tools sind deshalb riskanter als reine Lesezugriffe.
Datenabfluss
Sensible Informationen können über Agentenantworten, Tool-Aufrufe, API-Anfragen, Logs oder falsch konfigurierte externe Systeme abfließen. Datenzugriff und Output-Kanäle müssen gemeinsam betrachtet werden.
Memory Poisoning
Persistente Erinnerungen oder Wissensspeicher können falsche oder manipulierte Informationen dauerhaft übernehmen. Langzeit-Memory braucht daher klare Schreibrechte, Herkunft und Löschregeln.
Supply-Chain-Risiken
Modelle, Plugins, MCP-Server, APIs, Datenquellen und Bibliotheken sind Teil der Sicherheitsgrenze. Eine Änderung an einer Abhängigkeit kann das Verhalten eines Agenten verändern, ohne dass sich der eigentliche Prompt ändert.
Grundprinzip
Least Privilege: Agenten nur die Rechte geben, die sie wirklich brauchen
Least Privilege bedeutet bei Agenten mehr als eine einzelne Rollenberechtigung. Es betrifft Identität, Datenquellen, Tools, Zielsysteme, Aktionen und Zeitdauer der Berechtigung. Microsoft beschreibt als sinnvolle Praxis eine eindeutige Agentenidentität mit verantwortlichem Owner, klar dokumentiertem Zweck und überprüfbarem Berechtigungsumfang. Höhere Rechte sollten, wo möglich, nur temporär oder nach zusätzlicher Freigabe aktiviert werden.
Ein Recherche-Agent braucht beispielsweise nicht automatisch Schreibzugriff auf CRM-Daten. Ein Ticket-Agent muss möglicherweise Tickets schließen dürfen, aber keine Benutzerrollen verändern. Ein Coding-Agent kann Repository-Zugriff benötigen, sollte deshalb aber nicht zwangsläufig Produktions-Secrets oder unternehmensweite Cloud-Administratorrechte sehen.
Rechte nicht nach dem maximal denkbaren Workflow vergeben, sondern nach dem kleinsten real benötigten Handlungsschritt. Neue Tools oder Datenquellen sollten eine erneute Berechtigungsprüfung auslösen.
Externe Inhalte
Prompt Injection: Warum Webseiten, E-Mails und Dokumente nicht vertrauenswürdig sind
Indirect Prompt Injection ist für Agenten besonders relevant, weil Agenten fremde Inhalte häufig selbstständig abrufen. Eine Website kann Text enthalten, der wie eine Anweisung an das Modell formuliert ist; dasselbe gilt für E-Mails, Tickets, PDFs oder Dateien. Wenn ein Agent solche Inhalte ungeprüft mit privilegierten Tools kombiniert, kann aus einer Textmanipulation eine reale Aktion werden.
OpenAI empfiehlt für Agenten-Workflows, nicht vertrauenswürdige Daten nicht direkt das Verhalten kritischer Schritte steuern zu lassen. Strukturierte Übergaben – etwa validierte JSON-Felder oder klar definierte Enums – können den Einfluss freier Texte begrenzen. Zusätzlich sollten Tool Approvals, Guardrails und Evals kombiniert werden. Auch OWASP empfiehlt, Prompt Injection nicht isoliert zu betrachten, sondern gemeinsam mit Tool-Rechten, Datenzugriff und Memory.
Wichtig: Prompt Injection lässt sich nicht allein durch einen „besseren System-Prompt“ lösen. Je höher die Auswirkung eines Tool-Aufrufs, desto stärker sollte die Absicherung außerhalb des Sprachmodells sein.
Kontrollpunkte
Human-in-the-loop: Welche Aktionen sollten Menschen freigeben?
Eine menschliche Freigabe ist besonders sinnvoll, wenn eine Aktion irreversibel, finanziell, rechtlich relevant, öffentlich sichtbar oder sicherheitskritisch ist. Microsoft nennt beispielsweise Änderungen an Daten, Kommunikation, Käufe, Löschvorgänge und andere Aktionen mit Nebenwirkungen als typische Kandidaten für Approval-Gates.
Human Approval ersetzt jedoch keine technische Autorisierung. Ein Mensch sollte nicht regelmäßig Aktionen bestätigen müssen, die der Agent technisch gar nicht ausführen dürfte. Gute Systeme kombinieren deshalb Least Privilege + Approval Gates.
Identity & Access
Agenten brauchen nachvollziehbare Identitäten
Wenn ein Agent unter einem gemeinsam genutzten Servicekonto oder den dauerhaften Rechten eines Menschen arbeitet, wird schwer nachvollziehbar, wer eine Aktion tatsächlich ausgelöst hat. NIST arbeitet deshalb ausdrücklich an Identitäts- und Autorisierungsfragen für Software- und KI-Agenten. Microsoft empfiehlt eindeutige, lifecycle-fähige Agentenidentitäten, damit Zugriffe geprüft, entzogen und protokolliert werden können.
Für die Produktauswahl sind daher Funktionen wie SSO, SAML/OIDC, SCIM, RBAC, Custom Roles und Audit Logs relevant – aber nicht austauschbar. SSO allein bedeutet beispielsweise nicht automatisch SCIM-Provisioning oder granulare Rollen. AgentenCode behandelt diese Merkmale deshalb getrennt und setzt unbekannte Felder nicht automatisch auf „Nein“.
Daten & Datenschutz
Sensible Daten: Zugriff, Training, Speicherung und Region getrennt prüfen
„Der Anbieter ist sicher“ ist für Datenfragen zu grob. Unternehmen sollten mindestens unterscheiden: Welche Daten darf der Agent lesen? Werden Eingaben zum Training verwendet? Wie lange werden Inhalte gespeichert? Gibt es Löschoptionen? In welchen Regionen werden Daten verarbeitet? Welche Daten verlassen das eigene Netzwerk? Welche verbundenen Tools erhalten Kontext?
Bei personenbezogenen, vertraulichen oder regulierten Daten steigt der Prüfbedarf. Microsoft empfiehlt für regulierte Daten explizite Zugriffsfreigaben, engere Scopes, stärkere Auditierung und eine Kontrolle externer beziehungsweise mandantenübergreifender Datenbewegungen. Unabhängig vom Anbieter bleibt das Unternehmen dafür verantwortlich, seinen konkreten Einsatz und die eigenen Verpflichtungen zu bewerten.
„Datenresidenz verfügbar“, „Region durch Kunden wählbar“, „Private Network“ und Verschlüsselungsmerkmale sind separate Felder. Eine generische Enterprise- oder Security-Seite reicht nicht automatisch als Beleg für jede einzelne Eigenschaft.
Interoperabilität
Sind MCP und A2A sicher?
MCP und A2A sind keine Sicherheitszertifikate. Sie standardisieren Interoperabilität: MCP verbindet Modelle oder Agenten mit Tools und Datenquellen; A2A beschreibt Kommunikation zwischen Agenten. Ob eine konkrete Verbindung sicher ist, hängt von Authentifizierung, Autorisierung, Token-Scope, Netzwerkgrenzen, Serververtrauen und der Implementierung ab.
Ein MCP-Server kann beispielsweise sehr mächtige Tools anbieten. Die Tatsache, dass ein Agent MCP unterstützt, sagt deshalb noch nichts darüber aus, ob einzelne Tool-Aufrufe genehmigt werden müssen oder wie Credentials geschützt werden. OpenAI empfiehlt bei MCP-basierten Agenten-Workflows ausdrücklich Tool Approvals. Für A2A gilt dasselbe Prinzip: Agent Card und Protokollfähigkeit schaffen Interoperabilität, ersetzen aber keine Vertrauensentscheidung zwischen zwei Agenten.
Für Unternehmen sollten MCP-Server und A2A-Endpunkte deshalb wie andere externe Abhängigkeiten inventarisiert, versioniert und überwacht werden.
Memory & Kontext
Memory kann Nutzen erhöhen – und Sicherheitsgrenzen verwischen
Persistentes Memory kann Agenten produktiver machen, weil Präferenzen, Aufgabenstatus oder Organisationswissen über eine einzelne Sitzung hinaus verfügbar bleiben. Gleichzeitig entsteht ein zusätzlicher Speicherort für sensible oder manipulierte Informationen. Microsoft nennt Memory-Design, Isolation und Schutz vor Poisoning ausdrücklich als Teil der Agentensicherheit.
Organisationen sollten deshalb festlegen, welche Informationen gespeichert werden dürfen, wer Memory schreiben oder lesen kann, wie lange Einträge bestehen und wie sie korrigiert oder gelöscht werden. Besonders kritisch ist gemeinsam genutztes Memory, wenn Inhalte eines Nutzers spätere Aktionen für andere Nutzer beeinflussen können.
Audit & Observability
Logs müssen zeigen, was der Agent tatsächlich getan hat
Bei klassischen Anwendungen reicht ein Login-Log allein nicht aus. Bei Agenten sollte nachvollziehbar sein, unter welcher Identität und Rolle eine Aktion erfolgte, welches Tool aufgerufen wurde, welche Zielressource betroffen war und ob die Aktion im Namen eines Nutzers ausgeführt wurde. Microsoft empfiehlt außerdem Korrelations-IDs, damit mehrstufige Abläufe später rekonstruiert werden können.
Audit Logs sind trotzdem kein Selbstzweck. Organisationen brauchen eine klare Aufbewahrung, Zugriffskontrolle und Auswertung. Logs können selbst sensible Daten enthalten und müssen entsprechend geschützt werden. Für produktive Agenten sollte außerdem ein Abschalt- und Revocation-Pfad getestet sein: Agent deaktivieren, Tokens ungültig machen, Credentials rotieren und veraltete Rechte entfernen.
Mehrere Agenten
Multi-Agent-Systeme erhöhen die Zahl der Vertrauensbeziehungen
Wenn mehrere Agenten Aufgaben übergeben, entstehen zusätzliche Grenzen zwischen Identitäten, Tools, Daten und Verantwortlichkeiten. Microsoft weist darauf hin, dass Multi-Agent-Systeme die Komplexität erhöhen und mehr Möglichkeiten für unerwartete Interaktionen schaffen. Jede Übergabe sollte deshalb als eigene Vertrauensentscheidung betrachtet werden – nicht automatisch als sicher, nur weil beide Agenten zum selben Workflow gehören.
Besonders wichtig sind klare Rollen, erlaubte Datenweitergabe, definierte Endpunkte und nachvollziehbare Übergaben. Ein Agent sollte nicht allein deshalb auf alle Daten eines anderen Agenten zugreifen dürfen, weil beide in derselben Orchestrierung vorkommen.
Unternehmens-Checkliste
KI-Agenten vor dem produktiven Einsatz prüfen
- Zweck definieren.
Welche konkrete Aufgabe soll der Agent übernehmen – und was ausdrücklich nicht?
- Identität klären.
Arbeitet der Agent mit eigener Identität, im Namen eines Nutzers oder mit gemeinsam genutzten Credentials?
- Daten inventarisieren.
Welche personenbezogenen, vertraulichen oder regulierten Daten können in den Agentenkontext gelangen?
- Tools klassifizieren.
Welche Tools lesen nur, welche verändern Daten und welche lösen irreversible Aktionen aus?
- Least Privilege anwenden.
Rollen, Tokens, API-Scopes und Netzwerkzugriffe auf das Minimum begrenzen.
- Approval Gates setzen.
Finanzielle, irreversible, rechtlich relevante und öffentlich sichtbare Aktionen gezielt freigeben lassen.
- Externe Inhalte als untrusted behandeln.
Webseiten, E-Mails, Dateien und Tool-Antworten dürfen kritische Aktionen nicht ungeprüft steuern.
- Memory regeln.
Speicherung, Schreibrechte, Löschung und Isolation dauerhaft gespeicherter Informationen festlegen.
- Logging testen.
Tool Calls, Identität, Zielressource, Aktion und Ergebnis müssen nachvollziehbar sein.
- Revocation üben.
Agenten abschalten, Tokens entziehen, Credentials rotieren und Berechtigungen entfernen können.
- Grenzfälle evaluieren.
Nicht nur Demo-Prompts testen, sondern Manipulation, fehlerhafte Tools, unerwartete Daten und Abbruchpfade.
- Änderungen überwachen.
Neue Tools, Modelle, Datenquellen oder Anbieteränderungen können eine erneute Prüfung erforderlich machen.
AgentenCode in der Praxis
Welche Sicherheitsmerkmale dokumentiert AgentenCode?
AgentenCode versucht nicht, einen eigenen Penetrationstest oder eine juristische Freigabe zu ersetzen. Die AgentenPassports und Deep-Evidence-Daten strukturieren öffentlich belegbare Eigenschaften, die für eine Vorprüfung relevant sind. Dazu gehören unter anderem:
Fehlt für ein Feld eine belastbare Primärquelle, bleibt es unknown. Das ist ein zentraler Sicherheitsgrundsatz: Eine nicht gefundene Funktion ist nicht dasselbe wie eine dokumentiert nicht vorhandene Funktion.
Anforderungen prüfen
Security-Kriterien direkt gegen Agenten-Evidenz abgleichen.
AgentenFit kann unter anderem SSO, SCIM, RBAC, Audit Logs, Datenresidenz, Verschlüsselung, CMK, MCP/A2A und Hosting anhand der dokumentierten Field-Level-Evidenz vergleichen.
Primärquellen
Grundlage dieser Sicherheitsreferenz
- NIST NCCoE – Identity and Authority of Software and AI Agents ↗Identifikation, Autorisierung, Auditing, Non-Repudiation und Prompt Injection als zentrale Themen für Agenten.
- OWASP – AI Agent Security Cheat Sheet ↗Agentenspezifische Risiken wie Prompt Injection, Tool Abuse, Data Exfiltration und Memory Poisoning.
- Microsoft – Least privilege for AI agents ↗Agentenidentität, Scoping, Tool-Zugriff, Auditierbarkeit und zeitlich begrenzte Rechte.
- Microsoft – Reduce autonomous agentic AI risk ↗Agent Hijacking, Memory, Supply Chain, Agent Sprawl, Human Oversight und Monitoring.
- OpenAI – Safety in building agents ↗Tool Approvals, Guardrails, strukturierte Übergaben, Evals und Schutz vor Prompt Injection in Agenten-Workflows.
Letzte redaktionelle Prüfung dieser Seite: 2. Oktober 2026. Hersteller- und Standarddokumentation kann sich ändern; für konkrete Produkte gelten zusätzlich die im jeweiligen AgentenProfil verlinkten Primärquellen.
FAQ
Häufige Fragen zur Sicherheit von KI-Agenten
Sind KI-Agenten sicher?
KI-Agenten können kontrolliert eingesetzt werden, wenn Identitäten, Berechtigungen, Datenzugriffe, Tools und Aktionen technisch begrenzt werden. Eine pauschale Sicherheitsgarantie gibt es nicht; das konkrete Risiko hängt vom Agenten, seinen Rechten und dem Einsatzszenario ab.
Was ist das größte Sicherheitsrisiko bei KI-Agenten?
Es gibt kein einzelnes größtes Risiko. Besonders relevant sind Prompt Injection, übermäßige Berechtigungen, Tool-Missbrauch, Datenabfluss, Memory Poisoning und fehlende Nachvollziehbarkeit.
Wie schützt man KI-Agenten vor Prompt Injection?
Externe Inhalte sollten als nicht vertrauenswürdig behandelt werden. Tool-Rechte werden begrenzt, strukturierte Übergaben bevorzugt und kritische Aktionen zusätzlich durch deterministische Regeln oder menschliche Freigaben geschützt.
Wann braucht ein KI-Agent menschliche Freigaben?
Vor allem bei irreversiblen, finanziellen, rechtlich relevanten, öffentlich sichtbaren oder besonders sicherheitskritischen Aktionen. Reine Lese- und Analyseaufgaben benötigen häufig weniger Eingriffe.
Sind MCP und A2A Sicherheitsfunktionen?
Nein. Beide Protokolle schaffen Interoperabilität. Sicherheit hängt weiterhin von Authentifizierung, Autorisierung, Scopes, Netzwerkgrenzen und der konkreten Implementierung ab.
Welche Logs sollte ein Agent erzeugen?
Mindestens relevante Identität, Rolle, Tool-Aufruf, Zielressource, Aktion und Ergebnis sollten rekonstruierbar sein. In sensiblen Umgebungen kommen Aufbewahrungs- und Compliance-Anforderungen hinzu.
Was bedeutet Least Privilege bei KI-Agenten?
Der Agent erhält nur die Daten, Tools, Rollen und Aktionen, die für seine konkrete Aufgabe erforderlich sind. Rechte sollten so eng und so kurzlebig wie praktikabel vergeben werden.
Reicht ein SOC-2- oder ISO-Nachweis des Anbieters aus?
Nein. Solche Nachweise können wichtige Informationen liefern, ersetzen aber nicht die Prüfung des konkreten Agenten, seiner Datenflüsse, Berechtigungen, Tools, Regionen und des eigenen Einsatzszenarios.