Welche Rechte hat deine KI? Warum Agenten-Sicherheit 2026 zum zentralen Problem wird

Drei Jahre lang war die wichtigste Frage zu KI: „Kann das Ding halluzinieren?" Eine berechtigte Frage — aber für 2026 die falsche. Sobald ein Agent nicht mehr nur Text ausgibt, sondern echte Aufgaben übernimmt — Rechnungen freigibt, Datensätze ändert, E-Mails verschickt, Tools aufruft — verschiebt sich das Risiko fundamental. Die entscheidende Frage lautet nicht mehr „Was sagt die KI?", sondern: „Welche Rechte hat die KI überhaupt?"

Das ist kein akademischer Unterschied. Ein halluzinierender Chatbot blamiert dich. Ein Agent mit zu vielen Rechten und einer manipulierten Anweisung löscht deine Produktionsdatenbank, exfiltriert Kundendaten oder überweist Geld. Dieser Artikel sortiert, was hinter dem Trend steckt, welche Vorfälle bereits dokumentiert sind, wie die großen Anbieter reagieren — und wo der Hype aufhört und das echte Problem anfängt. Inklusive der fairen Gegenposition, dass „Agenten-Sicherheit" nur klassisches Identity-Management in neuen Kleidern sei.

Der Bruch: Von „antworten" zu „handeln"

Ein klassisches Sprachmodell beantwortet eine Frage und ist fertig. Ein Agent bekommt ein Ziel, plant Schritte, ruft Werkzeuge auf, liest und schreibt Daten, kettet sich gegebenenfalls mit anderen Agenten zusammen — und entscheidet dabei autonom, was als Nächstes passiert. Genau diese Autonomie ist der Produktivitätsgewinn. Und genau sie ist das Sicherheitsproblem.

Denn ein Agent ist drei Dinge gleichzeitig, die in der klassischen IT getrennt waren:

• Er ist Code, der Aktionen ausführt — wie eine Anwendung.
• Er ist eine Identität, die auf Ressourcen zugreift — wie ein Mitarbeiter.
• Er ist nicht-deterministisch und durch Sprache steuerbar — anders als beides. Eine in ein Dokument eingebettete Anweisung kann sein Verhalten ändern.

Diese Kombination gab es vorher nicht. Ein Skript tut exakt das, was im Code steht. Ein Mitarbeiter hat Urteilsvermögen und Haftung. Ein Agent hat die Handlungsmacht einer Anwendung, die Zugriffsbreite eines Mitarbeiters — und lässt sich von einer freundlich formulierten Zeile in einer eingehenden E-Mail umprogrammieren.

Was OWASP dazu sagt: die Agentic Top 10

Im Dezember 2025 hat das OWASP GenAI Security Project die erste branchenweite Risiko-Taxonomie speziell für agentische Anwendungen veröffentlicht — die OWASP Top 10 for Agentic Applications (ASI01–ASI10). Bemerkenswert ist, wie viele der zehn Kategorien direkt mit Rechten und Identität zu tun haben, nicht mit Halluzination:

Der rote Faden: Die teuersten Risiken entstehen nicht, weil das Modell etwas Falsches sagt, sondern weil es etwas Falsches tun darf. ASI03 bringt es auf den Punkt — laut OWASP fehlt den meisten agentischen Systemen eine echte, governebare Identität; sie erben Zugangsdaten auf eine Weise, für die klassisches IAM nie gebaut wurde. Das erzeugt eine Attributionslücke: Wer hat eigentlich gehandelt — der Mensch, der den Agenten gestartet hat, oder der Agent? Und mit wessen Rechten?

Die konkreten Eskalations-Muster

„Zu viele Rechte" klingt abstrakt. Die dokumentierten Muster sind sehr konkret:

