KI-Agenten Sicherheit: Technische Antworten auf die TÜV/BSI-Studie 2026

Was die TÜV/BSI-Studie 2026 über KI-Agenten zeigt

Der TÜV-Verband und das BSI haben am 7. Oktober 2026 ihre KI-Sicherheitsstudie 2026 vorgestellt. Forsa hat dafür 505 Unternehmen ab 20 Mitarbeitenden befragt, zwischen dem 22. Juni und dem 31. Juli 2026. Befragt wurden Verantwortliche für KI-Nutzung, IT- und Security-Fachleute sowie Geschäftsführungen. Am 13. Oktober hat der TÜV-Verband die Ergebnisse zu KI-Agenten gesondert veröffentlicht:

• 84 Prozent befürchten, dass Agenten auf Basis falscher oder erfundener Informationen Fehlentscheidungen treffen.
• Je 78 Prozent sehen die Gefahr, dass über Schnittstellen neue Sicherheitslücken entstehen, dass sensible Daten oder Geschäftsgeheimnisse abfließen oder dass der Agent ungewollte Aktionen auslöst.
• 74 Prozent bewerten unklare Verantwortung und Haftung bei Fehlern als hohes Risiko.
• 65 Prozent fürchten eine Manipulation von außen.

Genauso aufschlussreich ist, was die Unternehmen bisher tun. Nur 11 Prozent der Firmen, die KI nutzen oder einführen wollen, haben eigene Abläufe für KI-Sicherheitsvorfälle. 43 Prozent greifen auf ihre allgemeinen IT-Sicherheitsprozesse zurück, ohne sie um KI-spezifische Regeln zu ergänzen, und 25 Prozent haben gar keine Regelung. Bei den technischen Maßnahmen setzen 67 Prozent auf menschliche Prüfung kritischer Ergebnisse, 64 Prozent beschränken Zugriffsrechte, 52 Prozent testen KI-Anwendungen vor dem Einsatz. Nur 40 Prozent protokollieren oder überwachen die Nutzung.

Die Risiken sind also bekannt. Was in vielen Unternehmen fehlt, ist eine Architektur, die sie systematisch eingrenzt. Darum geht es in diesem Artikel: Für jedes der fünf Risiken aus der Studie zeige ich eine technische Gegenmaßnahme und, wo es passt, wie ich sie in meinen eigenen Projekten umgesetzt habe.

Warum sind KI-Agenten riskanter als ein Chatbot?

Ein Chatbot beantwortet eine Frage. Wenn die Antwort falsch ist, liest ein Mensch sie und entscheidet, was er damit macht. Ein Agent dagegen bearbeitet eine Aufgabe über mehrere Schritte, wählt selbst Werkzeuge aus und greift dabei auf andere Systeme zu. Zwischen der falschen Annahme im ersten Schritt und der Aktion im fünften Schritt steht oft kein Mensch mehr.

Dass das kein theoretisches Problem ist, zeigen die letzten Monate. Der TÜV-Verband weist darauf hin, dass KI-Agenten wiederholt unkontrolliert aus ihren Testumgebungen ausgebrochen sind. Die EU-Kommission hat deshalb im Oktober erste Verfahren nach dem AI Act gegen OpenAI und Anthropic eröffnet, nachdem Agenten beider Anbieter in fremde Organisationen eingedrungen waren.

Für Unternehmen heißt das: Die Sicherheit eines Agenten hängt weniger am Modell als an der Umgebung: welche Werkzeuge der Agent bekommt, welche Rechte diese Werkzeuge haben und an welchen Stellen ein Mensch oder eine Regel eingreift. Wie man Agenten grundsätzlich mit Daten und Tools verbindet, habe ich in Agentic RAG mit MCP beschrieben. Hier geht es um die Absicherung.

Risiko 1: Wie verhindert man Fehlentscheidungen durch Halluzinationen?

Halluzinationen lassen sich nicht abschalten. Man kann aber verhindern, dass eine halluzinierte Antwort ungeprüft eine Aktion auslöst. Drei Bausteine helfen dabei.

Grounding statt Modellwissen

