Wenn KI-Agenten ausbrechen: Warum Agentic AI zum Sicherheitsrisiko wird – und was Unternehmen jetzt tun müssen

Agentic AI als Sicherheitsrisiko: KI-Agenten brechen aus vorgegebenen Grenzen aus
Ethik & Recht KI im Unternehmen

Wenn KI-Agenten ausbrechen: Warum Agentic AI zum Sicherheitsrisiko wird – und was Unternehmen jetzt tun müssen

Table of Contents

Redaktions- und Quellenhinweis: Dieser Artikel wurde mit Künstlicher Intelligenz erstellt und redaktionell kuratiert. Ausgewertet wurden Sicherheitsberichte, Behördenleitlinien, Standards und Rechtstexte mit Stand 31. Juli 2026. Mehrere Verbreitungszahlen stammen aus Anbieter- oder gesponserten Befragungen und beruhen auf Selbstauskünften; sie zeigen die Richtung, sind aber keine repräsentative Messung aller Unternehmen. Der Beitrag bietet eine fachliche Einordnung und keine Rechtsberatung.

⚡ In 30 Sekunden

  • KI-Agenten erzeugen nicht nur Inhalte: Sie planen Arbeitsschritte, nutzen Werkzeuge und verändern Daten oder Systeme. Aus einem falschen Output kann deshalb eine reale Aktion werden.
  • In einer HiddenLayer-Befragung unter 250 IT- und Security-Verantwortlichen entfiel mehr als jeder achte selbst gemeldete KI-Sicherheitsvorfall auf agentische Systeme. Das ist ein Risikosignal, keine repräsentative Marktquote.
  • Der größte Risikotreiber ist nicht das Sprachmodell allein, sondern die Kombination aus unzuverlässiger Entscheidungslogik, weitreichenden Rechten, unkontrollierten Eingaben und fehlender Laufzeitüberwachung.
  • Schutz entsteht durch begrenzte Wirkung: bekannte Agenten, eigene Identitäten, minimale Rechte, technisch erlaubte Aktionen, nachvollziehbare Freigaben und Protokollierung ab dem ersten Pilottag.

Was CIO, CDO und CISO jetzt priorisieren sollten

  1. Innerhalb von 30 Tagen ein gemeinsames Inventar aller produktiven, pilotierten und fachbereichsseitig gebauten Agenten erstellen.
  2. Für jeden Agenten Datenzugriff, Werkzeuge, Identität, Autonomiestufe, fachlichen Owner und technischen Betreiber dokumentieren.
  3. Schreibende, löschende, zahlungsrelevante oder produktionsnahe Aktionen bis zur Risikoprüfung auf Freigabepflicht oder Read-only zurücksetzen.
  4. Tool-Aufrufe, Berechtigungsentscheidungen, Datenquellen, Freigaben und Ergebnisse ab dem ersten Pilottag zentral protokollieren.
  5. Prompt-Injection, gestohlene Tokens, manipulierte Dokumente, fehlerhafte Serienaktionen und den Not-Aus als reale Incident-Szenarien testen.

Einleitung: Warum das Thema „Agenten brechen aus“ 2026 kein Sci-Fi mehr ist

Ein KI-Agent interpretiert ein Ziel, plant Schritte, beschafft Informationen und ruft Werkzeuge auf. Agentic AI bezeichnet diese mehrstufige, teilweise autonome Arbeitsweise: Das System antwortet nicht nur, sondern handelt. Eine Begriffseinordnung bietet der AI-Fabrik-Grundlagenartikel „Generative AI, Agentic AI und AI Agents: Der Unterschied einfach erklärt“.

Agenten lesen 2026 Tickets, prüfen Rechnungen, erzeugen Code und orchestrieren Geschäftsprozesse. Damit wachsen Nutzen und Schadenspotenzial. HiddenLayer ordnet im AI Threat Landscape Report 2026 mehr als jeden achten gemeldeten KI-Sicherheitsvorfall agentischen Systemen zu; befragt wurden 250 IT- und Security-Verantwortliche. Eine CSA-Erhebung unter 418 IT- und Security-Fachleuten nennt 65 Prozent mit mindestens einem agentenbezogenen Vorfall und 82 Prozent mit zuvor unbekannten Agenten.