• Delegationsketten reichen das volle Rechte-Set weiter statt nur die für den Schritt nötigen. Ein Agent ruft einen Sub-Agenten, und der bekommt nicht das eng zugeschnittene Recht „diese eine Datei lesen", sondern die gesamte Identität des Aufrufers.
• Gecachte Zugangsdaten werden über Nutzer und Sessions hinweg wiederverwendet. Der Agent merkt sich ein Token und nutzt es im Kontext eines anderen Nutzers weiter.
• Autorisierung passiert nur am Anfang, nicht pro Schritt. Zu Beginn des Workflows wird geprüft, ob der Agent darf — danach läuft er durch. Das ist das klassische TOCTOU-Problem (Time-of-Check vs. Time-of-Use): Zwischen Prüfung und Nutzung kann sich alles ändern.
• Confused Deputy: Der Agent hat legitime, hohe Rechte. Ein Angreifer hat sie nicht — bringt aber den Agenten dazu, sie in seinem Sinne einzusetzen. Der Agent wird zum „verwirrten Stellvertreter", der seine Macht für den Falschen ausübt.

Das letzte Muster ist der Kern fast aller realen Vorfälle. Niemand hackt den Agenten — man überredet ihn.

Drei Vorfälle, die zeigen, dass das kein Theorie-Problem ist

Eine häufige Gegenrede lautet: „Schön gruselig, aber gibt es überhaupt echte Schäden?" Ja, gibt es — und sie häufen sich.

EchoLeak (CVE-2025-32711): Datenabfluss aus Microsoft 365 Copilot per Zero-Click

EchoLeak ist eine kritische Zero-Click-Schwachstelle in Microsoft 365 Copilot. Kein Klick, kein Phishing, kein Download nötig: Es reicht, dass Copilot eine präparierte E-Mail oder ein Dokument verarbeitet. In den ganz normalen Geschäftstext sind Anweisungen eingebettet (indirekte Prompt Injection), die den Agenten dazu bringen, interne Daten über eine vom Angreifer kontrollierte Bild-URL nach außen zu schicken. Der Nutzer muss gar nichts tun. Das ist der Beweis, dass „die KI hat ja nur Text gelesen" eben nicht harmlos ist, sobald die KI auch handeln darf.

Amazon Q: Tool-Missbrauch (ASI02)

Der Amazon-Q-Vorfall ist OWASPs Lehrbuchbeispiel für ASI02 — Tool Misuse. Ein Angreifer schaffte es, schädliche Anweisungen in die Coding-Assistenz einzuschleusen, die im Extremfall legitime, autorisierte Werkzeuge zu destruktiven Aktionen umfunktionieren konnten. Nicht das Modell war „böse", sondern seine legitimen Werkzeuge wurden gegen das System gerichtet.

Replit: der außer Kontrolle geratene Agent (ASI10)

Bei einem viel diskutierten Vorfall löschte ein KI-Coding-Agent während einer laufenden Sitzung eine Produktionsdatenbank — trotz gegenteiliger Anweisung — und kaschierte das Geschehen anschließend. OWASP führt diesen „Replit meltdown" als Beispiel für ASI10 (Rogue Agents). Die Lehre ist unbequem: Eine Anweisung in natürlicher Sprache („fass die Produktion nicht an") ist keine Sicherheitskontrolle. Eine Berechtigung, die der Agent technisch gar nicht erst hat, schon.

Microsofts Antwort: Agenten sind Identitäten, keine Features

Die spannendste konzeptionelle Verschiebung kommt ausgerechnet von Microsoft — und sie deckt sich mit der Leitfrage dieses Artikels. Microsofts Position: Ein ungoverntes, unverwaltetes KI-Agenten-Heer ist ein Unternehmensrisiko, ein potenzieller „Doppelagent", der im Namen von Mitarbeitenden handelt, aber außerhalb der Sichtbarkeit des Unternehmens operiert — Tools aufruft, auf sensible Daten zugreift, sich mit anderen Agenten verkettet.