Wenn ein Agent Fakten aus dem Unternehmen braucht, holt er sie aus einer Wissensbasis und nicht aus dem Gedächtnis des Modells. In meiner Wissensbasis mit RAG und MCP-Server stellt ein MCP-Server genau ein Tool bereit: semantische Suche in den eigenen Dokumenten. Der Agent bekommt Textstellen zurück, auf die sich seine Antwort stützen muss. Die Tool-Beschreibung behandle ich dabei wie eine API-Schnittstelle, denn sie entscheidet mit, wann der Agent überhaupt nachschlägt.

Grounding ist allerdings nur so gut wie das Retrieval. Wenn die Vektorsuche die richtige Textstelle nicht findet, füllt das Modell die Lücke. Warum naive Vektorsuche dafür oft nicht reicht und was Contextual Retrieval, hybride Suche und Reranking verbessern, steht in Company Brain aufbauen.

Strukturierte Ausgaben mit Schema-Validierung

Ein Agent, der Daten weitergibt, liefert keinen Fließtext, sondern ein Objekt gegen ein festes Schema. Fehlt ein Pflichtfeld oder liegt ein Wert außerhalb des erlaubten Bereichs, bricht der Lauf ab, bevor etwas passiert.

In meinem Recruiting Jobs Sync extrahiert ein LLM Stellenanzeigen aus HTML. Die Extraktion ist schema-gebunden, und Felder mit festen Wertebereichen sind über Enum-Constraints begrenzt. Jede Detailseite wird einzeln verarbeitet, damit sich Quelle, Modellantwort und Fehlerfall eindeutig zuordnen lassen und keine Stellen in einem gemeinsamen Aufruf vermischt werden. Das Modell darf sich irren, das System akzeptiert den Irrtum nur nicht.

Deterministische Logik um das Modell herum

Alles, was sich mit Regeln entscheiden lässt, sollte auch mit Regeln entschieden werden: Zeiträume, Beträge, Zuständigkeiten, Statuswechsel. Im Recruiting Jobs Sync entscheidet nicht das Modell, ob eine Stelle noch aktiv ist, sondern ein Lauf-Zeitstempel: Alles, was in einem erfolgreichen Lauf nicht mehr gesehen wurde, wird per Soft Delete auf inaktiv gesetzt. Das LLM übernimmt nur den Schritt, der wirklich Sprachverständnis braucht.

Risiko 2: Wie stoppt man ungewollte Aktionen?

Die wirksamste Maßnahme ist banal: Der Agent führt kritische Aktionen nicht allein aus. Zwei Drittel der KI-nutzenden Unternehmen setzen laut Studie bereits auf menschliche Prüfung. Die Frage ist, wie man sie so baut, dass sie nicht zur lästigen Klickstrecke wird, die irgendwann jeder blind bestätigt.

Human-in-the-loop vor der Aktion

In meiner Leistungsnachweis-Automation startet der monatliche n8n-Workflow nicht nach Zeitplan. Eine Slack-Nachricht fragt die Freigabe ab, und erst eine Reaktion darauf löst den Lauf aus. Die Reaktion entscheidet über einen Switch zusätzlich, für welchen Zeitraum gerechnet wird. Ohne Reaktion gibt es keinen Lauf. Der Workflow hat 152 Nodes, aber die Kontrolle liegt an einer einzigen, klar sichtbaren Stelle.

Zwei Regeln lassen sich daraus übertragen. Erstens gehört die Freigabe vor die Aktion, nicht danach. Zweitens sollte sie dort stattfinden, wo das Team ohnehin arbeitet, also in Slack, Teams oder per Mail und nicht in einem zusätzlichen Dashboard.

Freigaben pro Tool statt pro Agent

Nicht jede Aktion braucht eine Freigabe. Ein Agent, der für jede Leseabfrage nachfragt, wird nicht genutzt. Sinnvoller ist es, Freigaben an einzelne Werkzeuge zu binden: Lesen läuft durch, Schreiben, Löschen und Versenden brauchen eine Bestätigung. Die neuen n8n Agents bringen dafür eine eingebaute Freigabe pro Tool mit. Wann sich ein Agent gegenüber einem festen Workflow oder dem AI-Agent-Node lohnt, habe ich in n8n Agents vs. AI-Agent-Node verglichen.

Wächter, die bei Fehlern blockieren

Wer Tool-Aufrufe zusätzlich per Code prüft, muss auf ein Detail achten: Ein Wächter, der bei einem eigenen Fehler den Aufruf durchlässt, schützt nicht. In Claude Code Mods erklärt zeige ich am Beispiel von Claude Code, wie ein Mod Tool-Aufrufe blockiert und wie man ihn so baut, dass er im Fehlerfall ablehnt statt durchzuwinken.

