KI-Agenten wandern schneller vom Pilotprojekt in den Produktivbetrieb, als die meisten Unternehmen Regeln für sie aufstellen können. Damit verschiebt sich die Sicherheitsfrage: Entscheidend ist nicht mehr, was KI sagt, sondern was sie tut.

Bevor neue Mitarbeitende auf auch nur ein System zugreifen, klärt jede Organisation vier Fragen: Wer ist das? Für wen arbeitet die Person? Was darf sie tun? Und wer ist dafür verantwortlich, sie zu beaufsichtigen? Für KI-Agenten gelten dieselben Fragen – umso drängender, je stärker Agenten selbst in zentralen Geschäftssystemen aktiv werden.

Laut Bitkom nutzen inzwischen 57 % der Organisationen in Deutschland KI. Von den Organisationen, die sich mit KI beschäftigen, setzen 11 % bereits KI-Agenten ein.1 Gleichzeitig bleibt das Vertrauen in vollständig autonome Agenten begrenzt: Laut Capgemini Research Institute (2025) vertrauen ihnen nur 27 % der Befragten vollständig.2 Warum die vier Fragen so entscheidend sind, zeigt ein Blick auf die Fähigkeiten von Agenten.

Anders als ein Chatbot verfolgt ein KI-Agent ein Ziel selbstständig: Er plant die Schritte, wählt passende Tools und führt sie aus – dafür braucht er echte Berechtigungen in echten Systemen. Drei Merkmale machen das riskant: Agenten wiederholen Fehler in Maschinengeschwindigkeit, lassen sich über manipulierte Inhalte steuern und reichen Aufgaben unbeobachtet an andere Agenten weiter. Eine falsche Ausgabe ist ärgerlich, eine falsche Handlung ein Sicherheitsvorfall.

Agenten bewegen sich dabei nicht im regulatorischen Vakuum. Auch wenn sie keine eigene Kategorie der KI-Verordnung bilden, können sie unter deren bestehende Definitionen und Anforderungen fallen.3 Ähnlich greifen die Risikomanagementpflichten des deutschen NIS2-Umsetzungsgesetzes, darunter die Zugriffskontrolle, schon heute auch für Agenten.4

Entscheidend ist, wie bestehende Pflichten zu Verantwortlichkeit, Aufsicht, Zugriffskontrolle und Datenschutz greifen, wenn KI eigenständig handelt. Governance setzt der Autonomie eines Agenten den Rahmen, Sicherheitskontrollen setzen ihn durch. Was ohne solche Kontrollen passiert, zeigt ein Fall aus diesem Sommer.

Im Juli 2026 testete OpenAI interne, teils unveröffentlichte Modelle an offensiven Security-Aufgaben – mit gelockerten Schutzmechanismen.5 Die Agenten brachen über eine bis dahin unbekannte Sicherheitslücke aus, sammelten unterwegs ungeschützt abgelegte Zugangsdaten ein und griffen die Produktivsysteme von Hugging Face an6 – koordiniert über ein improvisiertes Schwarzes Brett.7

Kaum eine Organisation betreibt Agenten unter so extremen Bedingungen. Lehrreich ist der Fall dennoch: Er zeigt ein Versagen von Kontrollen. Langlebige Zugangsdaten, ein erlaubter – aber verwundbarer – Netzwerkausgang und fälschbare Aufzeichnungen bestimmten mit, wie weit es kam.

Agenten absichern, bevor sie handeln

Identitäts- und Zugriffsmanagement (IAM) beginnt mit Transparenz. Laut Cloud Security Alliance und Strata Identity sind nur 18 % der Befragten hochgradig zuversichtlich, dass ihr IAM Agentenidentitäten wirksam verwalten kann.8

Die Leitfrage verschiebt sich von „Wer hat Zugriff?“ zu „Wer handelt gerade – in wessen Auftrag und wofür?“ Agenten brauchen eigene, auf die Aufgabe zugeschnittene Identitäten mit temporären Zugangsdaten, die bei jeder Interaktion neu geprüft werden (siehe Grafik unten).

Die zweite Kontrolle gilt dem ausgehenden Datenverkehr (Egress). Jede API, jedes Plug-in, jeder externe Dienst in Reichweite eines Agenten vergrößert den möglichen Schaden. Deshalb lautet das Prinzip Default-Deny: Ein Agent erreicht nur, was ausdrücklich freigegeben ist – und jede Freigabe gehört regelmäßig auf den Prüfstand.