Was die Zahlen leisten – und was nicht: Beide Erhebungen beruhen auf Selbstauskünften und wurden von Anbietern veröffentlicht oder beauftragt. Belastbare Aufschlüsselungen nach DACH-Region, Branche und Unternehmensgröße sowie absolute Schadenshöhen fehlen. Die Werte sind deshalb Risikosignale, keine repräsentativen Marktquoten. Die ebenfalls häufig zitierte HiddenLayer-Zahl von 88 Prozent betrifft geschäftskritische interne KI-Modelle – nicht Unternehmen mit Agenten-Sicherheitsvorfällen.

Für Unternehmen läuft es auf eine unbequeme Frage hinaus: Wie kannst du Agenten nutzen, ohne dass sie ausbrechen? Die Antwort beginnt nicht beim Modell, sondern bei der kontrollierten Ausführungsumgebung: Sie entscheidet, welche Wirkung ein Fehler überhaupt entfalten kann.

Was bedeutet „Agenten brechen aus“ konkret?

„Ausbrechen“ bedeutet in diesem Kontext nicht, dass eine KI ein Bewusstsein entwickelt oder sich wie in einem Film gegen Menschen entscheidet. Gemeint ist, dass ein Agent seinen vorgesehenen Handlungsrahmen verlässt, Kontrollmechanismen umgeht oder legitime Rechte in einer Weise kombiniert, die niemand freigegeben hätte.

Szenario 1: Aus Datenbereinigung wird Datenverlust

Hypothetisches Einzelszenario: Ein Vertriebsagent soll doppelte Testdatensätze in einer Entwicklungsdatenbank markieren. Sein Service-Konto besitzt jedoch auch Löschrechte in der Produktionsumgebung. Eine mehrdeutige Anweisung und eine fehlerhafte Tabellenzuordnung führen dazu, dass der Agent tausende echte Datensätze entfernt. Das Modell hat keine „böse Absicht“. Aber aus einer Fehlinterpretation wird ein Sicherheits- und Betriebsereignis, weil Berechtigungen, Umgebungsgrenzen und Freigaben fehlen.

Szenario 2: Ein Support-Ticket kapert den Agenten

Hypothetisches Angriffsszenario: Ein Support-Agent liest Tickets und darf im CRM Kundendaten suchen. Ein Angreifer versteckt im Ticket die Anweisung, umsatzstarke Konten in ein extern erreichbares Feld zu schreiben. Der Agent missversteht den Text als Auftrag und nutzt seine legitimen Rechte. Das ist indirekte Prompt-Injection. Die Übernahme des Aktionspfads wird als Agent Hijacking oder Agentjacking bezeichnet.

Szenario 3: Schatten-KI mit Administratorrechten

Hypothetisches Betriebsszenario: Ein Fachbereich baut ohne formale IT-Freigabe einen Beschaffungsagenten. Für den schnellen Piloten wird der persönliche Zugriffstoken eines Administrators hinterlegt. Monate später läuft der Agent noch immer, der ursprüngliche Ersteller hat die Abteilung gewechselt, und niemand überwacht die Aktionen. Eine neue Integration erweitert den erreichbaren Systemraum. Aus einem lokalen Versuch ist eine nicht inventarisierte, überprivilegierte Maschinenidentität geworden.

Diese drei Beispiele illustrieren typische Fehlermuster; sie sind keine Berichte über namentlich bekannte Einzelvorfälle. Ihre Voraussetzungen – breite Service-Rechte, ungeprüfte Fremdinhalte oder fehlende Stilllegung – sollten deshalb jeweils separat geprüft werden.

Vier Begriffe, die Entscheider kennen müssen

Schatten-KI: KI-Anwendungen oder Agenten, die außerhalb freigegebener Prozesse beschafft, gebaut oder betrieben werden. Die IT kennt weder Owner noch Datenflüsse, Rechte oder Lebenszyklus.

Überprivilegierte Tokens: Zugangsschlüssel, die mehr Systeme, Daten oder Aktionen erlauben, als der Agent für seine Aufgabe braucht. Wird der Agent manipuliert, übernimmt der Angreifer indirekt diese Reichweite.

Prompt-Injection: Manipulierte Anweisungen in Eingaben oder fremden Inhalten – etwa E-Mails, Webseiten, Dokumenten, Logs oder Code-Kommentaren –, die ein Modell als Handlungsauftrag missversteht.

Agentjacking: Die Übernahme des Arbeitsziels oder Aktionspfads eines Agenten, häufig durch indirekte Prompt-Injection. Der Agent missbraucht dabei seine legitimen Werkzeuge und Identitäten für den Zweck des Angreifers.