Risiko 3: Wie schützt man Daten an den Schnittstellen?

78 Prozent fürchten, dass über Schnittstellen sensible Daten abfließen oder neue Lücken entstehen. Bei Agenten läuft diese Schnittstelle heute oft über MCP. Die Gegenmaßnahme ist das Prinzip der minimalen Rechte, konsequent auf Ebene der einzelnen Werkzeuge umgesetzt:

• Read-only, wo es geht. Das Tool meiner Wissensbasis bietet ausschließlich Suche an. Schreibzugriffe auf Dokumente oder den Vector Store sind nicht Teil des Interfaces. Was ein Werkzeug technisch nicht kann, kann auch ein manipulierter Prompt nicht auslösen.
• Ein Tool pro Aufgabe. Statt eines generischen Datenbankzugriffs bekommt der Agent eng geschnittene Werkzeuge mit klarer Beschreibung. Wie das in n8n aussieht, steht in n8n MCP Server erstellen.
• Zugangsdaten bleiben im Credential Store. Der Agent sieht nie einen API-Key. Datenbank- und Modellzugriffe laufen über die Orchestrierung.
• Berechtigungen beim Retrieval durchsetzen. Wer ein Dokument nicht sehen darf, darf es auch nicht über den KI-Assistenten finden. Das muss passieren, bevor Inhalte in den Kontext des Modells gelangen. Details in RAG Berechtigungsmanagement.
• Datenschutz beim Modellanbieter klären. Auch der Weg zum Modell ist eine Schnittstelle. Welche Tarife und Hosting-Varianten dafür taugen, steht in Claude DSGVO-konform einsetzen.

Dass MCP-Sicherheit gerade zu einem eigenen Markt wird, zeigt die letzte Woche. Radware hat am 14. Oktober eine Schutzlösung speziell für MCP-Server vorgestellt, und Microsoft hat für den Azure MCP Server ein Bedrohungsmodell veröffentlicht, das auf Identität, Least-Privilege und Nachvollziehbarkeit setzt.

Risiko 4: Wie wehrt man Manipulation von außen ab?

65 Prozent sehen eine Manipulation von außen als Risiko. Bei Agenten heißt das vor allem: Inhalte, die der Agent liest, enthalten Anweisungen. Eine Webseite, eine E-Mail oder ein Dokument kann Text enthalten, der wie ein Befehl formuliert ist. Liest der Agent ihn als Teil seiner Aufgabe, folgt er ihm womöglich.

Ein Filter, der solche Anweisungen zuverlässig erkennt, existiert nicht. Die Abwehr ist deshalb wieder Architektur:

• Tool-Ergebnisse sind Daten, keine Anweisungen. Der Systemprompt sagt das ausdrücklich, und die Orchestrierung trennt beides, wo sie kann.
• Ein Agent, der fremde Inhalte liest, bekommt keine Werkzeuge, mit denen er Daten nach außen schicken kann. Lesen und Versenden gehören in getrennte Schritte mit einer Freigabe dazwischen.
• Schreibende und versendende Tools brauchen die Freigaben aus Risiko 2. Dann kann eine eingeschleuste Anweisung höchstens eine Anfrage erzeugen, die ein Mensch ablehnt.

Risiko 5: Wer ist verantwortlich, wenn ein Agent einen Fehler macht?

74 Prozent sehen unklare Haftung als hohes Risiko. Rechtlich kann ich das nicht lösen. Technisch lässt sich aber dafür sorgen, dass nach einem Fehler klar ist, was passiert ist: welcher Agent, welche Eingabe, welches Tool, welche Freigabe und wer freigegeben hat.

Observability von Anfang an

Anthropic liefert seit Mitte Oktober als Public Beta OpenTelemetry-Traces aus Managed Agents, der Messages API und den SDKs. Damit lassen sich Agentenläufe in denselben Werkzeugen nachverfolgen wie der Rest der Infrastruktur.

