--- title: "Zero Trust für KI-Agenten: Sicherheit auf der Tool-Ebene" description: "Zero Trust für KI-Agenten: Prompts sind keine Sicherheitsgrenze. Wie Identität auf Tool-Ebene, kurzlebige Tokens und Audit-Traces die Lücke schließen." canonical: "https://www.kondevs.com/de/content-hub/prompts-not-security-boundary-zero-trust-ai-agents/" language: "de" type: "article" author: "https://www.kondevs.com/authors/stoyan-kondev/" published: "2026-11-11T21:19:26.630Z" modified: "2026-11-11T22:31:46.244Z" image: "https://www.kondevs.com/assets/images/content/de/prompts-not-security-boundary-zero-trust-ai-agents/og.jpeg" tags: ["ki-agenten", "zero-trust", "agenten-sicherheit", "least-privilege", "audit-trail", "integrationsarchitektur", "KI-Agent"] --- > Den vollständigen Index dieser Website finden Sie in [llms.txt](https://www.kondevs.com/llms.txt); die ganze Website in einer Datei: [llms-full.txt](https://www.kondevs.com/llms-full.txt). # Prompts sind keine Sicherheitsgrenze: Zero Trust für KI-Agenten KI & Machine Learning 11. November 2026 6 Min. Lesezeit Von [Stoyan Kondev](https://www.kondevs.com/de/authors/stoyan-kondev/) ## Das Wichtigste in Kürze - Die Umfrage von SailPoint unter 340 Führungskräften ergab: 79 % der Unternehmen betreiben KI-Agenten produktiv, während 2 % Werkzeuge für Identity Security eingeführt haben, die eigens für deren Governance gebaut sind. Das ist eine 40-fache Lücke zwischen Einführung und Readiness. - Advait Patels Architektur setzt Sicherheit auf der Tool-Ebene durch, mit einer eigenen Identität pro Agent, kurzlebigen, auf die Aufgabe beschränkten Tokens und Least Privilege, statt sich auf Prompts als Sicherheitsgrenze zu verlassen. - Vier Fehlerbilder im Produktivbetrieb, die Sie einplanen sollten: Prompt Injection über Tool-Ausgaben, schleichende Rechteausweitung (Privilege Creep), unsicheres Retrieval über Mandanten- und Vertraulichkeitsgrenzen hinweg und Aktionsverstärkung (Action Amplification). - Fünf Schichten: Identität, Tools, Kontext und Retrieval, Policy und Entscheidung, Audit und Nachweis. Strukturierte Traces und Entscheidungsprotokolle vom ersten Tag an sind der Audit-Nachweis, mit dem das nächste Release schneller ausgeliefert wird. - Microsofts Bericht zu Storm-0940 und der Kompromittierung von ConnectWise Cloud Backup zeigt, dass Angreifer bereits KI-gesteuerte Werkzeuge nutzen, um sich schneller durch vertrauenswürdige Integrationen zu bewegen. - Der Einstieg: ein Anwendungsfall mit kleinem Schadensradius, Logging vor Policy, mindestens zwei Wochen im Schattenmodus, das SOC früh eingebunden, menschliche Freigabe nur für destruktive Aktionen. Der fünfte jährliche Bericht „Horizons of Identity Security“ von SailPoint, eine Umfrage unter 340 Führungskräften aus Identity-Management, IT, Sicherheit und Risikomanagement, kommt zu dem Ergebnis, dass [79 % der Unternehmen KI-Agenten produktiv betreiben, während 2 % Werkzeuge für Identity Security eingeführt haben, die eigens für die Governance dieser Agenten gebaut sind](https://www.sailpoint.com/press-releases/sailpoint-horizons-identity-security-ai-adoption-gap). Neunundsiebzig zu zwei: SailPoint spricht von einer 40-fachen Lücke zwischen Einführung und Readiness. In seinem Vortrag [„Zero Trust Agent Systems that Pass Audits and Still Ship“](https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/) auf der QCon AI Boston geht Advait Patel, Senior Site Reliability Engineer bei Broadcom, von einer Prämisse aus, die die meisten Teams in Unternehmen kennen, aber selten offen aussprechen: Prompts sind keine verlässliche Sicherheitsgrenze. Der Schadensradius (Blast Radius) eines Agenten liegt auf der Tool-Ebene, wo er APIs aufruft, Datenbanken liest und Aktionen auslöst. Genau dort müssen deshalb Authentifizierung, Autorisierung und eng zugeschnittene Berechtigungen durchgesetzt werden. ## Vier Fehlerbilder, die im Produktivbetrieb zählen Patels Einordnung ist nützlich, weil sie konkret ist. Er nennt vier Risiken im Produktivbetrieb: Prompt Injection über Tool-Ausgaben; schleichende Rechteausweitung (Privilege Creep), wenn ein Agent Tools ansammelt, die niemand prüft; unsicheres Retrieval, das Mandanten- und Vertraulichkeitsgrenzen überschreitet; und Aktionsverstärkung (Action Amplification), bei der eine einzige vage Anfrage viele folgenreiche Tool-Aufrufe auslöst. Daraus folgen zwei weitere: Aktionen, die niemand nachvollziehen kann, und eine zu langsame Reaktion auf Vorfälle. Nichts davon ist Theorie. Salt Security hat mehr als 380 Organisationen befragt: [49,8 % bestätigten oder vermuteten, dass ein Agent in den zwölf Monaten vor der Befragung eine unbeabsichtigte oder nicht autorisierte Aktion ausgeführt hat](https://salt.security/blog/agents-are-acting-most-organizations-cannot-stop-them). Nur 12,5 % können den vollständigen Pfad eines Agenten durchgängig nachverfolgen, und nur 17,5 % können einen Agenten automatisch stoppen, der sich unerwartet zu verhalten beginnt. Diese Zahlen sollten jeden beunruhigen, der in einem regulierten Umfeld Verantwortung für Integrationsarchitektur trägt. Wenn Sie nicht nachvollziehen können, was ein Agent getan hat, und ihn nicht stoppen können, wenn er sich falsch verhält, haben Sie kein System für den Produktivbetrieb. Sie haben ein Haftungsrisiko mit API-Schlüssel. ## Die fünf Schichten, die Patel vorschlägt 1. **Identität.** Jeder Agent und, wo nötig, jede Sitzung erhält eine eigene Identität (Workload Identity auf GCP, IAM-Rollen auf AWS) statt gemeinsam genutzter Zugangsdaten, sodass sich jede Aktion genau einem Agenten und einem Benutzer zuordnen lässt. 2. **Tools.** Jedes Tool hat eine eigene Identität, eine eigene Autorisierung, Rate Limits sowie Kontrollen für Ein- und Ausgaben und wird mit kurzlebigen Tokens aufgerufen, die auf die jeweilige Aufgabe beschränkt sind. 3. **Kontext und Retrieval.** Zugriffsregeln werden pro Dokument zum Zeitpunkt der Abfrage durchgesetzt, nicht dadurch, dass man das Modell bittet, sich an die Regeln zu halten. 4. **Policy und Entscheidung.** Eine eigenständige Engine (OPA, Cedar oder Ihre eigenen Regeln) steht zwischen dem, was der Agent vorhat, und dem, was tatsächlich ausgeführt wird, und protokolliert jede Entscheidung. 5. **Audit und Nachweis.** Strukturierte Traces pro Aktion, verknüpft mit Identität und Sitzung, zeigen, worauf der Agent zugegriffen und was er getan hat. Das ist eine Steuerungsebene (Control Plane), kein Schaubild für die Wand. Wer wie wir seit Jahren vertritt, dass die Integrationsschicht die Control Plane des Unternehmens ist, kann die Parallele kaum übersehen. Agentensysteme erben die strukturellen Probleme jeder Integrationslandschaft: Routing, Fallback, Observability, die Frage, wer um 02:00 Uhr zuständig ist. Der Unterschied: Agenten können schneller handeln, als Menschen prüfen können, und deshalb muss die Prüfung außerhalb des Modells liegen. Damit haben wir uns in einem eigenen Beitrag befasst: [deterministische Gates gegen stille Policy-Verstöße](https://www.kondevs.com/de/content-hub/deterministic-gates-silent-policy-violation-llm-agents/). ## Warum die Tool-Ebene die eigentliche Vertrauensgrenze ist Ein Großteil des Aufwands für die Absicherung von Agenten fließt in Prompt Engineering, Guardrails für das Modellverhalten und Eingabevalidierung. Patel hält das nicht für ausreichend. Über Tool-Ausgaben lassen sich Anweisungen in Prompts einschleusen. Berechtigungen sammeln sich unbemerkt an. Daten überschreiten beim Retrieval Mandantengrenzen. Die Durchsetzung muss dort stattfinden, wo der Agent handelt. Das deckt sich mit einem Grundsatz, den Integrationsarchitekten gut kennen: Punkt-zu-Punkt-Vertrauen ist genau einmal billig. Danach zahlen Sie Zinsen in Form von Vorfällen, Ausnahmen und unangenehmen Runden im Lenkungsausschuss. Eng zugeschnittene Tokens, Least Privilege auf der Tool-Ebene und Allowlists für destruktive Aktionen sind für Agenten das Gegenstück zu der Governance, die wir bereits auf APIs und Service-Verträge anwenden, und ein Gateway vor dem Modell und seinen Tools ist ein naheliegender Ort, um sie durchzusetzen; mehr dazu in [unserer Betrachtung eines KI-Gateways als Kontrollpunkt](https://www.kondevs.com/de/content-hub/cloudflare-ai-gateway-enterprise-control-plane/). Was sich ändert, ist die Geschwindigkeit: Ein Agent kann Dutzende Tool-Aufrufe in Sekunden aneinanderreihen, sodass schleichende Rechteausweitung und Aktionsverstärkung schneller eintreten, als irgendeine menschliche Freigabeschleife sie abfangen könnte. Patels Kontrollen sind konkret. Behandeln Sie Tool-Ausgaben als nicht vertrauenswürdig und bereinigen Sie sie. Setzen Sie ACLs zum Zeitpunkt der Abfrage durch. Stufen Sie destruktive Aktionen nach ihrem Schadensradius ab, mit einem Probelauf (Dry Run) oder einer ausdrücklichen Bestätigung für die höchste Stufe. Und bauen Sie den Kill Switch, bevor der Vorfall eintritt. In der Praxis heißt das, das Token eines Agenten sofort widerrufen zu können. Ein Kill Switch ist keine Paranoia, sondern betriebliche Hygiene. ## Auditfähigkeit als Beschleuniger der Auslieferung Der übliche Einwand lautet, Governance bremse die Auslieferung. Patel kehrt ihn um: Auditfähigkeit, die über strukturierte Traces und Entscheidungsprotokolle vom ersten Tag an eingebaut ist, verringert die Reibung mit der Zeit. Ohne Traces wird die Untersuchung eines Vorfalls zur Archäologie. Mit ihnen können Sie einem Auditor zeigen, worauf der Agent zugegriffen hat, welche Policy für jede Aktion maßgeblich war und wie weit der Schaden hätte reichen können. Genau dieser Nachweis erlaubt es Ihnen, die nächste Iteration ohne dreiwöchige Prüfung auszuliefern. Wie sich ein Trace durch APIs, Queues, Workflow-Engines und Modellaufrufe ziehen lässt, beschreibt [unser Leitfaden zu Trace-IDs](https://www.kondevs.com/de/content-hub/trace-ids-correlation-apis-queues-bpm-ai-calls/). Was auf dem Spiel steht, ist bereits sichtbar. Am 21. Oktober 2026 ordnete Microsoft die Kompromittierung von ConnectWise Cloud Backup dem Akteur zu, den das Unternehmen als Storm-0940 führt. Laut Microsoft nutzte dieser Akteur ARTEX, ein Open-Source-Framework für Penetrationstests, das sich von jedem beliebigen KI-Modell steuern lässt, um Aufklärung, Password Spraying und den Missbrauch von OAuth-Anwendungszugriffen zu beschleunigen. Dazu gehörten [Anmeldeversuche bei mehr als 2.250 Mandanten](https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/). Die Grundursache waren nach wie vor kompromittierte Zugangsdaten und vertrauenswürdige Integrationen; die agentischen Werkzeuge machten die Angriffskette schneller. Wenn Angreifer sich automatisiert durch Ihre Integrationslandschaft arbeiten, sind Least Privilege, starke Anwendungsidentitäten und Monitoring rund um Integrationen kein theoretischer Business Case mehr. ## Wo Sie anfangen sollten Patels praktischer Rat: Wählen Sie einen wertvollen Anwendungsfall mit kleinem Schadensradius. Beginnen Sie mit Logging, noch vor jeder Policy-Engine, denn was Sie nicht beobachten können, können Sie nicht kontrollieren. Lassen Sie den Agenten mindestens zwei Wochen im Schattenmodus (Shadow Mode) laufen, bevor Sie sich auf ihn verlassen. Und binden Sie das SOC früh ein, denn dort geht der erste Alarm ein. Beschränken Sie die menschliche Freigabe auf destruktive Aktionen. Eine Freigabe für alles ist eine Kontrolle, die niemand auf Dauer durchhält. Die Umfragedaten, der Bedrohungsbericht und die Architektur weisen in dieselbe Richtung: Agentenidentität, Autorisierung auf der Tool-Ebene, kurzlebige Zugangsdaten und durchgängige Traces sind die Mindestanforderung für den Produktivbetrieb, keine Kür für reife Organisationen. ## Drei Fragen zu einem Agenten, den Sie bereits betreiben Nehmen Sie einen Agenten, der produktiv läuft, und beantworten Sie drei Fragen. Unter welcher Identität läuft er, und ist es seine eigene? Welche Tools kann er aufrufen, mit welchen Berechtigungen, und wie lange ist sein Token gültig? Können Sie den Trace seiner letzten zehn Aktionen vorlegen und ihn innerhalb von Minuten stoppen? Jede Frage, die Sie nicht beantworten können, ist der nächste Eintrag im Backlog. Führt der Agent Aktionen in Unternehmenssystemen aus, ist das die Arbeit, die wir in der [Entwicklung von KI-Agenten](https://www.kondevs.com/de/services/agent-development/) leisten: Agenten, die über Ihre Integrationsschicht handeln, mit eng zugeschnittenen Berechtigungen, auditiertem Tool-Zugriff und einem Menschen an den Kontrollpunkten, auf die es ankommt. ## Häufige Fragen ### Warum sind Prompts keine verlässliche Sicherheitsgrenze für KI-Agenten? Ein Prompt lässt sich durch Text aushebeln, der über Tool-Ausgaben eingeschleust wird, und er kann weder Authentifizierung noch Autorisierung noch den Zuschnitt von Berechtigungen durchsetzen. Patel argumentiert, dass Sicherheit auf der Tool-Ebene verankert sein muss, dort, wo Agenten APIs aufrufen, Datenbanken lesen und Aktionen auslösen: mit einer eigenen Identität pro Agent, kurzlebigen, eng zugeschnittenen Tokens und Allowlists. ### Aus welchen fünf Schichten besteht eine Zero-Trust-Architektur für KI-Agenten? Identität (jeder Agent und jede Sitzung hat eine eigene Identität), Tools (jedes Tool hat eine eigene Identität, Autorisierung, Rate Limits und kurzlebige Tokens), Kontext und Retrieval (Zugriffsregeln werden pro Dokument zum Zeitpunkt der Abfrage durchgesetzt), Policy und Entscheidung (eine eigenständige Engine zwischen Absicht und Ausführung, die jede Entscheidung protokolliert) sowie Audit und Nachweis (strukturierte Traces pro Aktion, verknüpft mit Identität und Sitzung). ### Welche Kontrollen helfen zu verhindern, dass ein Agent nicht autorisierte Aktionen mit großer Tragweite ausführt? Least Privilege auf der Tool-Ebene, kurzlebige, auf die Aufgabe beschränkte Tokens, Allowlists und Stufen für destruktive Aktionen, ein Probelauf (Dry Run) oder eine ausdrückliche Bestätigung für die höchste Stufe und ein Kill Switch, der vor dem Vorfall gebaut wird: in der Praxis die Möglichkeit, das Token eines Agenten sofort zu widerrufen. ### Wie können Organisationen Auditoren zeigen, worauf ein KI-Agent zugegriffen und welche Aktionen er ausgeführt hat? Mit der Schicht für Audit und Nachweis: strukturierte Traces, die jeden Tool-Aufruf, jede Policy-Entscheidung und jeden Datenzugriff pro Agentensitzung festhalten, verknüpft mit der Identität des Agenten. Sie dienen als reproduzierbarer Nachweis bei der Untersuchung von Vorfällen und bei Compliance-Prüfungen. ### Wie groß ist die Lücke zwischen der Einführung von KI-Agenten und ihrer Governance? Laut der Umfrage von SailPoint unter 340 Führungskräften betreiben 79 % der Unternehmen KI-Agenten produktiv, während 2 % Werkzeuge für Identity Security eingeführt haben, die für Agenten gebaut sind. Salt Security stellte fest, dass nur 12,5 % der Organisationen den vollständigen Pfad eines Agenten durchgängig nachverfolgen können und nur 17,5 % einen Agenten automatisch stoppen können, der sich unerwartet verhält. ### Welche reale Bedrohung zeigt, warum Kontrollen für Agenten in integrationsintensiven Umgebungen wichtig sind? Am 21. Oktober 2026 berichtete Microsoft, dass der von ihm als Storm-0940 geführte Akteur bei der Kompromittierung von ConnectWise Cloud Backup ARTEX einsetzte, ein von KI-Modellen gesteuertes Open-Source-Framework für Penetrationstests, um Aufklärung, Password Spraying und OAuth-Missbrauch zu beschleunigen, mit Anmeldeversuchen bei mehr als 2.250 Mandanten. ## Quellen 1. [Zero Trust Agent Systems that Pass Audits and Still Ship, infoq.com](https://www.infoq.com/presentations/zero-trust-ai-agents-production-security/) 2. [The State of Agentic AI and API Security 2H 2026, salt.security](https://salt.security/blog/agents-are-acting-most-organizations-cannot-stop-them) 3. [AI-driven, large-scale nation-state campaign using ARTEX, microsoft.com](https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/) ## Verwandte Begriffe und Leistungen Wichtige Begriffe: [KI-Agent](https://www.kondevs.com/de/glossary/#ai-agent) Unsere Leistung: [Data Science & KI-Beratung](https://www.kondevs.com/de/services/ai-consulting/) ki-agenten zero-trust agenten-sicherheit least-privilege audit-trail integrationsarchitektur