KI-Agenten im Unternehmen sicher einführen

Kurzantwort: Was macht einen KI-Agenten sicher betreibbar?

Ein KI-Agent ist sicher betreibbar, wenn sein dynamischer Planungsspielraum in eine technisch erzwungene Kontrollarchitektur eingebettet ist. Der Agent darf nur freigegebene Werkzeuge mit eng begrenzten Funktionen aufrufen, erhält nur die für den aktuellen Vorgang nötigen Rechte und muss vor wirkungsreichen Aktionen eine geeignete Freigabe einholen.

Dazu kommen Schutz vor manipulierten Eingaben, Laufzeit- und Kostenlimits, nachvollziehbare Protokolle, sichere Wiederholung sowie eine Möglichkeit, Aktionen sofort zu stoppen. Sicherheit entsteht damit nicht durch das Modell allein, sondern durch Identität, Autorisierung, Prozesslogik und Betrieb rund um das Modell.

Stand 13. September 2026 ordnen NIST und OWASP diese Fragen zunehmend als eigene Betriebs- und Sicherheitsdisziplin ein. Der neue OWASP Agent Control Standard vom 1. September 2026 fordert ausdrücklich transparente, nachvollziehbare und zur Laufzeit kontrollierbare Agenten. Der Standard ist eine hilfreiche technische Orientierung, aber keine Zertifizierung und ersetzt weder Risikoanalyse noch rechtliche Prüfung des konkreten Einsatzes.

Chatbot, Workflow und KI-Agent sauber unterscheiden

Ein Chatbot erzeugt hauptsächlich Antworten. Ein klassischer Workflow durchläuft vorab definierte Zustände und Regeln. Ein KI-Agent kann dagegen ein Ziel in Zwischenschritte zerlegen, passende Werkzeuge auswählen, Ergebnisse bewerten und den nächsten Schritt dynamisch bestimmen. Diese Flexibilität wird betrieblich relevant, sobald der Agent Daten liest, Nachrichten versendet oder Zustände in einem Fachsystem verändert.

Viele Prozesse brauchen keinen frei planenden Agenten. Wenn Reihenfolge, Daten und Entscheidungen stabil sind, bleibt ein deterministischer Workflow leichter zu testen und zu verantworten. Ein Agent ist vor allem dort sinnvoll, wo Aufgaben variieren, mehrere Informationsquellen kombiniert werden müssen und sich der Lösungsweg nicht vollständig vorab modellieren lässt.

• Chatbot: formuliert Antworten, ohne selbstständig betriebliche Aktionen auszuführen
• Workflow: führt definierte Schritte, Zustände und Regeln reproduzierbar aus
• KI-Agent: wählt innerhalb gesetzter Grenzen Werkzeuge und Zwischenschritte dynamisch
• Hybrides System: Agent plant oder bereitet vor, Workflow prüft und vollzieht die verbindliche Aktion

Vor der Technik ein vollständiges Aktionsinventar erstellen

Die Frage „Was soll der Agent können?“ ist zu grob. Erfassen Sie jede Aktion mit Datenquelle, Zielsystem, möglicher Wirkung, Rücknehmbarkeit und erforderlicher Verantwortung. Aus „im CRM arbeiten“ werden beispielsweise getrennte Funktionen zum Suchen, Lesen, Entwurf anlegen, Status ändern und endgültig löschen.

Ordnen Sie Aktionen anschließend nach Wirkung. Lesen und Vorbereiten benötigen andere Kontrollen als externe Kommunikation, Zahlung, Bestellung, Berechtigungsänderung oder Löschung. Der Agent erhält nur die kleinste freigegebene Teilmenge. Nicht freigegebene Aktionen existieren für ihn technisch nicht.

• Klasse 1 – lesen: freigegebene Datensätze und Dokumente abrufen
• Klasse 2 – vorbereiten: Entwürfe, Aufgaben oder Änderungsvorschläge erzeugen
• Klasse 3 – kommunizieren: Nachrichten an definierte interne oder externe Empfänger senden
• Klasse 4 – verändern: Stammdaten, Status, Termine oder Buchungen im Zielsystem ändern
• Klasse 5 – kritisch: löschen, bezahlen, bestellen, Rechte vergeben oder produktiven Code ausrollen

Agenten mit eigener Identität und begrenzten Rechten ausstatten