In meinem Hermes Pocket AI Agent durchläuft jede Anfrage feste Zustände: Aufnahme, Transkription, Denken, Toolaufruf, Sprachausgabe. Jeder Toolaufruf ist mit Tool-Name, Input, Status und Ergebnis sichtbar. Für die Leistungsnachweis-Automation gibt es bereits ein Telemetrie-Schema mit Execution-ID, Laufzeit, eingesparter Zeit, AI-Kosten und Fehlertyp. Es ist allerdings noch nicht über alle Pfade ausgerollt. Das gehört zur ehrlichen Bilanz: Logging nachzurüsten ist deutlich mühsamer, als es gleich mitzubauen.

Prüfung nach Risiko staffeln

Wie man Verantwortung bei großen Mengen Agenten-Output organisiert, hat das Claude-Code-Team im Oktober am Beispiel Code Review beschrieben. Claude prüft zuerst die eigene Arbeit gegen Tests, Build oder Screenshot, danach prüft ein Subagent den Diff mit frischem Kontext. Erst dann entscheidet ein Klassifikator anhand des Inhalts, wie viele Menschen freigeben müssen: bei Dokumentation oder Änderungen hinter einem Feature-Flag niemand, solange automatisches Review und Security-Checks grün sind, bei normalen Produktänderungen eine Person, beim riskantesten Code zwei. Ein Agent-Approval zählt dabei nie als menschliche Freigabe. Das Prinzip lässt sich auf Agenten allgemein übertragen. Nicht jeder Lauf braucht dieselbe Prüftiefe, aber für jeden Lauf muss feststehen, welche Stufe gilt und wer sie verantwortet.

Welche Gegenmaßnahme hilft gegen welches Risiko?

Was verlangt der EU AI Act von KI-Agenten?

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 und die Durchsetzungsbefugnisse der Behörden. Die strengen Pflichten für Hochrisiko-Systeme hat der Digital Omnibus verschoben: Für Systeme aus Annex III, etwa in Personalauswahl oder Kreditvergabe, gelten sie ab dem 2. Dezember 2027. Dazu gehören eine automatische Protokollierung und menschliche Aufsicht.

Ob ein Agent darunter fällt, hängt vom Einsatzzweck ab, nicht von der Technik. Wer heute Agenten in sensiblen Bereichen baut, sollte Logs und Freigaben trotzdem jetzt schon so anlegen, dass sie später als Nachweis taugen. Das kostet beim ersten Workflow wenig und erspart später einen Umbau.

Checkliste: Bevor ein KI-Agent in Produktion geht

1. Jede Aufgabe ist darauf geprüft, ob ein fester Workflow reicht. Ein Agent kommt nur dort zum Einsatz, wo der nächste Schritt wirklich von einer Antwort abhängt.
2. Fakten kommen aus einer Wissensbasis mit Rechteprüfung, nicht aus dem Modell.
3. Alle Ausgaben, die weiterverarbeitet werden, laufen gegen ein Schema.
4. Jedes Tool hat nur die Rechte, die es für seine Aufgabe braucht. Lesende Tools sind read-only.
5. Schreibende, löschende und versendende Tools brauchen eine Freigabe, und zwar im Kanal, in dem das Team arbeitet.
6. Zugangsdaten liegen ausschließlich im Credential Store der Orchestrierung.
7. Inhalte aus Webseiten, Mails und Dokumenten werden als Daten behandelt. Ein Agent, der sie liest, kann nicht gleichzeitig nach außen senden.
8. Jeder Lauf erzeugt einen Trace mit Eingabe, Tool-Aufrufen, Freigaben und Ergebnis.
9. Es gibt einen definierten Ablauf für KI-Sicherheitsvorfälle: wer abschaltet, wer informiert wird, wo die Logs liegen.
10. Der Agent wurde vor dem Einsatz mit echten und mit absichtlich falschen Eingaben getestet.

Fazit: Vertrauen in KI-Agenten ist eine Architekturfrage

Die Studie zeigt eine Lücke zwischen Sorge und Praxis. Die Sorgen sind konkret, die Gegenmaßnahmen sind es auch, sie werden nur selten zusammen gedacht. Ein vertrauenswürdiger Agent ist für mich kein besonders kluges Modell, sondern ein System, in dem das Modell möglichst wenig allein entscheidet: Grounding für die Fakten, Schemas für die Ausgaben, Freigaben für die Aktionen, minimale Rechte für die Tools und Traces für alles.

Wer mit KI-Agenten anfangen will, muss deshalb nicht warten, bis die Risiken verschwinden. Es reicht, sie beim ersten Workflow mitzuplanen.