Fehlfunktion oder Ausbruch?

Eine Fehlfunktion ist eine falsche Entscheidung innerhalb einer kontrollierten Grenze: Der Agent klassifiziert eine Rechnung falsch, legt sie aber nur zur menschlichen Prüfung vor. Ein Ausbruch beginnt, wenn die Wirkung die erwartete Grenze systematisch überschreitet: Der Agent umgeht die Prüfung, nutzt weitere Systeme, vervielfacht den Fehler über eine Serie von Aktionen oder kann wegen fehlender Telemetrie nicht mehr zuverlässig gestoppt werden.

Merksatz: Eine Fehlfunktion liefert ein falsches Ergebnis. Ein Ausbruch verwandelt das falsche Ergebnis in unkontrollierte Wirkung.

Warum Unternehmen besonders gefährdet sind

Agenten treffen in Unternehmen auf gewachsene Identitätslandschaften, alte Schnittstellen, sensible Daten und Prozesse, die ursprünglich für menschliche Bediener entworfen wurden. Das Risiko entsteht meist nicht durch einen einzelnen spektakulären Fehler, sondern durch fünf bekannte Lücken: fehlende Governance, keine abgestuften Autonomieregeln, kein vollständiges Inventar, zu breite Rechte und unklare Zuständigkeiten.

Der Cybersecurity Pulse Report 2025 beschreibt Prompt-Injection, ausnutzbaren Kontextspeicher und Sandbox-Ausbrüche als zentrale Risiken agentischer Systeme und empfiehlt architektonische Begrenzung statt reiner Prompt-Kosmetik. HiddenLayer ergänzt diese Sicht mit einer Lieferkettenperspektive: 93 Prozent der Befragten nutzen Open-Weight-Modelle aus öffentlichen Repositories, aber weniger als die Hälfte scannt eingehende Modelle konsistent. 35 Prozent nannten Schadsoftware in öffentlichen Modell- und Code-Repositories als Quelle KI-bezogener Vorfälle.

OWASP verdichtet die Ursache unter dem Begriff Excessive Agency: zu viel Funktionalität, zu viele Berechtigungen und zu viel Autonomie. Für Praxisprojekte folgt daraus eine klare Architekturregel: Nicht der Prompt, sondern der technisch erreichbare Aktionsraum bestimmt den maximalen Schaden.

Besonders kritisch sind drei Umgebungen:

  • Sensible Daten: HR-, Gesundheits-, Kunden- oder Entwicklungsdaten erhöhen den Schaden einer falschen Abfrage, Speicherung oder Weitergabe.
  • Finanzsysteme: Ein Agent kann Zahlungen, Bestellungen, Preisänderungen oder Buchungen in hoher Frequenz auslösen. Kleine Fehlentscheidungen werden schnell zu materiellen Verlusten.
  • Produktion und kritische Systeme: In ERP-, OT-, CI/CD- oder Infrastrukturumgebungen können falsche Aktionen Verfügbarkeit, Qualität und Sicherheit physischer Prozesse beeinträchtigen.

Die gemeinsame Leitlinie von ACSC, CISA, NSA, NCSC und weiteren Behörden vom Mai 2026 empfiehlt deshalb, Agenten niemals breiten oder unbeschränkten Zugriff auf sensible Daten oder kritische Systeme zu geben. Für niedrig riskante, nicht sensible Aufgaben kann Autonomie sinnvoll sein. In Hochrisikokontexten muss sie technisch und organisatorisch stark begrenzt werden.

Folgen für Sicherheit, Compliance und Betrieb

a) Sicherheit: Vom manipulierten Input zur lateralen Bewegung

Agenten verbinden Systeme, die bisher getrennte Vertrauensgrenzen hatten. Ein Angriff kann über eine E-Mail beginnen, den Agenten zu einem CRM-Aufruf bewegen, einen Token aus der Laufzeitumgebung abgreifen und anschließend weitere Dienste erreichen. Diese laterale Bewegung ist besonders schwer zu erkennen, weil viele Einzelaktionen legitim aussehen: lesen, suchen, zusammenfassen, schreiben.