Ein Agent sollte nicht mit dem Sammelzugang eines Teams oder den dauerhaften Vollrechten einer administrativen Person arbeiten. Das NIST National Cybersecurity Center of Excellence betont in seinem Konzeptpapier vom 5. Februar 2026 die eigenständige Identifikation, Authentifizierung und Autorisierung von Software- und KI-Agenten. So lässt sich eine Aktion einem Agenten, einer delegierenden Person und einem konkreten Zweck zuordnen.

Rechte sollten kurzlebig, zweckgebunden und auf einzelne Werkzeuge beschränkt sein. Wo der Agent für eine Person handelt, wird die Berechtigung aus deren Rolle abgeleitet und weiter eingeschränkt. Eine fachliche Freigabe darf keine stillschweigende Rechteausweitung bewirken. Geheimnisse gehören in einen Secret Store und werden erst beim erlaubten Tool-Aufruf bereitgestellt – nicht in Prompt, Wissensbasis oder Agentengedächtnis.

• eigene technische Identität oder nachvollziehbare delegierte Nutzeridentität
• kurzlebige Zugangstoken statt dauerhafter Schlüssel im Agentenkontext
• kleinstmöglicher Daten-, Mandanten-, Funktions- und Zeitbereich
• keine Weitergabe von Passwörtern, API-Schlüsseln oder Sitzungscookies an das Modell
• regelmäßige Rezertifizierung und sofortiger Entzug bei Rollen- oder Zweckänderung

Werkzeuge klein schneiden und im Zielsystem autorisieren

Offene Werkzeuge wie eine allgemeine SQL-Schnittstelle, ein universeller Shell-Zugang oder eine freie HTTP-Funktion vergrößern den Handlungsspielraum unnötig. Sicherer sind fachlich schmale Funktionen wie „Kundenauftrag lesen“, „Antwortentwurf speichern“ oder „Termin innerhalb eines freigegebenen Kalenders vorschlagen“. Parameter, erlaubte Werte und Datenmenge werden technisch validiert.

Die Autorisierung muss an der ausführenden API, Datenbank oder Anwendung greifen. OWASP beschreibt zu weitreichende Funktionalität, Berechtigungen und Autonomie als „Excessive Agency“ und empfiehlt unter anderem eingeschränkte Erweiterungen, minimal notwendige Rechte, Ausführung im Kontext des Nutzers und eine Freigabe für wirkungsreiche Aktionen. Der Prompt kann das gewünschte Verhalten erklären; er darf nicht die letzte Sicherheitsgrenze sein.

E-Mail, Dokument und Webseite als nicht vertrauenswürdige Eingabe behandeln

Ein Agent kann Anweisungen nicht nur aus dem Systemprompt aufnehmen. Manipulative Texte können in einer E-Mail, einem PDF, einer Webseite, einem Ticket oder der Ausgabe eines anderen Werkzeugs verborgen sein. Das BSI beschreibt diese indirekte Prompt Injection als relevantes Risiko generativer KI-Modelle. Besonders gefährlich wird sie, wenn derselbe Agent Inhalte liest und mit weitreichenden Rechten handeln darf.

Trennen Sie deshalb Systemanweisungen, Nutzereingaben, abgerufene Inhalte und Tool-Ergebnisse technisch und logisch. Externe Inhalte dürfen keine neuen Rechte, Werkzeuge oder Ziele freischalten. Zulässige Empfänger, Domains, Dateitypen und Parameter werden auf einer Positivliste geprüft. Sensible Ausgaben durchlaufen zusätzlich Inhalts- und Datenverlustkontrollen, bevor sie das Unternehmen verlassen.

• eingelesene Inhalte eindeutig als Daten markieren, nicht als Steuerbefehl
• Werkzeuge und Rechte außerhalb des Modells auf Positivlisten begrenzen
• URLs, Empfänger, Dateitypen, Mandanten und Datenfelder validieren
• verdächtige Instruktionsmuster als Signal nutzen, aber nicht als einzige Schutzmaßnahme
• Tool-Ausgaben und Agentengedächtnis vor erneuter Verwendung prüfen und begrenzen

Menschliche Freigaben nach Wirkung statt nach jedem Schritt setzen

Eine menschliche Freigabe ist nur wirksam, wenn die prüfende Person Quelle, geplante Aktion, Ziel, betroffene Daten und mögliche Folge versteht und den Vorgang ändern oder stoppen kann. Ein pauschaler Bestätigungsdialog nach jedem Tool-Aufruf erzeugt dagegen Gewöhnung. NIST warnt in seiner Einordnung vom August 2026 vor einer Ermüdung durch zu viele Human-in-the-Loop-Abfragen.

