Sicherheitsarchitektur für KI-Agenten: Warum klassische Konzepte nicht mehr ausreichen

Eine Sicherheitsarchitektur für KI-Agenten muss nicht nur Server, Netzwerke und Anwendungen schützen, sondern auch Ziele, Entscheidungen, Werkzeuge und Zustandsdaten eines Agenten begrenzen. Klassische Kontrollen bleiben wichtig, reichen allein jedoch nicht aus. Erforderlich sind getrennte Identitäten, minimale Berechtigungen, kontrollierte Schnittstellen, laufende Beobachtung und verbindliche Freigaben für folgenreiche Aktionen.

Warum reichen klassische Sicherheitskonzepte für KI-Agenten nicht aus?

Klassische Anwendungssicherheit geht im Kern davon aus, dass Software vorab definierte Funktionen ausführt. Ein Benutzer klickt auf eine Schaltfläche, eine Anwendung prüft Eingaben, ruft eine bekannte Funktion auf und verarbeitet das Ergebnis nach einer programmierten Logik. Abweichungen entstehen vor allem durch Programmierfehler, Fehlkonfigurationen, gestohlene Zugangsdaten oder manipulierte Eingaben.

Ein KI-Agent arbeitet anders. Er erhält ein Ziel, bewertet den verfügbaren Kontext, zerlegt eine Aufgabe in Teilschritte und entscheidet situationsabhängig, welche Daten, Werkzeuge oder Schnittstellen er verwenden möchte. Zwei nahezu identische Anfragen können dadurch unterschiedliche Aktionsketten auslösen. Das Verhalten bleibt zwar steuerbar, lässt sich jedoch nicht vollständig durch feste Wenn-dann-Regeln vorwegnehmen.

Damit verschiebt sich der Schutzgegenstand. Es genügt nicht mehr, nur Infrastruktur, API-Endpunkte und Datenbanken abzusichern. Geschützt werden müssen zusätzlich das Ziel des Agenten, sein Arbeitskontext, seine Identität, seine Werkzeugauswahl, sein Gedächtnis, seine Entscheidungskette und die Übergabe von Ergebnissen an nachgelagerte Systeme.