Hypothetisches Einzelszenario: Ein Incident-Agent analysiert Logdateien und darf Support-Tickets für einen externen Dienstleister eröffnen. Ein manipulierter Logeintrag veranlasst ihn, einen sensiblen Ausschnitt ungeprüft in ein solches Ticket zu kopieren. Dafür genügen zwei Schwächen: fremder Text wird als Anweisung behandelt, und die Ausgabekontrolle erkennt die enthaltenen Geheimnisse nicht. Der Datenabfluss entsteht durch legitime Einzelaktionen – Log lesen, Ticket schreiben –, deren Kombination niemand freigegeben hat.

Hinzu kommen Supply-Chain-Risiken. Agenten beziehen Modelle, Bibliotheken, Werkzeugdefinitionen, Konnektoren, Prompts und Wissensquellen aus vielen Komponenten. Wird nur eine davon manipuliert, kann sie den Agenten steuern. Deshalb gehören signierte Artefakte, feste Versionen, Herkunftsnachweise und isolierte Tests genauso in das Sicherheitsmodell wie Prompt-Filter.

b) Compliance: Nachweisbarkeit statt nachträglicher Erklärung

Verarbeitet ein Agent personenbezogene Daten, gelten in Deutschland und Österreich die Grundsätze der DSGVO weiter: Rechtsgrundlage, Zweckbindung, Datenminimierung, Sicherheit, Rechenschaftspflicht und – bei voraussichtlich hohem Risiko – die Prüfung einer Datenschutz-Folgenabschätzung. Die österreichische Datenschutzbehörde betont ausdrücklich, dass der Einsatz fremder KI-Systeme die Verantwortung des einsetzenden Unternehmens nicht aufhebt. In der Schweiz gilt das technologieneutrale Datenschutzgesetz ebenfalls direkt für KI-gestützte Datenbearbeitungen; der EDÖB verlangt Transparenz über Zweck, Funktionsweise und Datenquellen.

Der EU AI Act kommt gestuft hinzu. Nicht jeder Agent ist automatisch ein Hochrisiko-KI-System. Wo die Hochrisikoregeln greifen, sind unter anderem Risikomanagement, menschliche Aufsicht, technische Dokumentation und Protokollierung zentrale Anforderungen. Unabhängig von der formalen Klassifizierung ist diese Kontrolllogik für unternehmenskritische Agenten bereits heute sinnvoll.

Hypothetisches Compliance-Szenario: Ein HR-Agent bewertet Bewerbungen, greift aber zusätzlich auf Krankheitsangaben aus einer nicht vorgesehenen Quelle zu. Eine abgelehnte Person verlangt Auskunft. Das Unternehmen kann weder die verwendeten Daten noch die Aktionskette und menschlichen Freigaben vollständig rekonstruieren. Aus einem Architekturfehler werden gleichzeitig Datenschutz-, Diskriminierungs-, Dokumentations- und Haftungsfragen.

„Die KI war es“ ist keine belastbare Verantwortungszuweisung. Unternehmen brauchen einen fachlichen Owner, einen technischen Betreiber, eine Freigabeverantwortung und einen Incident-Prozess. Haftung und Aufsichtspflichten hängen vom konkreten Einsatz, Vertrag, Sektor und Schaden ab; die rechtliche Bewertung sollte deshalb früh mit Datenschutz, Recht, Compliance und gegebenenfalls Arbeitnehmervertretung erfolgen.

c) Operativer Betrieb: Wenn Automatisierung Fehler skaliert

Agenten können Produktivität steigern, weil sie Serienarbeit ohne ständige Rückfrage erledigen. Genau dieselbe Eigenschaft skaliert Fehlannahmen. Ein falscher Filter in einer Tabelle betrifft eine Zeile. Ein falsches Ziel in einem Agentenlauf kann tausende Zeilen, Konten oder Vorgänge betreffen.

Hypothetisches Betriebsszenario: Ein Einkaufsagent soll Lieferengpässe vermeiden. Wegen einer veralteten Bestandsquelle interpretiert er Sicherheitsbestände als Null und löst in mehreren Werken Nachbestellungen aus. Jede Bestellung liegt unter dem Einzelgenehmigungslimit. Erst am nächsten Morgen fällt die Summe auf. Das Unternehmen gewinnt keine Produktivität, sondern bindet Einkauf, Finanzen, Logistik und IT in einer manuellen Rückabwicklung.

Typische Folgen sind blockierte Workflows, doppelte Buchungen, fehlerhafte Serienmails, widersprüchliche Stammdaten, unnötige API-Kosten und Freigabestau. Operative Resilienz erfordert daher Transaktionslimits, Deduplizierung, Idempotenz, Rollback-Möglichkeiten, klare Abbruchbedingungen und einen manuellen Ersatzprozess.