Bündeln Sie deshalb zusammengehörige Schritte zu einem verständlichen Aktionsplan. Niedrig wirkende, reversible Aktionen können innerhalb einer freigegebenen Zone automatisch laufen. Externe Kommunikation, finanzielle Wirkung, Löschung, Rechteänderung und irreversible Schritte benötigen eine ausdrückliche Freigabe – bei besonders hohen Auswirkungen gegebenenfalls nach dem Vier-Augen-Prinzip.

• vor der Freigabe: Quelle, Begründung, Zielobjekt, konkrete Änderung und Folge zeigen
• nach der Freigabe: nur exakt den dargestellten Plan ausführen; Änderungen erneut vorlegen
• Ablehnung und Korrektur als verwertbares Ergebnis in den Vorgang zurückführen
• Notfallaktionen und Sicherheitsstopps dürfen keine reguläre Freigabekette benötigen

Laufzeit, Kosten und Folgewirkung technisch begrenzen

Agenten können Schleifen bilden, dieselbe Aktion wiederholen oder einen falschen Zwischenstand immer weiter verarbeiten. Jeder Lauf benötigt deshalb Grenzen für Dauer, Modellaufrufe, Tool-Aufrufe, Datenmenge und Kosten. Ein Schritt ohne eindeutigen Erfolg bricht kontrolliert ab, statt stillschweigend weiterzulaufen.

Schreibende Aktionen werden idempotent gestaltet: Eine eindeutige Vorgangs-ID verhindert, dass ein Wiederanlauf dieselbe Nachricht, Buchung oder Bestellung doppelt ausführt. Vor kritischen Änderungen prüft das Zielsystem den aktuellen Zustand erneut. Ein zentraler Not-Aus kann Token sperren, Tool-Zugriffe schließen und laufende Jobs stoppen, ohne bereits erzeugte Nachweise zu löschen.

• maximale Laufzeit, Anzahl der Schritte, Tool-Aufrufe und Budget pro Vorgang
• eindeutige Vorgangs- und Aktionsschlüssel für sichere Wiederholung
• erneute Zustandsprüfung unmittelbar vor einer schreibenden Aktion
• Rate Limits, Parallelitätsgrenzen und Schutz vor rekursiven Agentenaufrufen
• Not-Aus, Rückfallprozess und klarer Besitzer für den Störungsfall

Entscheidung, Tool-Aufruf und Wirkung getrennt protokollieren

Ein Chatverlauf allein erklärt nicht, was in einem Fachsystem passiert ist. Ein belastbarer Nachweis verbindet Vorgangs-ID, Agenten- und Nutzeridentität, Modell- und Regelversion, verwendete Datenquellen, geplante Aktion, Freigabe, konkreten Tool-Aufruf, technische Antwort und bestätigte fachliche Wirkung.

Protokolle müssen vor unbemerkter Veränderung geschützt, zeitlich abgestimmt und für berechtigte Rollen auswertbar sein. Gleichzeitig gelten Datenminimierung und Aufbewahrungsgrenzen: Vollständige Prompts oder Dokumentinhalte gehören nicht automatisch in jedes technische Log. Für Vorfälle muss rekonstruierbar sein, welche Agentenidentität wann auf welche Daten und Funktionen zugreifen konnte.

Vier Anwendungsszenarien mit passenden Kontrollgrenzen

Ein E-Mail-Agent kann Anliegen lesen, CRM-Kontext abrufen und einen Antwortentwurf speichern. Der Versand bleibt bei sensiblen, rechtlich relevanten oder ungewöhnlichen Fällen gesperrt. Empfänger und Anhänge werden unabhängig vom Modell geprüft.

Ein Einkaufsagent kann Bedarf und freigegebene Lieferanten vergleichen und eine Bestellung vorbereiten. Preisgrenze, Budgetstelle, Lieferant, Menge und Freigaberolle werden im Bestellprozess erzwungen. Eine abweichende Kontoverbindung oder ein neuer Lieferant führt immer in die Klärung.

Ein Serviceagent kann Tickets zusammenführen, Dokumentation durchsuchen und Arbeitsaufträge vorschlagen. Er darf aber keine Sicherheitsfunktion deaktivieren oder Anlagenparameter außerhalb einer freigegebenen Zone ändern. Bei widersprüchlichen Sensordaten oder fehlendem Nachweis stoppt der Lauf.