Das aktuelle Rahmenwerk der OWASP Foundation (https://owasp.org/) für agentische Anwendungen nennt unter anderem Zielmanipulation, Werkzeugmissbrauch, Identitäts- und Privilegienmissbrauch, vergiftete Kontextdaten, unsichere Kommunikation zwischen Agenten, Kaskadenfehler und unerwünschtes autonomes Verhalten. Diese Risiken entstehen nicht ausschließlich im Sprachmodell. Sie ergeben sich aus dem Zusammenspiel von Modell, Orchestrierung, Berechtigungen, Schnittstellen, Datenquellen und Betriebsprozessen.

Was unterscheidet einen KI-Agenten sicherheitstechnisch von einem Chatbot?

Ein Chatbot beantwortet im einfachsten Fall Fragen. Ein Agent kann dagegen Aktionen ausführen. Er legt beispielsweise einen Vorgang im CRM an, liest eine Kundenakte, bereitet ein Angebot vor, versendet eine Nachricht, reserviert einen Termin, aktualisiert einen Projektstatus oder ruft Informationen aus dem ERP ab.

Der sicherheitstechnische Unterschied liegt deshalb weniger in der Textausgabe als in der Reichweite. Eine falsche Chatbot-Antwort kann einen Mitarbeiter irritieren. Eine ungeprüfte Agentenaktion kann Stammdaten verändern, vertrauliche Informationen versenden, einen Auftrag auslösen oder einen Geschäftsprozess blockieren.

Zudem verarbeitet ein Agent häufig Inhalte, deren Vertrauenswürdigkeit nicht feststeht. Dazu gehören E-Mails, PDF-Dateien, Webseiten, Support-Tickets, Kundenkommentare, Dokumente aus Projekträumen oder Ergebnisse anderer Agenten. In diesen Inhalten können Anweisungen verborgen sein, die den Agenten von seinem ursprünglichen Ziel abbringen. Für den Agenten ist eine solche Anweisung zunächst ebenfalls Text und damit möglicher Bestandteil seines Arbeitskontexts.

Die Sicherheitsarchitektur muss deshalb zwischen Daten und Anweisungen unterscheiden. Ein Dokument darf Informationen liefern, sollte aber nicht ohne Weiteres die Systemregeln, Berechtigungen oder Aktionsziele des Agenten verändern können.

Welche zusätzlichen Angriffsflächen entstehen durch Planung und Autonomie?

Agenten erzeugen während einer Aufgabe Zwischenziele. Sie entscheiden beispielsweise, zunächst eine Kundenakte zu prüfen, anschließend einen Vertragsentwurf zu lesen und danach eine E-Mail zu formulieren. Wird der Kontext unterwegs manipuliert, kann sich nicht nur die nächste Antwort verändern, sondern der gesamte weitere Ablauf.

Dieses sogenannte Goal Hijacking ist besonders relevant, wenn externe Inhalte in die Planung einfließen. Eine manipulierte E-Mail könnte den Agenten dazu bewegen, zusätzliche Daten abzurufen. Ein präpariertes Dokument könnte verlangen, vertrauliche Informationen in eine Zusammenfassung aufzunehmen. Ein kompromittierter Werkzeugserver könnte dem Agenten eine Funktion anbieten, deren Beschreibung harmlos wirkt, deren Ausführung aber unerwünschte Nebenwirkungen besitzt.

Hinzu kommt die Möglichkeit von Rückkopplungen. Ein Agent übernimmt das Ergebnis eines zweiten Agenten, speichert es im gemeinsamen Gedächtnis und verwendet es später erneut. Ein einzelner fehlerhafter oder manipulierter Inhalt kann sich dadurch durch mehrere Arbeitsschritte verbreiten. Aus einem lokalen Problem wird eine Kaskade.

Eine geeignete Architektur begrenzt daher nicht nur einzelne API-Aufrufe. Sie kontrolliert auch, welche Zwischenziele zulässig sind, welche Quellen Entscheidungen beeinflussen dürfen und wann ein Ablauf unterbrochen werden muss.

Warum wird die Identität des Agenten zur zentralen Sicherheitsfrage?

In vielen frühen Implementierungen arbeitet ein KI-Agent technisch unter dem Benutzerkonto eines Mitarbeiters oder mit einem breit berechtigten Servicekonto. Das ist bequem, führt aber zu einem erheblichen Zuordnungs- und Berechtigungsproblem. Der Agent kann dann häufig alles tun, was auch der Benutzer oder das Servicekonto tun darf, selbst wenn die konkrete Aufgabe nur einen kleinen Ausschnitt dieser Rechte benötigt.

Ein Vertriebsagent, der Angebote vorbereitet, benötigt möglicherweise Leserechte für Kundendaten und Produktinformationen. Er braucht jedoch nicht automatisch Zugriff auf sämtliche Personalakten, Finanzdaten oder Administrationsfunktionen. Ein Serviceagent darf einen Einsatzbericht zusammenfassen, sollte aber nicht ohne zusätzliche Freigabe Bankverbindungen, Rollenmodelle oder Vertragsstammdaten verändern können.

Die Studie von IBM (https://www.ibm.com/) zur Sicherheit von KI-Anwendungen zeigt die praktische Bedeutung dieses Themas: 13 Prozent der untersuchten Organisationen meldeten kompromittierte KI-Modelle oder KI-Anwendungen. Von den betroffenen Organisationen verfügten 97 Prozent nicht über angemessene Zugriffskontrollen für ihre KI-Systeme.

Jeder produktive Agent sollte deshalb eine eigene technische Identität besitzen. Seine Rechte werden nicht aus Bequemlichkeit vom aufrufenden Benutzer übernommen, sondern für den konkreten Auftrag ermittelt. Diese aufgabenbezogene Autorisierung kann zusätzlich berücksichtigen, welcher Benutzer den Agenten gestartet hat, welche Datenkategorie betroffen ist und welche Aktion ausgeführt werden soll.

Wie sollten Berechtigungen für KI-Agenten aufgebaut sein?

Das Prinzip der minimalen Rechte bleibt gültig, muss für Agenten jedoch feiner umgesetzt werden. Ein klassisches Servicekonto besitzt häufig dauerhafte Berechtigungen. Ein Agent sollte dagegen bevorzugt kurzlebige, auf den jeweiligen Auftrag begrenzte Zugangsdaten erhalten.

So kann ein Agent beispielsweise das Recht bekommen, genau einen bestimmten Kundenvorgang zu lesen und einen Entwurf im CRM zu speichern. Nach Abschluss der Aufgabe verliert das Token seine Gültigkeit. Der Agent erhält weder pauschalen CRM-Zugriff noch die Möglichkeit, beliebige Kunden zu exportieren.

Zusätzlich sollte zwischen Lesen, Vorschlagen, Erstellen, Ändern, Versenden und Löschen unterschieden werden. In vielen Geschäftsprozessen darf der Agent Informationen lesen und einen Vorschlag erzeugen, während die verbindliche Änderung oder der externe Versand eine menschliche Bestätigung erfordert.

Auch Datenbereiche benötigen eigene Grenzen. Ein Agent für den technischen Service kann Zugriff auf Handbücher, Wartungshistorien und Ersatzteildaten erhalten. Personenbezogene Beschäftigtendaten, vertrauliche Kalkulationen oder Geschäftsführungsunterlagen bleiben außerhalb seines Arbeitsraums.

Entscheidend ist, dass Berechtigungen nicht allein als statische Rollen verstanden werden. Die Autorisierung muss die konkrete Aktion, den aktuellen Auftrag, die betroffenen Daten und das mögliche Schadensausmaß berücksichtigen.

Warum werden Schnittstellen und Drittanbieter zum kritischen Kontrollpunkt?

KI-Agenten entfalten ihren Nutzen durch Verbindungen. Sie greifen auf CRM, ERP, DMS, E-Mail, Kalender, Datenbanken, Suchdienste, Cloud-Speicher und spezialisierte Fachanwendungen zu. Jede neue Verbindung erweitert jedoch die mögliche Aktionsfläche.

Der Data Breach Investigations Report von Verizon (https://www.verizon.com/) für 2026 ordnet 48 Prozent der untersuchten Datenschutzverletzungen einer Beteiligung von Drittanbietern zu. Für Agentenarchitekturen ist diese Entwicklung besonders relevant, weil Werkzeuge, Modellanbieter, Plug-ins, API-Dienste und externe Datenquellen häufig Bestandteil derselben Aktionskette sind.

Eine direkte Verbindung jedes Agenten mit jedem Zielsystem ist deshalb selten empfehlenswert. Besser ist eine kontrollierte Vermittlungsschicht, die Werkzeugaufrufe entgegennimmt, Berechtigungen prüft, Parameter validiert, Daten filtert und Aktionen protokolliert. Diese Schicht kann als Tool Gateway, Policy Enforcement Point oder kontrollierter MCP-Zugang umgesetzt werden.

Das Gateway sollte nicht nur prüfen, ob ein Werkzeug grundsätzlich erlaubt ist. Es muss auch die konkrete Verwendung bewerten. Ein E-Mail-Werkzeug kann für interne Entwürfe zugelassen sein, während externe Empfänger, Anhänge oder große Verteiler eine zusätzliche Freigabe benötigen.

Welche Rolle spielt das Model Context Protocol in der Sicherheitsarchitektur?

Das Model Context Protocol, kurz MCP, standardisiert die Anbindung von KI-Anwendungen an Datenquellen und Werkzeuge. Dadurch lassen sich Agenten schneller mit Dateisystemen, Datenbanken, Entwicklerwerkzeugen oder Geschäftsanwendungen verbinden. Gleichzeitig kann ein MCP-Server Funktionen, Beschreibungen und Ressourcen bereitstellen, die zur Laufzeit in den Agentenkontext gelangen.

Das schafft eine neue Vertrauensgrenze. Ein MCP-Server ist nicht nur eine technische Schnittstelle, sondern kann beeinflussen, welche Fähigkeiten der Agent wahrnimmt und wie er diese interpretiert. Manipulierte Werkzeugbeschreibungen, unsichere Parameter, zu weitreichende Tokens oder unerwartete Änderungen eines Servers können den Aktionspfad verändern.

Unternehmen sollten MCP-Server deshalb wie produktive Integrationskomponenten behandeln. Dazu gehören ein Inventar aller Server, eine Freigabe der angebotenen Werkzeuge, Versionskontrolle, Signierung oder verlässliche Herkunftsnachweise, Netzwerksegmentierung, Secret Management und eine Begrenzung ausgehender Verbindungen.

Ein Agent sollte außerdem nicht automatisch jedes neu verfügbare Werkzeug verwenden dürfen. Neue oder geänderte Funktionen müssen zunächst geprüft und einer Richtlinie zugeordnet werden. Ein dynamisch entdecktes Werkzeug darf keine höheren Rechte erhalten, nur weil seine Beschreibung zum aktuellen Ziel zu passen scheint.

Wie schützt man Gedächtnis, Kontext und Wissensquellen vor Manipulation?

Agenten verwenden häufig verschiedene Arten von Gedächtnis. Kurzfristiger Kontext enthält die aktuelle Unterhaltung und Zwischenergebnisse. Langfristiges Gedächtnis speichert Präferenzen, Zusammenfassungen oder Erkenntnisse für spätere Aufgaben. Hinzu kommen Unternehmenswissen aus Vektordatenbanken, Dokumentenspeichern und relationalen Systemen.

Diese Inhalte beeinflussen zukünftige Entscheidungen. Eine manipulierte Erinnerung ist deshalb nicht nur ein fehlerhafter Datensatz. Sie kann zu einer dauerhaften Veränderung des Agentenverhaltens führen. Die OWASP Foundation (https://owasp.org/) beschreibt Memory and Context Poisoning als eigenständige Angriffsfläche agentischer Systeme. Ein einmal eingeschleuster Inhalt kann über Sitzungen und Aufgaben hinweg weiterwirken.

Gedächtnis benötigt daher Herkunftsinformationen. Das System sollte speichern, woher ein Inhalt stammt, wann er erzeugt wurde, welcher Benutzer oder Prozess ihn bestätigt hat und für welche Aufgaben er verwendet werden darf. Externe Inhalte dürfen nicht automatisch denselben Vertrauensstatus erhalten wie freigegebene Arbeitsanweisungen.

Sinnvoll sind getrennte Speicherbereiche für Benutzerpräferenzen, fachliches Wissen, temporäre Arbeitsergebnisse und sicherheitsrelevante Systemvorgaben. Ein Agent sollte keine Systemrichtlinie überschreiben können, nur weil eine neue Zusammenfassung im Langzeitgedächtnis gespeichert wurde.

Auch Lösch- und Ablaufregeln gehören zur Architektur. Nicht jede Information muss dauerhaft erhalten bleiben. Kurzfristige Tokens, vertrauliche Zwischenergebnisse oder personenbezogene Daten sollten nach Abschluss eines Vorgangs entfernt oder gezielt archiviert werden.

Warum genügt klassische Protokollierung bei Agenten nicht?

Ein gewöhnliches Anwendungsprotokoll hält fest, welcher Endpunkt aufgerufen wurde und ob die Verarbeitung erfolgreich war. Bei einem Agenten reicht das nicht, weil der sicherheitsrelevante Zusammenhang zwischen Ziel, Kontext, Entscheidung und Aktion liegt.

Nachvollziehbar sein sollte, wer den Agenten gestartet hat, welches Ziel übergeben wurde, welche Datenquellen verwendet wurden, welche Werkzeuge zur Auswahl standen, welche Aktion vorgeschlagen oder ausgeführt wurde und welche Freigabe vorlag. Auch Richtlinienentscheidungen, blockierte Aufrufe und Änderungen des Gedächtnisses gehören in die Aufzeichnung.

Dabei müssen Unternehmen vermeiden, sämtliche vertraulichen Inhalte ungefiltert in Logdateien zu kopieren. Zugangsdaten, vollständige Dokumente oder personenbezogene Informationen können selbst in der Überwachung neue Risiken erzeugen. Protokolle sollten deshalb strukturierte Metadaten, Referenzen, Prüfsummen und gezielt geschützte Detailinformationen enthalten.

Observability bedeutet bei Agenten außerdem mehr als technische Verfügbarkeit. Sie umfasst Aktionsmuster. Wenn ein Angebotsagent plötzlich auf ungewöhnlich viele Kundendatensätze zugreift, externe Domains anspricht oder ein nicht vorgesehenes Werkzeug verwendet, sollte das System den Vorgang stoppen oder an einen Mitarbeiter übergeben.

Wie unterscheiden sich klassische Anwendungssicherheit und Agentensicherheit?

Klassische Kontrollen verschwinden damit nicht. Netzwerksegmentierung, Patchmanagement, Verschlüsselung, sichere Softwareentwicklung, Backups und Schwachstellenmanagement bleiben das Fundament. Hinzu kommt eine zweite Ebene, die das Verhalten des Agenten während der Ausführung kontrolliert.

Wie sieht eine mehrschichtige Sicherheitsarchitektur für KI-Agenten aus?

Eine belastbare Architektur beginnt mit einer vertrauenswürdigen Infrastruktur. Modelle, Orchestrierung, Vektordatenbanken, API-Gateways und Laufzeitumgebungen werden gepatcht, segmentiert und mit zentralem Secret Management betrieben. Dieser Teil entspricht weitgehend etablierter IT-Sicherheit.

Darüber liegt die Identitätsebene. Jeder Agent erhält eine eindeutige Identität, einen definierten Eigentümer und begrenzte Rollen. Kurzlebige Tokens und auftragsbezogene Berechtigungen verhindern, dass ein kompromittierter Agent dauerhaft auf ganze Systeme zugreifen kann.

Die Datenebene steuert Herkunft, Vertraulichkeit, Integrität und zulässige Verwendung. Dokumente werden klassifiziert, Ergebnisse mit Quellen versehen und Speicherbereiche voneinander getrennt. Vertrauliche Daten werden vor der Übergabe an externe Modelle gefiltert oder pseudonymisiert.

Die Werkzeugsebene kontrolliert API-, MCP- und Funktionsaufrufe. Ein Gateway prüft Parameter, Empfänger, Datenmenge, Zielsystem und Risikoklasse. Folgenreiche Aktionen benötigen eine Bestätigung oder ein zweites technisches Kontrollsignal.

Die Verhaltensebene überwacht Zieländerungen, ungewöhnliche Aktionsfolgen, wiederholte Fehlversuche und Abweichungen vom vorgesehenen Prozess. Grenzwerte für Laufzeit, Tokenverbrauch, Zahl der Werkzeugaufrufe und Datenumfang begrenzen Endlosschleifen und unkontrollierte Skalierung.

Schließlich benötigt die Architektur eine betriebliche Ebene. Verantwortlichkeiten, Freigaberegeln, Incident-Prozesse, Testzyklen, Notabschaltung und Wiederanlauf werden vor der Produktivsetzung festgelegt. Das National Institute of Standards and Technology, NIST (https://www.nist.gov/), entwickelt hierfür Kontrollprofile, die ausdrücklich auch Einzelagenten und Multi-Agenten-Systeme berücksichtigen.

Wann braucht ein Agent eine menschliche Freigabe?

Nicht jede Agentenaktion muss bestätigt werden. Ein Agent darf beispielsweise Dokumente suchen, Inhalte zusammenfassen oder interne Entwürfe erstellen, sofern die verwendeten Daten und Ausgabebereiche begrenzt sind. Eine Bestätigung wird dort wichtig, wo eine Aktion schwer rückgängig zu machen ist oder externe Auswirkungen besitzt.

Dazu gehören Zahlungen, Vertragsabschlüsse, Bestellungen, Änderungen von Berechtigungen, Löschvorgänge, externe Nachrichten, Veröffentlichungen und Eingriffe in technische Anlagen. Auch der Zugriff auf besonders geschützte Daten kann eine vorherige Freigabe erfordern.

Die Freigabe sollte mehr enthalten als eine allgemeine Schaltfläche mit „Bestätigen“. Der Mitarbeiter muss sehen, welche Aktion geplant ist, welche Daten verwendet werden, welches System betroffen ist und welche Folgen zu erwarten sind. Änderungen gegenüber einem vorherigen Entwurf sollten hervorgehoben werden.

Wichtig ist zudem, dass der Agent die Freigabe nicht selbst erzeugen oder umgehen kann. Bestätigung und Ausführung müssen technisch getrennt sein. Für besonders kritische Vorgänge kann ein Vier-Augen-Prinzip oder eine zusätzliche Richtlinienprüfung erforderlich sein.

Welche Anwendungsfälle eignen sich für einen sicheren Einstieg im Mittelstand?

Ein guter Einstieg liegt bei Aufgaben mit hohem Informationsanteil und begrenzter Aktionsreichweite. Ein Agent kann beispielsweise eingehende Serviceanfragen strukturieren, passende Dokumente suchen, eine Übergabe für den Innendienst vorbereiten und einen Terminvorschlag erstellen. Die endgültige Kundenkommunikation bleibt zunächst beim Mitarbeiter.

Auch Angebotsvorbereitung eignet sich, wenn der Agent Leistungsverzeichnisse ausliest, frühere Kalkulationen findet und fehlende Angaben markiert. Preise, Rabatte und verbindliche Versandentscheidungen werden nicht autonom getroffen.

Im Dokumentenmanagement kann ein Agent Dateien klassifizieren, Metadaten vorschlagen und Dubletten erkennen. Die endgültige Löschung, Änderung von Aufbewahrungsfristen oder Freigabe vertraulicher Unterlagen bleibt geschützt.

Weniger geeignet für den Einstieg sind Agenten mit pauschalem Zugriff auf E-Mail, Dateisystem, ERP, Zahlungsverkehr und öffentliche Kommunikation. Eine solche Kombination erzeugt einen großen Wirkungsradius, bevor das Unternehmen ausreichend Erfahrung mit Überwachung, Berechtigungen und Fehlerbehandlung gesammelt hat.

Was läuft bei Agentensicherheitsprojekten üblicherweise falsch?

Ein häufiger Fehler besteht darin, nur das Sprachmodell zu bewerten. Unternehmen vergleichen Modelle, Prompt-Filter und Ausgaberichtlinien, während der Agent gleichzeitig ein zu weit berechtigtes Servicekonto verwendet. Der eigentliche Risikotreiber liegt dann nicht in der Antwortqualität, sondern in der Kombination aus Modellentscheidung und technischer Reichweite.

Ebenso problematisch ist eine einmalige Sicherheitsprüfung vor dem Start. Agenten verändern sich durch neue Werkzeuge, andere Modelle, aktualisierte Wissensbestände und zusätzliche Schnittstellen. Eine Architektur, die beim Pilot funktionierte, kann nach mehreren Erweiterungen völlig andere Aktionsketten ermöglichen.

Oft fehlt auch ein vollständiges Inventar. Niemand weiß dann zuverlässig, welche Agenten produktiv sind, welche Konten sie verwenden, mit welchen Datenquellen sie verbunden sind und wer fachlich verantwortlich ist. Ohne Inventar lassen sich weder Rechte überprüfen noch Vorfälle eingrenzen.

Ein weiterer Fehler ist die Speicherung vollständiger Eingaben, Dokumente und Modellantworten in zentralen Logsystemen. Die Überwachung wird dadurch selbst zu einem umfangreichen Datenspeicher mit neuen Zugriffs- und Aufbewahrungsrisiken.

Schließlich wird häufig nur der Normalfall getestet. Angreifer und technische Fehler nutzen jedoch Grenzfälle: widersprüchliche Anweisungen, manipulierte Dokumente, unerwartete Dateiformate, abgebrochene API-Aufrufe, wiederholte Tool-Aufrufe oder Ergebnisse, die einen Folgeagenten zu einer unerwünschten Handlung bewegen.

Wie können mittelständische Unternehmen pragmatisch beginnen?

Der erste Schritt ist ein Agenteninventar. Erfasst werden Zweck, Eigentümer, Modell, Hosting, Datenquellen, Werkzeuge, Identität, Berechtigungen und mögliche externe Auswirkungen. Auch Agentenfunktionen innerhalb vorhandener SaaS-Anwendungen gehören dazu.

Danach wird für jeden Anwendungsfall der maximale Wirkungsradius bestimmt. Welche Daten kann der Agent lesen? Was kann er verändern? Kann er externe Kommunikation auslösen? Wie viele Datensätze könnte er in einem fehlerhaften Lauf verarbeiten? Welche Aktion wäre wirtschaftlich oder rechtlich besonders problematisch?

Aus dieser Bewertung entsteht ein Berechtigungs- und Freigabemodell. Aktionen mit geringem Risiko können automatisiert werden. Mittlere Risiken erhalten technische Prüfungen oder eine Stichprobe. Folgenreiche Aktionen benötigen eine ausdrückliche Bestätigung.

Anschließend wird ein kontrollierter Pilot mit realen, aber begrenzten Vorgängen durchgeführt. Dabei sollten nicht nur erfolgreiche Aufgaben getestet werden. Das Team benötigt bewusst präparierte Dokumente, widersprüchliche Eingaben, unerwartete Werkzeugantworten und simulierte Ausfälle.

Erst wenn Protokollierung, Abschaltung, Fehlerbehandlung und Verantwortlichkeiten funktionieren, wird der Umfang erweitert. Der Ansatz ist weniger spektakulär als ein vollständig autonomer Agent, führt aber deutlich häufiger zu einem System, das im Tagesgeschäft dauerhaft eingesetzt werden kann.

Welche rechtlichen Anforderungen sind in Deutschland relevant?

Für deutsche Unternehmen kommen bestehende Pflichten aus Datenschutz, Vertragsrecht, Geschäftsgeheimnisschutz, IT-Sicherheit und branchenspezifischen Vorgaben hinzu. Ein KI-Agent schafft keinen rechtsfreien Automatisierungsraum. Das Unternehmen bleibt für Datenverarbeitung, Zugriffsrechte, ausgelöste Handlungen und organisatorische Kontrollen verantwortlich.

Der europäische AI Act, Regulation (EU) 2024/1689, enthält für Hochrisiko-KI-Systeme Anforderungen an Genauigkeit, Robustheit und Cybersicherheit. Auch wenn nicht jeder betriebliche Agent als Hochrisiko-System eingestuft wird, bietet der Ansatz einen sinnvollen Maßstab für Architektur und Betrieb: Risiken werden über den gesamten Lebenszyklus betrachtet und nicht erst nach einem Vorfall.

Bei personenbezogenen Daten müssen Zweckbindung, Datenminimierung, Berechtigungen und Löschregeln berücksichtigt werden. Nutzt ein Agent externe Modell- oder Werkzeuganbieter, sind zudem Auftragsverarbeitung, Datenstandorte, Unterauftragnehmer und mögliche Übermittlungen zu prüfen.

Für Geschäftsgeheimnisse ist entscheidend, ob vertrauliche Informationen an externe Dienste übertragen, in Protokollen gespeichert oder durch Ergebnisse an unberechtigte Empfänger weitergegeben werden können. Technische Filter und Vertragsklauseln müssen hier zusammenwirken.

Wie werden KI-Agenten sicher getestet?

Funktionsprüfungen beantworten lediglich, ob der Agent eine vorgesehene Aufgabe erledigen kann. Sicherheitstests untersuchen dagegen, wie er auf manipulierte, widersprüchliche oder unerwartete Situationen reagiert.

Ein Testkatalog sollte direkte und indirekte Prompt Injection, manipulierte Dokumente, vergiftete Wissenseinträge, fehlerhafte Werkzeugbeschreibungen, abgelaufene Tokens, unzulässige Empfänger, große Datenabfragen und mehrstufige Angriffsketten enthalten. Auch die Kommunikation zwischen mehreren Agenten muss geprüft werden.

Zusätzlich benötigt das Unternehmen Tests der technischen Grenzen. Kann der Agent sein Laufzeitlimit überschreiten? Kann er durch wiederholte Aufrufe hohe Kosten verursachen? Werden Daten auch dann geschützt, wenn ein Werkzeug nicht verfügbar ist? Greift die Notabschaltung während einer laufenden Aktionskette?

MITRE (https://www.mitre.org/) erweitert seine ATLAS-Wissensbasis fortlaufend um Angriffstechniken, Gegenmaßnahmen und Fallstudien für KI-Systeme. ATLAS unterstützt Unternehmen dabei, agentenspezifische Bedrohungen in Threat Modeling, Red Teaming und Security Operations einzubeziehen.

Wann ist ein KI-Agent bereit für den Produktivbetrieb?

Ein Agent ist nicht produktionsbereit, nur weil seine Antworten in einer Demonstration überzeugen. Er benötigt einen fachlichen Eigentümer, eine dokumentierte Zweckbestimmung, eine eigene Identität, begrenzte Berechtigungen, definierte Datenquellen und eine kontrollierte Werkzeugliste.

Darüber hinaus müssen Protokollierung, Alarmierung, Abschaltung und Wiederanlauf getestet sein. Das Unternehmen sollte wissen, wie es Tokens entzieht, eine kompromittierte Wissensquelle isoliert, fehlerhafte Erinnerungen entfernt und laufende Aufgaben beendet.

Für jede folgenreiche Aktion braucht es eine eindeutige Freigaberegel. Fehler und blockierte Aktionen müssen an eine zuständige Stelle gelangen. Änderungen an Modellen, Prompts, Werkzeugen und Datenquellen werden wie produktive Softwareänderungen geprüft und versioniert.

Diese Anforderungen mögen zunächst umfangreich erscheinen. Sie verhindern jedoch, dass ein nützlicher Pilot später zu einem schwer kontrollierbaren Schattenprozess wird. Sicherheitsarchitektur für KI-Agenten ist damit keine nachgelagerte Zusatzfunktion. Sie ist die Voraussetzung dafür, dass Agenten dauerhaft reale Geschäftsprozesse unterstützen dürfen.

Häufig gestellte Fragen

Was ist eine Sicherheitsarchitektur für KI-Agenten?

Eine Sicherheitsarchitektur für KI-Agenten umfasst technische und organisatorische Kontrollen für Identitäten, Berechtigungen, Daten, Modelle, Gedächtnis, Werkzeuge und Schnittstellen. Sie begrenzt nicht nur den Zugang zum System, sondern auch die möglichen Aktionen während einer Aufgabe. Hinzu kommen Protokollierung, Freigabeverfahren, Tests, Notabschaltung und geregelte Verantwortlichkeiten für den laufenden Betrieb.

Warum reicht ein API-Gateway für KI-Agenten nicht aus?

Ein API-Gateway schützt Schnittstellen, prüft Tokens und kann Datenraten begrenzen. Es bewertet jedoch nicht automatisch, ob die vom Agenten geplante Aktion zum fachlichen Auftrag passt. Agentensicherheit benötigt zusätzlich eine Richtlinienebene, die Ziel, Benutzer, Datenkategorie, Werkzeug, Parameter und mögliche Auswirkungen gemeinsam bewertet, bevor eine Aktion ausgeführt oder an ein Zielsystem übergeben wird.

Braucht jeder KI-Agent eine eigene Identität?

Produktive Agenten sollten eine eigene technische Identität besitzen. Dadurch lassen sich Aktionen zuordnen, Berechtigungen begrenzen und Tokens bei einem Vorfall gezielt entziehen. Arbeitet ein Agent ausschließlich unter dem Konto eines Mitarbeiters, übernimmt er häufig mehr Rechte als nötig. Eine eigene Identität kann dennoch mit dem aufrufenden Benutzer und dessen fachlicher Berechtigung verknüpft werden.

Was bedeutet Least Privilege bei einem KI-Agenten?

Least Privilege bedeutet, dass ein Agent nur die Rechte erhält, die er für den aktuellen Auftrag benötigt. Diese Rechte sollten möglichst zeitlich begrenzt, auf bestimmte Datensätze beschränkt und nach Lese-, Schreib-, Versand- oder Löschaktionen getrennt sein. Ein Agent zur Angebotsvorbereitung benötigt beispielsweise keinen pauschalen Zugriff auf Finanzbuchhaltung, Personalakten oder Benutzerverwaltung.

Wie lässt sich Prompt Injection bei Agenten verhindern?

Prompt Injection lässt sich nicht allein durch einen Textfilter ausschließen. Unternehmen benötigen mehrere Kontrollen: Trennung von Daten und Systemanweisungen, Kennzeichnung externer Quellen, begrenzte Werkzeuge, Prüfung von Parametern, minimale Rechte und Bestätigungen für folgenreiche Aktionen. Selbst wenn ein manipulierter Inhalt die Planung beeinflusst, darf daraus keine unkontrollierte Systemaktion entstehen.

Welche Aktionen sollten immer bestätigt werden?

Zahlungen, Bestellungen, Vertragsabschlüsse, Löschungen, Berechtigungsänderungen, öffentliche Veröffentlichungen und externe Nachrichten mit vertraulichen Inhalten sollten grundsätzlich besonders geschützt werden. Je nach Branche gilt das auch für Eingriffe in Maschinen, Produktionsanlagen oder sicherheitsrelevante Systeme. Die Freigabe muss Aktion, Zielsystem, verwendete Daten und erwartete Auswirkungen verständlich darstellen.

Wie werden MCP-Server sicher betrieben?

MCP-Server benötigen ein Inventar, definierte Eigentümer, Versionskontrolle, begrenzte Berechtigungen und Netzwerkregeln. Werkzeuge sollten vor ihrer Freigabe geprüft und nicht automatisch durch Agenten aktiviert werden. Zugangsdaten gehören in ein Secret Management. Zusätzlich sollten Unternehmen Werkzeugbeschreibungen, Parameter, ausgehende Verbindungen und Änderungen überwachen sowie nicht benötigte Funktionen konsequent deaktivieren.

Was muss bei einem Agentengedächtnis geschützt werden?

Zu schützen sind Inhalt, Herkunft, Gültigkeit und zulässige Verwendung gespeicherter Informationen. Externe Inhalte sollten nicht denselben Status erhalten wie freigegebene Unternehmensrichtlinien. Benutzer, Aufgaben und Datenklassen benötigen getrennte Speicherbereiche. Änderungen müssen protokolliert werden. Für temporäre Informationen, Zugangsdaten und personenbezogene Daten sind Ablauf-, Lösch- und Aufbewahrungsregeln erforderlich.

Welche Protokolle benötigt ein Unternehmen für KI-Agenten?

Protokolliert werden sollten Auftraggeber, Ziel, Agentenidentität, verwendete Datenquellen, ausgewählte Werkzeuge, Richtlinienentscheidungen, Aktionen, Freigaben und Fehler. Vollständige vertrauliche Inhalte gehören nicht ungefiltert in zentrale Logs. Häufig genügen Metadaten, Referenzen und Prüfsummen. Die Aufzeichnung muss eine nachträgliche Untersuchung ermöglichen, ohne selbst zu einem ungeschützten Datenspeicher zu werden.

Wie oft sollte die Sicherheit eines KI-Agenten geprüft werden?

Die Prüfung sollte vor dem Produktivstart, nach wesentlichen Änderungen und regelmäßig im Betrieb erfolgen. Relevante Änderungen sind neue Modelle, Werkzeuge, Datenquellen, Berechtigungen oder Agentenverbindungen. Zusätzlich sollten aktuelle Angriffsmuster in die Tests einfließen. Eine einmalige Abnahme genügt nicht, weil sich Reichweite und Verhalten des Systems mit jeder Erweiterung verändern können.

Können kleine und mittlere Unternehmen KI-Agenten sicher betreiben?

Ja, sofern der Einstieg begrenzt bleibt. Ein Mittelständler benötigt nicht sofort eine umfangreiche Spezialplattform. Er braucht jedoch ein Agenteninventar, eigene Identitäten, minimale Rechte, kontrollierte Werkzeuge, nachvollziehbare Aktionen und Zuständigkeiten. Besonders geeignet sind zunächst interne Assistenzprozesse, bei denen der Agent vorbereitet und ein Mitarbeiter folgenreiche Entscheidungen bestätigt.

Quellen der verwendeten Kennzahlen

• IBM: „IBM Studie: Kosten von Datenlecks sinken in Deutschland erstmals seit fünf Jahren“ – 13 Prozent kompromittierte KI-Anwendungen, 97 Prozent ohne angemessene KI-Zugriffskontrollen und durchschnittlich 3,87 Millionen Euro Kosten pro Datenleck in Deutschland.
  https://de.newsroom.ibm.com/2025-07-30-IBM-Studie-Kosten-von-Datenlecks-sinken-in-Deutschland-erstmals-seit-funf-Jahren
• Verizon: „Vulnerability exploitation top breach entry point, 2026 industry-wide DBIR finds“ – Drittanbieter waren an 48 Prozent der untersuchten Datenschutzverletzungen beteiligt.
  https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

Interessante Links

• OWASP Top 10 für agentische Anwendungen 2026
  https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• NIST-Kontrollprofile zur Absicherung von KI-Systemen
  https://csrc.nist.gov/projects/cosais
• MITRE ATLAS: Angriffstechniken und Gegenmaßnahmen für KI-Systeme
  https://atlas.mitre.org/

Alle Technologie-Artikel

Alle Artikel zur Digitalisierung im Mittelstand

Technik-Community KI im Mittelstand