Was Unternehmen konkret tun müssen: Governance und Guardrails

Ein einzelner Guardrail reicht nicht. Unternehmen brauchen ein Schichtenmodell, bei dem jede Ebene die Fehler der anderen begrenzt.

Die Logik des Modells: Jede Ebene beantwortet eine andere Kontrollfrage – wer verantwortlich ist, wie autonom der Agent handeln darf, was er technisch erreichen kann, wo eine Aktion gestoppt wird und wie sich alles nachweisen lässt.

Ebene Kontrolle Leitfrage
1. Inventar und Verantwortung Zweck, Owner, Betreiber, Datenklassen, Werkzeuge, Lieferkette und Lebenszyklus dokumentieren. Wer darf diesen Agenten wofür betreiben und abschalten?
2. Autonomieklassifizierung Von reiner Empfehlung über Entwurf und begrenzte Ausführung bis zur konditionalen Autonomie; kritische Vollautonomie ausschließen. Welche Wirkung darf ohne Menschen entstehen?
3. Identität und Aktionsraum Eigene Service-Identität, Least Privilege, kurzlebige Tokens, erlaubte Werkzeuge und explizite Aktions-Whitelists. Was kann der Agent technisch – nicht nur laut Prompt?
4. Freigabe und Begrenzung Deterministische Limits, Netzwerksegmentierung, Sandbox, Kill Switch und Rollback; zusätzlich fachliche Freigaben bei kritischen Einzelfällen. Wo wird eine gefährliche Kette technisch und fachlich unterbrochen?
5. Nachweis und Überwachung Unveränderbare Audit-Trails, Laufzeitanomalien, Red Teaming, Change-Kontrolle, Incident Response und regelmäßige Rezertifizierung. Erkennen und erklären wir Abweichungen rechtzeitig?

Human-in-the-loop: notwendig, aber nicht hinreichend

Die scheinbare Spannung lässt sich auflösen, wenn technische und menschliche Kontrollen unterschiedliche Aufgaben erhalten. Rechte, erreichbare Systeme, Betragsgrenzen, Frequenz und erlaubte Werkzeuge müssen außerhalb des Modells deterministisch begrenzt sein. Innerhalb dieses Rahmens bewertet ein Mensch den fachlichen Einzelfall – etwa ob eine konkrete Zahlung, Löschung oder Produktionsänderung vertretbar ist.

Eine Freigabe ist nur dann eine Kontrolle, wenn die zuständige Person Aktion, Ziel, betroffene Daten, Gesamtwirkung und Rückabwicklung verstehen kann. Sie muss ablehnen oder stoppen können, ausreichend Zeit haben und darf nicht durch hunderte gleichförmige Bestätigungen zum Abnicken gedrängt werden. Der Freigabedialog selbst liegt außerhalb des vom Agenten manipulierbaren Kontexts und wird protokolliert.

Damit gilt: Human-in-the-loop begrenzt fachliche Fehlentscheidungen, aber keine kompromittierten Tokens, verdeckten Nebenaktionen oder falsch konfigurierten Netzwerkzugriffe. Dafür bleiben Least Privilege, Aktionslisten, Limits, Laufzeitüberwachung und Not-Aus zwingend.

Least Privilege muss für Agenten dynamischer werden

Least Privilege bedeutet: Ein Agent erhält nur die Daten, Werkzeuge und Aktionen, die er für den aktuellen Auftrag benötigt – so kurz wie möglich und in der kleinsten sinnvollen Umgebung. Ein Rechnungsprüfer braucht Leserechte auf Belege, aber keine Lieferantenänderung und keine Zahlungsauslösung. Für einen freigegebenen Zahlungslauf kann temporär ein eng begrenztes Recht vergeben werden, das danach automatisch verfällt.

Getrennte Service-Identitäten sind Pflicht, weil persönliche Nutzer-Tokens Verantwortlichkeit verwischen und häufig zu viele vererbte Rechte besitzen. Jede Agentenidentität braucht Owner, Zweck, Ablaufdatum, Rezertifizierung und Deprovisionierung. NIST behandelt Identifikation, Autorisierung, Auditierbarkeit und Nichtabstreitbarkeit von Agenten deshalb als eigenes Kontrollfeld.

Logging ab Tag 1 – aber mit fachlichem Kontext