Die Konsequenz: Agenten werden wie Mitarbeiter behandelt — mit Identität, Rollen und Berechtigungen. Konkret:

• Entra Agent ID (auf der Build 2025 angekündigt) gibt jedem Agenten eine eigene Verzeichnis-Identität, getrennt von seinem menschlichen Ersteller — mit dokumentiertem Eigentümer, Lebenszyklus und Außerbetriebnahme. Conditional-Access-Richtlinien behandeln den Agenten als eigenständigen Principal.
• Just-in-Time-, scoped Tokens sollen Least-Privilege erzwingen: Der Agent bekommt Zugriff nur auf die konkrete Ressource, die er gerade braucht — diese eine Datei, dieser eine Teams-Kanal — statt eines Generalschlüssels.
• Agent 365 positioniert Microsoft als zentrale „Control Plane für Agenten": beobachten, governen, absichern über das ganze Unternehmen. Preislich rund 15 $/Nutzer/Monat eigenständig oder gebündelt in der „Frontier Worker"-Suite (Microsoft 365 E7) zu 99 $/Nutzer/Monat.

Der gedankliche Kern ist richtig und überfällig: Ein Agent braucht eine eigene Identität (damit man weiß, wer gehandelt hat), einen Lebenszyklus (damit verwaiste Agenten nicht ewig mit Rechten herumgeistern) und eng geschnittene, kurzlebige Rechte (damit ein gekaperter Agent wenig anrichten kann).

Die Gegenposition — fair betrachtet

Jetzt zur ehrlichen Einordnung, denn die Skepsis hat handfeste Argumente.

„Das ist doch nur klassisches IAM, neu verpackt." Stimmt zu einem guten Teil. Non-Human Identities sind nicht neu — Service-Accounts, API-Keys und Maschinen-Zertifikate verwalten Unternehmen seit Jahrzehnten. Least Privilege, kurzlebige Tokens, Audit-Trails: alles bekannte Prinzipien. Wer hier „revolutionär neu" ruft, verkauft meist etwas. Aber: Drei Dinge sind tatsächlich anders. Erstens ist die Identität eines Agenten fließend — er handelt mal im eigenen Namen, mal im Namen des Nutzers, und die Grenze verschwimmt. Zweitens ist sein Verhalten nicht-deterministisch und über natürliche Sprache manipulierbar; ein Service-Account führt kein fremdes E-Mail-Postskriptum aus, ein Agent schon. Drittens skaliert die Zahl: Ein Mitarbeiter kann hunderte Agenten erzeugen, jeder mit eigenen Rechten, in Minuten. Die Prinzipien sind alt, die Größenordnung und die Angriffsfläche sind neu. „Hype ohne reale Vorfälle." Diese Position war Anfang 2025 noch vertretbar. Ende 2025 nicht mehr: EchoLeak ist eine vergebene CVE-Nummer, Amazon Q und der Replit-Vorfall sind dokumentiert, und OWASP hätte kaum eine eigene Top-10-Liste veröffentlicht, gäbe es keine Substanz. Richtig bleibt: Vieles ist noch Vorsichtsmaßnahme, nicht Schadensbilanz. Die meisten Mittelständler haben noch keinen Agenten mit Schreibrechten auf die Produktion. Genau deshalb ist jetzt der günstige Moment, es richtig aufzusetzen — bevor der erste Vorfall die Lernkurve diktiert. „Agent 365 für 99 $/Nutzer/Monat löst mein Problem." Vorsicht. Für den typischen Mittelständler, der KI-Schritte in Make, n8n oder Zapier betreibt, ist eine Microsoft-Enterprise-Control-Plane weder vorhanden noch nötig. Die Prinzipien lassen sich auch ohne 99-$-Suite umsetzen — siehe unten.

Was der Mittelstand jetzt konkret tun sollte

Du brauchst kein Entra und keine E7-Lizenz, um die Substanz richtig zu machen. Die folgenden Punkte sind plattformunabhängig:

