KI-Agenten sicher in Betrieb nehmen: Identitäten, Tool-Zugriffe und Kontrollpunkte organisieren

KI-Agenten sind sicherheitlich mehr als eine weitere Oberfläche für generative KI. Anders als ein rein antwortender Copilot können sie Informationen aus Unternehmensquellen abrufen, Kontext oder Memory speichern, Tools und APIs aufrufen und Arbeitsschritte automatisiert ausführen. Entscheidend ist daher nicht allein, welches Modell verwendet wird. Maßgeblich sind die delegierte Autorität, die erreichbaren Daten und Systeme sowie die Kontrollmechanismen zwischen einer Modellentscheidung und einer tatsächlichen Aktion.

Für den Produktiveinsatz genügt es nicht, einen erfolgreichen Pilotbetrieb fortzuschreiben. Unternehmen sollten agentische KI als neue oder wesentlich geänderte IT-gestützte Geschäftsprozesse behandeln und in ISMS, Datenschutzmanagement, Lieferantenrisikomanagement, Incident Response und gegebenenfalls BCMS einordnen. Das Kontrollmodell von ISACA bietet dafür eine praxisnahe Grundlage. Die darin beschriebenen Maßnahmen sind Sicherheits- und Governance-Empfehlungen, jedoch keine eigenständige, pauschal gesetzlich vorgeschriebene Architektur.

Warum ein KI-Agent vor allem delegierte Handlungsbefugnis bedeutet

Das besondere Risikoprofil entsteht, wenn ein Agent untrusted Content verarbeitet und diesen mit Unternehmensdaten, Tool-Zugriffen oder automatisierten Workflows verbindet. Zu den relevanten Gefährdungen zählen Prompt Injection, missbräuchliche Tool-Nutzung, übermäßige Handlungsautonomie, Memory Leakage sowie Kompromittierungen von Modellen oder Lieferketten. Die zentrale Freigabefrage lautet deshalb nicht: „Kann der Agent eine Aufgabe lösen?“ Sie lautet: „Worauf kann er zugreifen, was darf er tun, welche Autorität erhält er – und wer bleibt verantwortlich?“

Die Antwort sollte in einer risikobasierten Delegationsmatrix festgehalten werden. Sie unterscheidet etwa zwischen Aktionen, die ein Agent nur empfehlen, vorbereiten, nach menschlicher Freigabe ausführen oder grundsätzlich nicht ausführen darf. Für destruktive, finanzielle, rechtliche, regulierte oder irreversible Handlungen empfiehlt ISACA verbindliche menschliche Freigaben. Ergänzend können Vier-Augen-Prinzip, Step-up Authentication oder eine Transaktionsbestätigung erforderlich sein.

Das Inventar als Sicherheitsfundament

Ohne vollständiges Inventar ist weder eine belastbare Risikoentscheidung noch eine wirksame Untersuchung im Sicherheitsvorfall möglich. Der Agenten-Steckbrief sollte mindestens den geschäftlichen Zweck sowie einen fachlichen und technischen Owner enthalten. Erfasst werden sollten außerdem Modell und Provider, Orchestrierung, Tools, Plugins, APIs, Datenquellen, Vector Stores, Memory Stores, Netzwerkwege, Abhängigkeiten und externe Anbieter.

Ebenso wichtig sind Datenklassen, Herkunftsdokumentation und Vertrauensgrenzen: zwischen menschlichen Nutzern, Agent Runtime, Modellprovider, Orchestrierung, Tool-Ausführung, Unternehmenssystemen und Freigabeoberflächen. Diese Sicht macht transparent, an welchen Übergängen Daten, Instruktionen oder Berechtigungen unzulässig erweitert werden könnten. Sie schafft zugleich die Grundlage für Änderungsmanagement und regelmäßige Risikoüberprüfungen.

Eigene Agentenidentitäten statt breit berechtigter Bot-Konten

Agenten sind als nichtmenschliche Identitäten zu behandeln. Geteilte Konten, langlebige Tokens oder breit berechtigte Bot-Accounts erschweren Verantwortungszuordnung, Begrenzung und Widerruf. ISACA empfiehlt getrennte Identitäten je Agent und Workload, möglichst auf Basis föderierter Zugriffe und kurzlebiger, automatisch rotierter Credentials. Berechtigungen sollten nach Least Privilege für jedes Tool, jede Datenquelle und jeden Speicherbereich vergeben werden.

Praktisch bedeutet dies eine klare Trennung zwischen menschlichen Nutzern, Agent Runtime, Tool Runner sowie Admin- und Operator-Funktionen. RBAC, ABAC und zeitlich begrenzte Just-in-Time-Eskalationen können sensible Funktionen absichern. Wichtig ist, Berechtigungsprüfungen nicht beim Tool-Aufruf enden zu lassen: Auch Retrieval und Kontextzugriffe aus Memory Stores benötigen eine explizite Autorisierung. Gerade dort können sensible Informationen in spätere Entscheidungen des Agenten einfließen.

Zwischen Modell und Wirkung: eine harte Policy-Schicht

Ein Sprachmodell sollte nicht die letzte Instanz für Sicherheits- oder Geschäftsentscheidungen sein. Tool- und API-Zugriffe gehören hinter ein API Gateway, einen Action Broker oder einen deterministischen Policy Enforcement Point. Diese Schicht prüft vor der Ausführung Aktionstyp, Zielsystem, Akteursidentität, Berechtigung, Geschäftsregel, Risikoschwelle und erforderliche Freigabe.