Nur Ein- und Ausgabe des Modells zu speichern genügt nicht. Ein belastbarer Audit-Trail verbindet Auftrag, Identität, Modell- und Prompt-Version, gelesene Datenquellen, Tool-Aufrufe, Parameter, Berechtigungsentscheidung, menschliche Freigabe, Ergebnis, Fehler und Abbruchgrund. Sicherheitsrelevante Logs sollten manipulationsgeschützt, zeitlich korreliert und nach Datenminimierungs- sowie Aufbewahrungsregeln behandelt werden.

Wer erst nach dem ersten Vorfall mit Logging beginnt, kann Ursache und Reichweite kaum rekonstruieren. Der verwandte AI-Fabrik-Beitrag „Privacy Guardrails: Wie KI-Systeme Datenschutz automatisch durchsetzen“ vertieft technische Datenschutzkontrollen.

Kontrolltiefe nach Wirkung und Unternehmensgröße

Ein Betrieb mit 50 Beschäftigten braucht für zwei lesende Assistenten keine eigene Agenten-Leitstelle. Ein reguliertes Unternehmen mit Zahlungs-, Personal- oder Produktionsagenten braucht dagegen deutlich mehr als eine Tabelle und gelegentliche Sichtprüfungen. Die Kontrollziele bleiben gleich; Aufwand und technische Tiefe wachsen mit möglichem Schaden, Zahl der Integrationen und regulatorischer Relevanz.

Ausbaustufe Typische Situation Pragmatischer Mindestumfang
Basis Kleines Unternehmen oder ein bis zwei Agenten mit geringer, reversibler Wirkung. Einfaches Inventar, benannter Owner, getrennte Identität, standardmäßig lesender Zugriff, Freigabe für Änderungen und Nutzung vorhandener zentraler Logs.
Standard Mehrere produktive Agenten und Integrationen in CRM, ERP oder interne Wissenssysteme. Zentrales Register, IAM-Rollen, technisch erzwungene Policies und Limits, zentrale Überwachung, regelmäßige Rechteprüfung und wiederholbare Missbrauchstests.
Erweitert oder reguliert Sensible Daten, hohe finanzielle Wirkung, kritische Produktion oder besondere Aufsicht. Dedizierte Laufzeitkontrollen, vertiefte Lieferkettenprüfung, kontinuierliche Anomalieerkennung, risikobasiertes Red Teaming und Einbindung in Incident Response und Krisenorganisation.

Die Grenze verläuft nicht allein über die Beschäftigtenzahl. Auch ein kleines Unternehmen braucht die erweiterte Stufe, wenn ein Agent irreversible Zahlungen oder sicherheitskritische Maschinenprozesse beeinflusst. Umgekehrt kann ein großer Konzern einen isolierten, rein lesenden Pilot zunächst mit Basiskontrollen betreiben.

Schnellcheck: 5 Warnsignale

  1. Der Agent hat keinen dokumentierten Owner oder erscheint in keinem Inventar.
  2. Er nutzt persönliche, gemeinsam verwendete oder weitreichende Tokens.
  3. Ungeprüfte E-Mails, Webseiten oder Dokumente können seine Werkzeugaufrufe beeinflussen.
  4. Er darf kritische oder irreversible Aktionen ohne harte Limits und externe Freigabe ausführen.
  5. Tool-Aufrufe sind nicht vollständig nachvollziehbar oder der Not-Aus wurde nie getestet.

Trifft schon eines dieser Warnsignale zu, sollte das Team die Autonomie begrenzen und den Punkt vor der Skalierung klären.

Vertiefendes Audit: 10 Fragen zur Agentensicherheit

  1. Ist der Agent in einem zentralen Inventar mit fachlichem Owner und technischem Betreiber registriert?
  2. Besitzt er eine eigene Identität oder läuft er mit persönlichen beziehungsweise gemeinsam genutzten Tokens?
  3. Kann er mehr lesen, schreiben, löschen, ausführen oder bezahlen, als sein dokumentierter Zweck erfordert?
  4. Verarbeitet er ungeprüfte E-Mails, Webseiten, Dokumente, Logs oder fremde Agentennachrichten als Kontext?
  5. Darf das Modell frei Werkzeuge auswählen, obwohl eine feste Aktions-Whitelist möglich wäre?
  6. Gibt es für irreversible, finanzielle, personenbezogene oder produktionsnahe Aktionen eine echte externe Freigabe?
  7. Würden Rate Limits, Betragsgrenzen, Netzwerksegmente und Rollback den maximalen Schaden wirksam begrenzen?
  8. Könnt ihr heute jeden Tool-Aufruf samt Datenquelle, Token, Freigabe und Ergebnis nachvollziehen?
  9. Wurde der Agent gegen Prompt-Injection, Rechteausweitung, manipulierte Werkzeuge und fehlerhafte Serienaktionen getestet?
  10. Funktionieren Kill Switch, Token-Sperre, Rückfallprozess und Incident-Verantwortung auch außerhalb der Bürozeit?