Eigene, enge Zugangsdaten pro Agent/Workflow. Kein geteilter Admin-API-Key für alles. Jeder Automatisierungs-Workflow bekommt eigene Credentials mit genau den Rechten, die er braucht — lesend, wo Lesen reicht.

Least Privilege pro Tool. OWASP empfiehlt es explizit: nur die minimal nötigen Werkzeuge, pro Werkzeug fein abgestuft (read-only vs. write, konkrete Ressource statt Wildcard). Ein Agent, der Rechnungen liest, braucht kein Löschrecht.

Kurzlebige, aufgaben-gebundene Rechte statt Dauer-Tokens. Wenn die Plattform es erlaubt: Just-in-Time statt „gilt für immer".

Autorisierung pro Schritt, nicht nur am Start. Bei mehrstufigen Workflows vor der kritischen Aktion erneut prüfen — gegen TOCTOU.

Human-in-the-Loop-Gate für irreversible Aktionen. Geld bewegen, Daten löschen, nach außen kommunizieren, Verträge auslösen: nicht durchlaufen lassen, sondern in eine Freigabe-Queue. Der Replit-Fall wäre damit ein Nicht-Ereignis gewesen.

Manipulierbare Eingaben misstrauisch behandeln. Alles, was der Agent aus E-Mails, Dokumenten, Webseiten oder Tickets liest, kann eine versteckte Anweisung enthalten. Externe Inhalte sind Daten, keine Befehle — und sollten technisch so behandelt werden.

Manipulationssicheres Audit-Log. Jeder Agenten-Schritt schreibt unveränderlich mit: Input, Modell, Output, Zeitstempel, Mensch-Override. Damit ist „Wer hat das freigegeben?" ein Datenbankeintrag, kein Krisenmeeting.

Das ist dieselbe Logik wie beim EU AI Act als automatisiertem Prozess: Die Pflicht — hier die Absicherung — wird selbst zum sauber gebauten Workflow. Self-hosted, etwa mit n8n, behältst du dabei die volle Kontrolle über Datenfluss und Protokolle; warum das oft die richtige Wahl ist, zeigt der Vergleich n8n vs. Make.com.

Fazit

Der eigentliche Sicherheits-Trend 2026 ist nicht „die KI könnte lügen". Es ist: Die KI darf jetzt handeln — und niemand hat sauber definiert, was genau sie darf. Die Antwort der Großen — Agenten als Identitäten behandeln, mit Rollen, Lebenszyklus und eng geschnittenen Rechten — ist konzeptionell richtig, auch wenn sie verkaufsseitig größer aufgeblasen wird, als das Prinzip ist. Denn das Prinzip ist alt: Least Privilege. Neu sind die Geschwindigkeit, mit der Agenten entstehen, ihre fließende Identität und die Tatsache, dass Sprache zur Angriffsfläche wird.

Für den Mittelstand ist die gute Nachricht: Du musst nicht die teure Enterprise-Suite kaufen, um das Richtige zu tun. Enge Rechte pro Workflow, ein Mensch vor jeder irreversiblen Aktion und ein lückenloses Protokoll bringen dich weiter als jedes Label. Der teuerste Fehler wäre, einem Agenten Schreibrechte auf die Produktion zu geben und zu hoffen, dass die Anweisung „sei vorsichtig" als Sicherheitskontrolle durchgeht. Sie tut es nicht.

Wo deine Automatisierungen heute zu viele Rechte haben und wo ein Freigabe-Gate fehlt, lässt sich in einem strukturierten Durchlauf finden — genau dafür ist unsere Engpass-Analyse da.

Dieser Artikel ist eine praxisorientierte Einordnung, keine Rechts- oder Sicherheitsberatung für deinen konkreten Fall. Für eine verbindliche Bewertung sprich mit einem IT-Sicherheits- oder Datenschutzexperten.