Ein IT-Agent kann Fehlerdiagnosen sammeln und einen Änderungsvorschlag erzeugen. Produktiver Code, Berechtigungen und Infrastruktur werden erst nach Review über die bestehende Deployment- und Änderungsfreigabe verändert. Eine isolierte Testumgebung begrenzt den Schaden fehlerhafter Befehle.

Datenschutz und AI Act nach dem konkreten Einsatz prüfen

Der Begriff KI-Agent ist keine eigene Risikoklasse des AI Act. Entscheidend bleiben vorgesehener Zweck, Rolle, Einsatzgebiet und Wirkung des konkreten KI-Systems. Je nach Anwendung können Transparenz-, Betreiber- oder Hochrisikopflichten greifen. Eine Agentenarchitektur sollte deshalb Systeminventar, Modell- und Tool-Versionen, menschliche Aufsicht sowie Änderungen nachvollziehbar halten.

Werden personenbezogene Daten verarbeitet, gelten daneben die Anforderungen der DSGVO. Zweck, Rechtsgrundlage, Datenminimierung, Empfänger, Aufbewahrung, Betroffenenrechte und Schutzmaßnahmen müssen den gesamten Datenfluss einschließlich Speicher, Protokollen und Zielsystemen erfassen. Bei voraussichtlich hohem Risiko ist vor dem Einsatz eine Datenschutz-Folgenabschätzung zu prüfen. Diese Einordnung ersetzt keine Rechtsberatung im Einzelfall.

In vier Stufen vom abgegrenzten Auftrag zum produktiven Agenten

Starten Sie mit einem realen, begrenzten Auftrag und einer kleinen Werkzeugliste. Der erste Testlauf arbeitet nur lesend mit synthetischen oder freigegebenen Daten. Danach folgt ein Shadow Mode: Der Agent plant und protokolliert seine Schritte, führt sie aber nicht verbindlich aus. Fachverantwortliche vergleichen Plan und erwartetes Ergebnis anhand normaler, schwieriger und manipulierter Fälle.

Erst nach technischer und fachlicher Abnahme wird eine schmale Aktionsklasse freigegeben. Erweiterungen benötigen dieselben Prüfungen wie der erste Go-live. Neue Modelle, Tools, Datenquellen, Rechte oder Speicherfunktionen können das Risikoprofil verändern und lösen deshalb einen geregelten Änderungsprozess aus.

• 1. Auftrag abgrenzen: Ziel, Nicht-Ziele, Aktionsinventar, Daten und Verantwortliche
• 2. Read-only testen: Identität, Tool-Grenzen, Prompt-Injection-Szenarien und Protokolle
• 3. Shadow Mode: Pläne mit Fachentscheidungen vergleichen, ohne produktive Wirkung
• 4. begrenzt freigeben: kleine Aktionsklasse, Monitoring, Not-Aus und Rückfallbetrieb
• danach: nur mit dokumentierter Risiko-, Rechte- und Regressionprüfung erweitern

Der kompakte Betriebscheck vor jeder Freigabe

Ein Agent ist nicht produktionsreif, weil eine Demo funktioniert. Die Freigabe sollte fachlich und technisch bestätigen, dass der erlaubte Bereich vollständig beschrieben, erzwungen und im Störungsfall beherrschbar ist. Offene Hochrisikoaktionen bleiben deaktiviert, bis Kontrollen und Verantwortlichkeiten nachweislich greifen.

• Sind Ziel, Nicht-Ziele, erlaubte Aktionen und Stopbedingungen schriftlich freigegeben?
• Sind Identität, delegierende Person, Rechte und Geheimnisse technisch getrennt?
• Erzwingen APIs und Zielsysteme Autorisierung, Wertebereiche und Mandantengrenzen?
• Wurden indirekte Prompt Injection, falsche Tool-Ausgaben und Datenabfluss getestet?
• Sind Freigaben verständlich und werden kritische Änderungen erneut vorgelegt?
• Verhindern Limits und Idempotenz Schleifen, Doppelaktionen und unkontrollierte Kosten?
• Sind Protokolle, Monitoring, Alarmierung, Not-Aus und manueller Rückfall erprobt?
• Lösen neue Modelle, Tools, Rechte und Datenquellen eine erneute Prüfung aus?