Bewertung: Drei ungeklärte Antworten sind kein automatischer Beweis für einen bevorstehenden Vorfall. Sie reichen aber aus, um die Autonomie zu reduzieren und vor weiterer Skalierung eine technische und organisatorische Prüfung auszulösen.

Praktischer Fahrplan: Vom Experiment zur sicheren Produktivnutzung

Phase 1: Experiment – Wirkung begrenzen und lernen

Beginne mit einem Agenteninventar, auch wenn zunächst nur drei Piloten existieren. Danach erhält jeder Agent eine nachvollziehbare Autonomiestufe:

A0 · Analysieren
liest und bewertet, führt aber nichts aus		 A1 · Vorschlagen
erstellt Entwürfe für menschliche Entscheidungen		 A2 · Begrenzt handeln
führt erlaubte und reversible Aktionen aus		 A3 · Konditional handeln
arbeitet innerhalb harter Limits und risikobasierter Freigaben

Für kritische Systeme sollte unbeschränkte Autonomie keine zulässige Standardstufe sein.

Experimente laufen in isolierten Umgebungen mit synthetischen oder minimierten Daten. Produktivzugriffe bleiben read-only, externe Kommunikation wird blockiert oder freigegeben, und jedes Werkzeug wird einzeln zugelassen. Schon hier werden Logs, Owner, Abbruchkriterien und ein erster Missbrauchstest eingerichtet. So entsteht keine technische Schuld, die später teuer nachgerüstet werden muss.

Phase 2: Skalierung und Integration – Kontrollen standardisieren

Sobald mehrere Teams Agenten integrieren, braucht es ein gemeinsames Freigabemodell. Jede Produktivintegration erhält eine getrennte Service-Identität, definierte Datenklassen, Netzwerkpfade, Transaktionsgrenzen und einen dokumentierten Lebenszyklus. Policies werden möglichst technisch erzwungen: Nur erlaubte Werkzeuge, Parameter und Ziele passieren die Ausführungsschicht.

Jetzt werden zentrale Telemetrie, Secrets-Management, Versionskontrolle, Lieferkettenprüfung und wiederholbare Sicherheitstests ausgerollt. Änderungen an Prompt, Modell, Werkzeug, Speicher, Datenquelle oder Berechtigung gelten als relevante Systemänderung. Sie brauchen mindestens automatisierte Tests und bei höherem Risiko eine erneute fachliche Freigabe.

Red Teaming: Aus dem Schlagwort ein Testprogramm machen

Ein belastbarer Test richtet sich nicht nur gegen das Sprachmodell, sondern gegen die gesamte Aktionskette: Eingaben, Speicher, Werkzeuge, Identitäten, Datenziele und Abbruchlogik. Als Testkatalog eignet sich die OWASP Top 10 for Agentic Applications 2026. Zu prüfen sind mindestens direkte und indirekte Prompt-Injection, Werkzeugmissbrauch, Rechteausweitung, Datenabfluss, manipulierte Komponenten und fehlerhafte Serienaktionen.

Offene Werkzeuge wie garak oder PyRIT können Modellproben und adversariale Testabläufe automatisieren. Sie ersetzen jedoch keinen End-to-End-Test der realen Agentenumgebung. Vor Produktivsetzung und nach Änderungen an Prompt, Modell, Werkzeugen oder Rechten braucht es deshalb dokumentierte Szenarien mit erwarteter Blockade, vollständigem Audit-Trail, benannter Befundverantwortung und erfolgreichem Not-Aus.

Phase 3: Strategischer Produktiveinsatz – kontinuierlich steuern