Damit wird technisch erzwungen, dass eine plausibel klingende Modellantwort nicht unmittelbar zu einer wirksamen Aktion wird. Je nach Risikoklasse kann die Policy-Schicht eine Aktion ablehnen, auf einen begrenzten Umfang reduzieren, eine Freigabe anfordern oder den Agenten auf einen Read-only- beziehungsweise Recommendation-only-Modus beschränken. Die australische National AI Centre betont, dass wirksame menschliche Aufsicht neben Eingriffsfähigkeit und klaren Eskalationswegen auch ausreichendes Verständnis, Training und Ressourcen erfordert. Ein formaler Human-in-the-Loop-Schritt ohne echte Entscheidungsmöglichkeit ist keine belastbare Kontrolle.

Untrusted Content, Prompt Injection und Memory absichern

Prompt Injection ist nicht auf direkt eingegebene Nutzertexte beschränkt. Das NIST Generative AI Profile weist darauf hin, dass indirekte Prompt Injections über Inhalte erfolgen können, welche eine LLM-integrierte Anwendung abruft. Demonstrierte Folgen umfassen unter anderem Datenabfluss und die Remote-Ausführung schädlichen Codes.

Webseiten, E-Mails, PDFs, Anhänge, abgerufene Dokumente und Tool-Outputs sind deshalb als nicht vertrauenswürdige Eingaben zu behandeln. Sie dürfen Informationen liefern, aber weder die Instruktionshierarchie überschreiben noch selbstständig Tool-Aktionen auslösen. Herkunft und Vertrauensniveau eines Inhalts sollten in Autorisierungsentscheidungen einfließen. Ergänzend sind Allowlists, Parametergrenzen und eine getrennte Geheimnisverwaltung sinnvoll.

Memory und Kontext benötigen ebenfalls ein Zero-Trust-Modell. ISACA empfiehlt eine Isolation nach Mandant, Nutzer und Use Case, begründete Aufbewahrungs- und TTL-Grenzen, autorisiertes Retrieval sowie Prüfungen von Herkunft und Integrität gespeicherter und abgerufener Kontexte. Damit lassen sich Risiken durch Memory Leakage und Memory Poisoning begrenzen. Datenklassifikation muss sich folglich nicht nur auf Primärdaten erstrecken, sondern auch auf Prompts, Retrieval, Memory, Logs, Traces und Outputs.

Nachweisbarkeit und Notbetrieb vor dem Go-live

Für Untersuchung und Reaktion benötigt der Betrieb zentrale, manipulationsresistente Telemetrie. Unter angemessener Redaktion sensibler Daten sollten insbesondere Prompts, Antworten, abgerufene Quellen, Content-Hashes, Tool-Aufrufe, Aktionsentscheidungen, Freigaben, Identitätskontext und Policy-Verstöße nachvollziehbar sein. Diese Daten dienen nicht nur forensischen Zwecken, sondern auch der Kontrolle von Berechtigungen, Fehlerraten und unerwarteten Aktionsketten.

Agentenspezifische Incident-Response-Playbooks sollten mindestens Prompt Injection, kompromittierte Tools oder Credentials, Provider-Kompromittierung, Datenabfluss, mandantenübergreifende Offenlegung und Memory Poisoning abdecken. Vor der Produktivsetzung muss getestet werden, ob Teams Tools oder Credentials sperren, einen Agenten in den Read-only-Modus versetzen, Memory isolieren oder löschen, Modell-, Prompt-, Policy- und Berechtigungsversionen zurückrollen und Beweise sichern können.

Erforderlich sind zudem global und pro Fähigkeit getrennte Kill Switches sowie sichere Rückfallmodi. Kritische Geschäftsprozesse müssen bei deaktiviertem Agenten manuell fortgeführt werden können. Adversariale Tests und Regressionstests sollten als Release Gate etabliert werden, etwa für direkte und indirekte Prompt Injection, Datenexfiltration, unsichere Tool-Nutzung, Memory Poisoning, SSRF, bösartige Dokumenteninjektion und unerlaubte Aktionen. NIST empfiehlt, Ergebnisse von Pre-Deployment-Tests den für die Release-Freigabe verantwortlichen Rollen zugänglich zu machen.

Regulatorische Einordnung und kontrollierte Produktivfreigabe

Ein KI-Agent ist nicht allein wegen seiner Agentenfähigkeit automatisch ein Hochrisiko-KI-System. Die Einordnung nach dem AI Act hängt vom vorgesehenen Verwendungszweck und den gesetzlichen Kategorien ab. Für tatsächlich erfasste Hochrisiko-KI-Systeme verlangen insbesondere Art. 9 ein fortlaufendes Risikomanagement einschließlich Tests vor der Inbetriebnahme und Art. 14 wirksame menschliche Aufsicht. Der AI Act ist seit dem 1. August 2024 in Kraft; weitere Vorschriften gelten seit dem 2. August 2026 und werden durch AI Office sowie nationale Behörden durchgesetzt. Maßgeblich sind die Verordnung (EU) 2024/1689 und die Information der Europäischen Kommission.

Verarbeitet der Agent personenbezogene Daten, sind zudem risikoorientierte technische und organisatorische Maßnahmen nach Art. 32 DSGVO zu berücksichtigen. Für in Deutschland erfasste wichtige und besonders wichtige Einrichtungen verlangt das BSIG geeignete, verhältnismäßige und wirksame Maßnahmen für genutzte IT-Systeme, Komponenten und Prozesse; die Geschäftsleitung muss deren Umsetzung überwachen. Eine Produktivfreigabe sollte daher erst erfolgen, wenn Risiko- und Datenschutzbewertung, Owner-Freigaben, Berechtigungsrezertifizierung, Lieferantenprüfung, Tests, Monitoring, Incident-Übung und Rückfalltest dokumentiert vorliegen. Dies ist keine individuelle Rechtsberatung.