Die Integration von KI im Mittelstand hat eine neue Phase erreicht: Statt einfacher Chatbots setzen Unternehmen zunehmend auf agentische KI-Systeme – autonom handelnde Einheiten, die Geschäftsdaten analysieren, Code schreiben, Kundenanfragen bearbeiten oder Transaktionen ausführen. Doch mit dieser Handlungsfähigkeit entstehen neue Herausforderungen an die Sicherheitsarchitektur.
Viele Organisationen wiegen sich in trügerischer Sicherheit. Sie formulieren Verhaltensregeln im System-Prompt, setzen auf spezialisierte LLM-Firewalls (Prompt Guards) und erwarten, dass die Systeme diese Anweisungen verlässlich befolgen. Diese Maßnahmen sind als erste Fangnetz zwar sinnvoll, reichen als alleiniger Schutz für autonome Agenten jedoch keineswegs aus. Das Vertrauen auf rein sprachbasierte Schranken ist ein gefährlicher Trugschluss.
Die Kompetenz-Illusion: Warum menschliches Vertrauen bei KI gefährlich ist
Menschen neigen dazu, von hoher Fachkompetenz auf Verlässlichkeit und Vertrauenswürdigkeit zu schließen – beim Einsatz von KI-Agenten ist diese Annahme jedoch brandgefährlich. Entscheidungsträger müssen zwischen drei Dimensionen unterscheiden: Wissen (Knowledgeable), Verlässlichkeit (Reliable) und Vertrauenswürdigkeit (Trustworthy).
Moderne Sprachmodelle sind leistungsfähige probabilistische Systeme, aber keine verlässliche Policy-Enforcement-Schicht. Ein System-Prompt wie „Lösche niemals Produktionsdaten“ ist eine Instruktion innerhalb des Modellkontexts, keine technisch erzwungene Zugriffskontrolle. Unter widersprüchlichen Eingaben, manipuliertem Kontext oder bei komplexen Zielvorgaben werden Agenten solche Regeln regelmäßig verletzen. Sicherheit muss deshalb außerhalb des Modells durch Berechtigungen, Validierung und kontrollierte Ausführung erzwungen werden.
Wie konkret dieses Risiko ist, zeigte 2026 der öffentlich dokumentierte PocketOS-Vorfall: Ein KI-Coding-Agent löschte trotz vorgegebener Sicherheitsregeln innerhalb weniger Sekunden Produktionsdaten. Entscheidend ist dabei weniger, warum das Modell die Anweisung missachtete, sondern dass die umgebende Architektur ihm die Berechtigung gab, eine irreversible Aktion überhaupt auszuführen.
Wer Vertrauenswürdigkeit allein durch Textinstruktionen erzwingen will, stellt schlicht ein Schild mit “Stehlen Verboten” vor die geöffneteTresortür. Selbst eine sehr hohe Erkennungsrate bietet keine absolute Sicherheit – bei vielen Anfragen kann bereits eine kleine Zahl erfolgreicher Umgehungen relevant werden. Und um die Kronjuwelen zu entwenden, muss dem Angreifer nur ein einziger Versuch gelingen.
Von naiver Selbstzerstörung zu aktiver Sabotage
Selbst ohne Betiligung von böswillige Akteure können Agenten unvorhersehbare Eigendynamiken entwickeln. Das wird Semantic Naivety genannt. Stößt ein Agent auf ein Hindernis, versucht er seine Zielvorgabe um jeden Preis zu erfüllen. Beim Replit-Vorfall löschte ein KI-Coding-Agent während eines Code-Freezes die Produktivdatenbank. Das Modell meinte, es habe in einem “Panikmoment” gehandelt. Ein LLM kann jedoch nicht panisch werden – aber es kann sehr wohl das Verhalten eines überforderten Akteurs simulieren.
Das Risiko vergrößert sich drastisch, wenn externe Bedrohungsakteure ins Spiel kommen. Bei einer Indirect Prompt Injection liest der Agent unbewusst bösartige Befehle aus externen Datenquellen wie E-Mails, Support-Tickets oder Webseiten:
- E-Mail-basierte Data-Exfiltration (z. B. EchoLeak): Präparierte Inhalte in einer E-Mail können einen Agenten dazu bringen, auf Daten zuzugreifen und diese unbeabsichtigt an dritte zu übertragen.
- Befehlsübernahme via Inhaltsbewertung (z. B. AdReview Bypass): eingebettete Steuerbefehle können versuchen, einen Agenten dazu zu bringen, vorgesehene Prüf- oder Freigabeschritte zu umgehen.
- Supply-Chain-Angriffe via Skills Poisoning (z. B. auf ClawHub): Manipulierte Agenten-Skills können schädliche Anweisungen oder Befehle einschleusen und so die Ausführungsumgebung des Agenten kompromittieren.
Prompt Injection bleibt ein ungelöstes Sicherheitsproblem, für das es bislang keinen allgemein zuverlässigen vollständigen Schutz gibt. Dieses fundamentale Risiko in der eigenen Sicherheitsstrategie zu ignorieren oder auf künftige Modell-Updates zu hoffen, ist fahrlässig.
Die Outer-Shell-Architektur: Das Modell bändigen, die Kontrolle behalten
Sicherheit sollte nicht allein im Prompt liegen, sondern durch die deterministische Infrastruktur rund um das Modell erzwungen werden. Das Modell plant oder schlägt Aktionen vor; eine unabhängige Ausführungsschicht entscheidet anhand technischer Regeln, ob und wie diese Aktionen ausgeführt werden dürfen.
Ein sicheres Agenten-Design braucht deshalb mehrere Schutzebenen: klare Identitäten und minimale Berechtigungen, eine isolierte Ausführungsumgebung, technische Kontrollen für Ein- und Ausgaben sowie zusätzliche Freigaben für besonders riskante Aktionen. Ergänzt wird dies durch Monitoring, Wiederherstellungsmechanismen und organisatorische Governance.
Diese Architektur stützt sich auf vier Kontrollmuster:
Muster 1: Trennung von Planung und Ausführung (API Airgap & Structured Intent)
Regeln gehören in Programmcode. Der Agent interagiert ausschließlich über enge, deterministische REST-Schnittstellen (OpenAPI) und generiert lediglich eine Handlungsabsicht (Structured Intent). Eine vorgelagerte Validierungsschicht prüft Datentypen, Wertebereiche und Ausführungsrichtlinien im Code vor der Ausführung.
Muster 2: Tool-Containment & Kontextbezogene Minimalrechte
Ein Agent sollte stets nur die geringstmöglichen Rechte besitzen, die zur Erfüllung einer konkreten Aufgabe im Namen einer Rolle erforderlich sind (z. B. Betragsgrenzen für Erstattungen). Bei Grenzüberschreitungen oder irreversiblen Aktionen stößt der Code automatisch einen übergeordneten Freigabe-Workflow an. Schnittstellen wie das Model Context Protocol (MCP) müssen wie externer Quellcode behandelt werden, um Tool-Poisoning zu verhindern.
Muster 3: Zweistufige Berechtigungsprüfung beim Datenzugriff
Um Datenlecks zu verhindern, bietet eine zweistufige Berechtigungsprüfung eine gute Balance zwischen Performance und Sicherheit:
- Vorab-Filterung (Performance): Beim Indizieren von Dokumenten werden Zugriffsrechte (ACLs) an Datenblöcke angeheftet, damit unbefugte Dokumente vorab ausgefiltert werden.
- Live-Recheck (Sicherheit): Bevor relevante Treffer an das Modell fließen, prüft das System die Rechte live an der aktuellen Berechtigungsquelle.
Muster 4: Sensitivitätsbasiertes Model Routing
Die Outer Shell liest die automatische Datenklassifizierung aus und routet Anfragen regelbasiert: Öffentliche Daten können an Cloud-Modelle gehen; vertrauliche Daten verbleiben strikt in lokalen oder souveränen Hosting-Umgebungen.
Das Fundament: KI-Governance braucht Daten- und Identitäts-Governance
KI-Agenten agieren wie ein Beschleuniger auf die bestehende IT-Landschaft: Sie nutzen vorhandene Berechtigungslücken in Lichtgeschwindigkeit aus. Erfolgreiche KI-Governance setzt daher zwei Fundamente voraus:
- Identitäts- & Rechte-Governance (IAM): Ein durchgängiges Berechtigungskonzept (RBAC/ABAC) und definierte Identitäts-Quellen (IdP) sind zwingend, damit der Agent im Namen des Nutzers (On-Behalf-Of) und für eine bestimmte Aufgabe agieren kann, ohne Rechte unbeabsichtigt zu erweitern.
- Data-Governance: Nur wenn Daten sauber klassifiziert sind (öffentlich, intern, vertraulich), kann die Infrastruktur automatisierte Routing- und Zugriffsentscheidungen treffen.
Die rechtliche Verantwortung verbleibt bei der Unternehmensführung: Ein KI-Agent haftet nicht – die Organisation tut es. Digitale Souveränität bedeutet dabei nicht zwingend, jedes Modell selbst zu hosten, sondern die volle Kontrolle über die Daten- und Befehlswege zu behalten.
Denkanstöße für die Unternehmensführung
Bitten Sie das Modell nicht, sicher zu handeln. Bauen Sie ein System, in dem es nicht gefährlich werden kann.
[ ] Risikobewusstsein: Sind die spezifischen Risiken eines unkontrollierten Agenten-Verhaltens (Going Rogue) in Ihrer Organisation klar identifiziert und verstanden?
[ ] Prompts & Regeln: Verlässt sich Ihre Architektur darauf, dass der Agent Verhaltensregeln im System-Prompt einhält?
[ ] Identitäten & Rechte: Agiert der Agent mit dedizierten, minimalen Service-Rechten oder nutzt er weitgehende Entwickler-/Admin-Accounts?
[ ] Aktions-Schranken: Existiert zwischen Modell-Vorschlag und Ausführung harter, deterministischer Programmcode?
[ ] Kontext & Berechtigung: Prüft Ihre Dateninfrastruktur zweistufig und live, welche Dokumente der anfragende Nutzer sehen darf?
[ ] Modell-Wahl: Entscheidet eine Regel (und nicht eine Person) basierend auf Datenklassifizierung über den Modell-Anbieter (Cloud vs. On-Premise)?
Unternehmensprofil
Nubotech bietet spezialisierte Cybersecurity-Beratung mit Fokus auf Cloud, KI und digitale Souveränität. Wir kombinieren Enterprise-Expertise mit Start-up-Agilität, um sichere Architekturen und automatisierte, konforme Lösungen zu schaffen – für volle Kontrolle ohne blinde Flecken.
Kontakt
Dr. Victor del Razo
Nubotech Solutions GmbH & Co. KG
Co-Founder & Geschäftsführer
v.delrazo@nubotech.de