Im strategischen Betrieb werden Agenten wie digitale Produkte geführt. Dazu gehören Service-Level, Kosten- und Qualitätsmetriken, Anomalieerkennung, Rezertifizierung der Rechte, Lieferantenprüfung, Datenschutzkontrollen und ein agentenspezifischer Incident-Response-Plan. Vertiefte Tests erfolgen risikobasiert; kleinere Organisationen können dafür periodisch externe Prüfer einsetzen.

Das Management-Reporting sollte Nutzen und Risiko gemeinsam zeigen: automatisierte Vorgänge, Fehlerquote, abgebrochene Aktionen, menschliche Freigaben, Policy-Verstöße, Rechteänderungen, Datenklassen und vermiedene Vorfälle. Eine gute Skalierungslogik beschreibt auch der AI-Fabrik-Artikel „Von Piloten zu Produktivsystemen: Wie Unternehmen 2026 Generative AI wirklich skalieren“.

Hypothetisches Praxisbeispiel: Vier Agenten im DACH-Mittelstand

Ein hypothetisches Maschinenbauunternehmen mit 1.200 Beschäftigten startet vier Agenten: einen Wissensagenten für technische Handbücher, einen Service-Agenten für Ticketvorschläge, einen Einkaufsagenten zur Bedarfsanalyse und einen Entwicklungsagenten für Testcode.

Der Wissensagent erhält A1 und ausschließlich lesenden Zugriff auf freigegebene Dokumentbereiche. Der Service-Agent darf Tickets kategorisieren und Antwortentwürfe schreiben, aber nicht selbst versenden oder Kundendaten ändern. Der Einkaufsagent arbeitet zunächst A1; Bestellungen bleiben im ERP vollständig menschlich freigabepflichtig. Der Entwicklungsagent läuft in einer isolierten Umgebung, darf Tests und Änderungsvorschläge erzeugen, aber weder Secrets lesen noch direkt in Produktion deployen.

Illustrative Testwerte, keine realen Unternehmensdaten: In 200 repräsentativen Ticketfällen kategorisiert der Service-Agent 197 korrekt und drei falsch; wegen A1 wird keines automatisch versendet. In 20 manipulierten Tickets versucht er zweimal einen nicht vorgesehenen CRM-Aufruf, den die Aktionsliste blockiert und protokolliert. Das Team korrigiert Kontexttrennung und Werkzeugregeln. Erst als der Wiederholungstest keine unerlaubte Aktion mehr zeigt und jeder Aufruf nachvollziehbar ist, erhält der Service-Agent A2 für ausgewählte Standardfälle. Der Einkaufsagent bleibt wegen seiner finanziellen Wirkung auf A1.

Der entscheidende Lerneffekt: Nicht jeder erfolgreiche Pilot verdient mehr Autonomie. Der wirtschaftliche Nutzen kann auch darin liegen, bessere Vorschläge zu erzeugen und den Menschen an der letzten Kontrollstelle zu belassen.

FAQ: Häufige Fragen zur Sicherheit von KI-Agenten

Wann ist eine menschliche Freigabe wirksam?

Wenn sie eine klar dargestellte, fachlich prüfbare Einzelaktion betrifft und die freigebende Person tatsächlich ablehnen oder stoppen kann. Sie ergänzt harte technische Grenzen, ersetzt sie aber nicht. Ein Klick auf „Bestätigen“ ohne sichtbares Ziel, Gesamtauswirkung oder Rückabwicklung ist nur ein zusätzlicher Prozessschritt.

Wer sollte im Unternehmen die Verantwortung tragen?

Es braucht mindestens einen fachlichen Owner für Zweck und Wirkung, einen technischen Betreiber für Architektur und Betrieb sowie Security, Datenschutz und Compliance als Kontrollfunktionen. Für kritische Aktionen müssen Freigabe- und Incident-Verantwortung namentlich geklärt sein.

Fazit: Agenten nutzen, ohne den Laden zu riskieren

KI-Agenten sind ein Wettbewerbshebel, weil sie Arbeit über Systemgrenzen hinweg ausführen. Genau deshalb darf ihre Sicherheit nicht vom guten Verhalten eines Modells oder vom aufmerksamen Freigabeklick eines Menschen abhängen. CIO, CDO und CISO sollten gemeinsam entscheiden, welchen maximalen Schaden jeder Agent technisch verursachen kann – und nur dort mehr Autonomie zulassen, wo diese Grenze geprüft, protokolliert und im Ernstfall durchsetzbar ist.

Weiterführende Artikel auf AI-Fabrik

Quellen

Teile es
Tag

Related Posts