Wenn Agenten das Steuer übernehmen: : Die Governance-Lücke im KI-Zeitalter
Autonome KI-Systeme übernehmen zunehmend operative Aufgaben in Unternehmen – doch bestehende Governance-Strukturen, Haftungsregeln und Sicherheitsarchitekturen sind auf diese Art von Akteuren nicht vorbereitet. Die daraus entstehende Lücke betrifft CISOs, CIOs und Compliance-Verantwortliche gleichermaßen.
Deutsche Unternehmen stehen bei der Integration von KI-Agenten vor zwei gegenläufigen Anforderungen. Einerseits wächst der Wettbewerbsdruck, autonome Systeme schnell in geschäftskritische Prozesse einzubinden. Auf der anderen Seite fehlen bislang verbindliche regulatorische Vorgaben für deren sicheren Betrieb. Der EU AI Act steckt zwar einen ordnungspolitischen Rahmen ab, lässt operative Fragen zur Governance von KI-Agenten aber weitgehend offen.
Autonom handelnde KI-Systeme haben den Schritt vom Pilotprojekt in die Produktionsumgebung vielerorts bereits vollzogen. Damit rücken Sicherheit, Haftung und Kontrollarchitektur in den Fokus – Fragen, die CISOs, CIOs und Compliance-Verantwortliche gleichermaßen betreffen.
Warum klassische Governance an Agenten scheitert
Die meisten Governance-Modelle wurden für vorhersehbare Auftraggeber entwickelt – für Menschen oder klar abgegrenzte Dienstkonten. KI-Agenten passen nicht in dieses Schema. Sie entscheiden dynamisch, welche APIs sie aufrufen, verknüpfen Aktionen systemübergreifend und arbeiten mit Zugangsdaten, die formal wie Dienstkonten aussehen, sich aber eher wie Menschen mit weitreichenden Befugnissen verhalten.
Das Prinzip der geringsten Rechte (Least Privilege) läuft damit ins Leere: Berechtigungen werden nicht mehr vorab in Richtlinien festgelegt, sondern effektiv zur Laufzeit – zum Zeitpunkt der Inferenz – entschieden. Genau hier liegt die Lücke, im Spannungsfeld zwischen der Handlungsfähigkeit der Agenten und ihren Zugriffsrechten.
Wer haftet, wenn der Agent sich irrt?
Macht ein autonomer Agent in Maschinengeschwindigkeit einen Fehler, ist die Rechenschaftspflicht bislang eher vertraglich als regulatorisch geregelt. Führt ein Agent die falsche Aktion aus, verteilt sich die Verantwortung auf den Anbieter, das Sicherheitsteam, das ihn bereitgestellt hat, und den Betreiber des betroffenen Systems – eine klare Haftungszuordnung fehlt jedoch.
Rahmenwerke wie das NIST AI Risk Management Framework (AI RMF) und der EU AI Act setzen bei Governance- und Überwachungsprozessen an, nicht bei der Zuordnung auf Ebene des einzelnen Vorfalls. Viele Organisationen behalten daher bei folgenreichen Aktionen weiterhin einen Menschen im Genehmigungsprozess (Human in the Loop) – auch wenn das den Geschwindigkeitsvorteil schmälert, der den Einsatz des Agenten ursprünglich begründet hat.
Der Lösungsansatz: Kognition und Steuerung trennen
Wenn klassische Governance- und Haftungsmodelle nicht greifen, verlagert sich die Absicherung in die Architektur selbst. Defensive Architektur in einer agentenbasierten Umgebung beginnt mit Sichtbarkeit der eingesetzten KI – on premises, auf Laptops, in Containern, in Platform-as-a-Service-Umgebungen (PaaS) – und mit der Erfassung, welche Modelle tatsächlich genutzt werden. Dazu müssen Model-Context-Protocol-(MCP)-Server und Modelle gescannt werden, um deren Risiken zu bewerten und daraus das Risiko der Agenten abzuleiten, die mit ihnen interagieren.
Agenten sollten die Automatisierung vorantreiben, die eigentlichen Aktionen aber von deterministischen Systemen gesteuert werden. Problematisch wird es, wenn dasselbe System, das Schlussfolgerungen zieht, auch zustandsändernde Operationen ausführt – ohne klare Richtliniengrenze dazwischen. Das sicherere Muster trennt die kognitive Ebene von der Steuerungsebene: Agenten geben Empfehlungen in Maschinengeschwindigkeit, während Policy-Engines festlegen, was tatsächlich erlaubt ist. Jede Aktion erhält dabei einen nachvollziehbaren Herkunftspfad (Provenance), der sich im Nachhinein prüfen lässt.
MCP: Wo die Zugriffskontrolle zur Schwachstelle wird
Wie kritisch diese Trennung ist, zeigt sich am Protokoll, über das Agenten ihre Werkzeuge ansteuern. Die Stärke und das Risiko von MCP beruhen auf derselben Eigenschaft: ein Agent, viele Tools. Die meisten MCP-Implementierungen stützen sich heute noch auf grob granulare Berechtigungen – besitzt der Agent den API-Schlüssel, kann er in der Regel alles aufrufen, was dahinterliegt. Kritisch wird das, sobald eine Prompt Injection beeinflussen kann, welche Tools der Agent aufruft. Auch die Tool-Beschreibungen selbst erweisen sich dabei als unterschätzte Angriffsfläche.
In der Branche setzt sich die Erkenntnis durch, dass MCP-Sicherheit im Kern ein Problem der Zugriffssteuerung ist. Tool-spezifische Scopes, kontextbezogene Autorisierung und eine menschliche Freigabe für sensible Aktionen entwickeln sich von Best Practices zu grundlegenden Anforderungen. Unternehmen achten zunehmend darauf, zunächst zu erfassen, wo MCP-Server in ihrer Organisation betrieben werden und welche Agenten nach welchem Berechtigungsmodell darauf zugreifen.
Fünf Maßnahmen für sichere KI-Agenten
Agentische KI lässt sich nicht über das Modell absichern, sondern nur über das umgebende System. Fünf Maßnahmen haben Vorrang:
- Inventarisieren. Erfassen, welche Agenten in Produktion laufen, welche Modelle sie nutzen und wo MCP-Server betrieben werden. Ohne Bestandsaufnahme keine Kontrolle.
- Agentenidentität klären. Agenten nicht über geteilte Dienstkonten und Sammel-API-Schlüssel betreiben, sondern mit eigener Identität und nachvollziehbarer Zuordnung.
- Steuerung von Kognition trennen. Die Entscheidung “was ist erlaubt” gehört in eine Policy-Engine – nicht in das Modell, das die Aktion vorschlägt.
- Nachvollziehbarkeit erzwingen. Jede zustandsändernde Aktion eines Agenten muss im Nachhinein lückenlos nachvollziehbar sein.
- Human in the Loop für kritische Aktionen. Solange die Haftung ungeklärt ist, bleibt die menschliche Freigabe bei folgenreichen Operationen die Rückfallebene
Kein Modellproblem – ein Systemproblem
Die Branche behandelt agentische KI als Modellproblem, obwohl es sich tatsächlich um ein Systemproblem handelt. Die eigentliche Angriffsfläche sind nicht nur die Prompts – es sind die Tools, der Speicher, die Berechtigungen und die Integrationen des Agenten. Ein Agent, der über persistenten Speicher mit mehreren MCP-Servern verbunden ist, verhält sich weniger wie ein Chatbot als vielmehr wie ein verteiltes System. Dennoch wird zu wenig in die unscheinbaren Bereiche investiert: Tool-Autorisierung, Agentenidentität, Audit-Protokolle und eine grundlegende Bestandsaufnahme, welche Agenten überhaupt in der Produktion laufen.
Die nächste Welle schwerwiegender Vorfälle dürfte eher Angriffen auf die Lieferkette ähneln als KI-Ausfällen im Hollywood-Format: kompromittierte Tools, vergifteter Speicher und der Missbrauch legitimer Agenten-Workflows – nicht bösartige Superintelligenz.
Autorin
Saumitra Das ist Vice President Engineering bei Qualys.