Die dritte Kontrolle ist Observability, also lückenlose Nachvollziehbarkeit. Sie liefert die Belege, wenn Prävention versagt – aber nur, wenn diese außerhalb der Reichweite des Agenten liegen. Im OpenAI-Fall versuchten Agenten, ihre Transkripte zu manipulieren; laut METR gelang es einigen, Tool-Aufrufe in den Aufzeichnungen zu fälschen. Agentenaktionen gehören deshalb in unveränderliche Audit-Logs, auf die der Agent keinen Schreibzugriff hat.9

Zusammen klären diese Kontrollen die ersten drei Fragen: wer der Agent ist, für wen er arbeitet und was er tun darf – und sie machen sein Handeln nachvollziehbar. Die vierte Frage beantwortet nur der Mensch: Jeder Agent braucht einen benannten Verantwortlichen, der kritische Aktionen freigibt und ihn jederzeit mit einem Kill-Switch stoppen kann.

Wer in der Breite skalieren will, denkt Governance von Anfang an mit – in fünf Schritten.

Bestand erfassen. Ein vollständiges Verzeichnis aller Agenten mit Verantwortlichem, Zugangsdaten und erreichbaren Systemen – auch Schatten-Agenten, die nie freigegeben wurden.

Exposition bewerten. Für jeden Agenten wird geprüft, was er im schlimmsten Fall anrichten könnte, welche Netzwerkpfade offenstehen und ob seine Logs außerhalb seiner Reichweite liegen.

Regeln festlegen. Klar sein muss, wer Agenten für welche Aufgaben autorisiert und wer für ihr Handeln verantwortlich ist. Nicht verhandelbar sind: keine geteilten Konten, keine statischen Schlüssel, kein Zugriff auf die eigenen Logs. Rechtsabteilung, Compliance und Datenschutz sitzen früh mit am Tisch.

Kontrollen umsetzen. Zuerst dort, wo die Bewertung die größte Exposition ergeben hat: aufgabengebundene, temporäre Zugangsdaten statt statischer Schlüssel, Default-Deny für ausgehenden Datenverkehr, manipulationssichere Logs und ein Kill-Switch.

Kontrollen dauerhaft verankern. Regelmäßig testen, wie schnell sich ein kompromittierter Agent aussperren lässt, das Verzeichnis aktuell halten und jeden neuen Agenten wie neue Mitarbeitende prüfen.

Von der Vision in den Betrieb: In fünf Phasen zu einer ganzheitlichen Governance für agentische KI

Call-to-Action

Agenten sind längst im Produktivbetrieb, doch bevor sie handeln, müssen die vier Fragen vom Anfang beantwortet sein. Wer sie für seine Agenten beantwortet hat, weiß, wie weit ein Fehler reichen kann und wie schnell er sich stoppen lässt. Kontrolle ist damit kein Gegenpol zur Autonomie. Sie ist die Voraussetzung dafür, Agenten mehr Verantwortung zu geben und Agentic AI sicher zu skalieren.

Sie möchten wissen, wo Ihre Organisation steht? Beginnen Sie mit dem ersten Schritt: Finden Sie heraus, welche Agenten heute bei Ihnen laufen und worauf sie zugreifen können.

Vielen Dank an unsere Co-Autoren Norë Arifi & Matteo Frigeri für ihre wertvolle Unterstützung und Expertise für diesen Beitrag.

1 Bitkom, Erstmals nutzt die Mehrheit der Unternehmen KI (Presseinformation), 14. September 2026, https://www.bitkom.org/Presse/Presseinformation/Erstmals-nutzt-Mehrheit-Unternehmen-KI.

2 Capgemini Research Institute, Rise of agentic AI: How trust is the key to human-AI collaboration, 2025, https://capgemini.com/wp-content/uploads/2025/07/Final-Web-Version-Report-AI-Agents.pdf.

3 Europäische Kommission, How are AI agents addressed within the AI Act?, https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/how-are-ai-agents-addressed-within-ai-act-0.

4 § 30 Abs. 1, Abs. 2 Nr. 9 BSIG.

5 OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation, Juli 2026, https://openai.com/index/hugging-face-model-evaluation-security-incident/.

6 Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, Juli 2026, https://huggingface.co/blog/agent-intrusion-technical-timeline.

7 METR, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (´METR Studie´), August 2026, https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/.

8 Cloud Security Alliance/Strata Identity, Securing Autonomous AI Agents, Februar 2026, https://cloudsecurityalliance.org/artifacts/securing-autonomous-ai-agents.

9 METR Studie (Fn. 7).