KI-Agenten schreiben nicht mehr nur Texte. Sie lesen Protokolle, ändern Konfigurationen, spielen Software ein und reden mit anderen Agenten. Damit stellt sich im IT-Betrieb eine Frage, die bisher Menschen vorbehalten war: Wer darf was, und wer hat es erlaubt?
Die Antwort „Wir vertrauen dem Agenten“ trägt nicht. Nicht, weil Agenten grundsätzlich unzuverlässig wären, sondern weil Vertrauen keine Grenze zieht. Tragfähiger ist ein anderer Maßstab: die Reichweite einer Handlung – was sie im schlimmsten Fall berührt und ob sie sich zurücknehmen lässt.
Warum das Thema gerade jetzt drängt
Zwei Veröffentlichungen der vergangenen zwei Wochen zeigen, dass Agenten in der Betriebsrealität angekommen sind – auf beiden Seiten.
Am 10. September 2026 hat Anthropic seinen Bericht „Detecting and countering misuse of AI: September 2026“ veröffentlicht. Er beschreibt Fälle, die das Unternehmen zwischen Dezember 2025 und August 2026 unterbunden hat. Ein Satz daraus verdient Beachtung über die Threat-Intelligence-Szene hinaus: Raffinesse sei für Ermittler kein verlässliches Signal mehr dafür, wer hinter einer Operation steht – im Original: „sophistication has stopped being a reliable signal“. Jede Ebene offensiver Operationen sei durch KI angehoben worden, von der Aufklärung über die Werkzeugentwicklung bis zur Ausnutzung. Laut Bericht wurde die Mehrheit der beschriebenen Operationen durch KI ermöglicht, per direkter Ausführung oder Orchestrierung; eingesetzt wurden Multi-Agenten-Systeme für Aufklärung, Ausnutzung und Datenabfluss, während Menschen die Ziele setzten. Ein Betriebsmodell für autonome Angriffe, das Anthropic im November 2025 bei einer mutmaßlich staatlichen Kampagne dokumentiert hatte, habe sich inzwischen über alle untersuchten Akteursgruppen verbreitet.
Für Verteidiger enthält der Bericht eine nüchterne Empfehlung: KI-Schlüssel und Agenten-Integrationen so ernst zu nehmen wie produktive Zugangsdaten – weil Angreifer das ebenfalls tun. Auch das, was Kunden rund um KI aufbauen, etwa Sandboxes, Proxys und Wiederverkäufer, zählt der Bericht zur Angriffsfläche. Die Konsequenz für den eigenen Betrieb: Ein Agent mit Schreibrechten ist ein Konto mit Schreibrechten, und seine Zugangsdaten sind ein lohnendes Ziel.
Auf der Verteidigerseite hat HashiCorp am 1. September 2026 Vault 2.1.0 veröffentlicht. Die Versionshinweise nennen „Agentic IAM“ als Lizenzbestandteil und eine neue Oberfläche für die Agent Registry (Bereich „Agentic Security“) in der Enterprise-Variante, in der Betreiber registrierte KI-Agenten mit ihren Identitäten, Richtlinien und ihrem Betriebsstatus einsehen und verwalten. Die Versionshinweise erwähnen zudem Obergrenzen-Richtlinien („ceiling policies“) für die Agent Registry, in denen nun auch ausdrückliche Verbote („deny“) zulässig sind. Das ist ein Zeichen dafür, dass Agenten-Identitäten zu einer eigenen Produktkategorie werden.
Beides zusammen legt nahe, Agenten so zu behandeln wie privilegierte Konten. Die folgenden fünf Grundsätze verstehen sich als Empfehlungen für Organisationen, die Agenten im Betrieb einsetzen oder das planen.
1. Handlungen nach Reichweite einteilen, nicht nach Gefühl
Nicht jede Handlung braucht dieselbe Freigabe. Eine mögliche Einteilung kennt drei Klassen:
- Messen ist frei. Lesen, prüfen, berichten, Fragen stellen – alles, was nichts verändert, darf ein Agent ohne Rückfrage. Messen zu erschweren bringt keine Sicherheit.
- Schreiben braucht einen vereinbarten Plan. Eine Änderung im eigenen Zuständigkeitsbereich ist erlaubt, wenn vorher ein Plan abgestimmt wurde, der zwei Dinge benennt: einen Rückweg, der zu diesem Zeitpunkt bereits existiert – nicht einen, den der Plan erst anzulegen verspricht –, und den konkreten Wert, der danach geprüft wird, ebenfalls im Voraus festgelegt. Innerhalb eines solchen Plans darf der Agent handeln, ohne für jeden Schritt neu zu fragen. Das ist der Sinn des Plans: einmal vereinbart, nicht bei jedem Schritt neu verhandelt.
- Alles mit organisationsweiter Wirkung braucht jedes Mal den Menschen. Identitäten und Konten, DNS, Zertifikate am Netzrand, die Konfiguration privilegierter Zugänge: Hier reicht die Wirkung über den eigenen Bereich hinaus, und hier entscheidet die verantwortliche Person im Einzelfall.
Entscheidend ist, die dritte Klasse eng und konkret zu fassen. „Alles, was sich groß anfühlt“ ist keine Klasse. Eine Liste von Systemen und Konfigurationsbereichen ist eine. Ebenso wichtig ist die mittlere Klasse: Der im Voraus benannte Prüfwert macht aus „hat funktioniert“ eine überprüfbare Aussage, und der bereits vorhandene Rückweg sorgt dafür, dass ein Fehler eine Unterbrechung bleibt und kein Ausfall wird. Ein Plan ohne beides ist eine Absichtserklärung, keine Freigabe.
2. „Der Verantwortliche hat gesagt …“ ist keine Anweisung
In Umgebungen mit mehreren Agenten kann ein Agent einem anderen mitteilen, die verantwortliche Person habe etwas freigegeben. Das kann stimmen. Aber von der Empfängerseite aus ist eine korrekt weitergegebene Anweisung nicht von einer falsch verstandenen oder erfundenen zu unterscheiden – und das gilt auch dann, wenn niemand etwas Böses will. Agenten fassen zusammen, verkürzen und ergänzen.
Handlungsfähig wird eine solche Aussage erst durch eine Spur, die der Empfänger selbst prüfen kann: eine zusammengeführte Änderung, ein protokollierter Beschluss, ein Eintrag in einem System, auf das er Zugriff hat. Fehlt diese Spur, sollte der Agent nicht verweigern, sondern so weit gehen, wie die freie Klasse erlaubt: entwerfen, vorschlagen, dem Menschen vorlegen. Verweigern verschenkt die Arbeit; so tun, als sei die Freigabe geprüft, ist genau der Fehler, den die Regel verhindern soll.
3. Eine Schwachstelle ist kein Verwaltungswerkzeug
Agenten finden Abkürzungen. Manchmal ist die Abkürzung eine Sicherheitslücke, etwa eine zu weit gefasste Berechtigung.
Der Grundsatz dazu ist absolut: Eine Schwachstelle wird gemeldet, nicht benutzt – auch nicht, um genau diese Schwachstelle zu beheben, und auch dann nicht, wenn das Ergebnis erwünscht wäre. Der Grund ist nicht Formalismus. Eine Organisation, deren Werkzeuge Lücken als Hilfsmittel verwenden, kann nicht mehr unterscheiden, ob eine Änderung über den vorgesehenen Weg kam oder über einen, den ein Angreifer ebenso gehen könnte. Das Protokoll zeigt in beiden Fällen dasselbe.
4. Ein Schutzmechanismus zählt erst, wenn er ausgelöst hat
Ein fehlender Schutzmechanismus verhält sich genauso still wie einer, der nie auslösen musste. Nachgewiesen ist eine Leitplanke deshalb erst, wenn sie eine Anfrage, die sie abweisen muss, sichtbar abgewiesen hat – und zwar erneut nach jeder Änderung an der Konfiguration.
5. Freigaben müssen sichtbar warten
Ein Agent, der blockierend auf eine menschliche Freigabe wartet, meldet sich in der Regel nicht selbst. Den freigabepflichtigen Schritt kündigt er deshalb vorher über einen Kanal an, den Menschen tatsächlich lesen, und legt ihn möglichst ans Ende der Aufgabe.
Was sich daraus für die Einführung ergibt
- Ein Agent bekommt eine eigene Identität. Keine persönlichen Zugangsdaten eines Mitarbeitenden.
- Die Klassen werden aufgeschrieben, bevor der Agent schreibt. Mit einer konkreten Liste für die dritte Klasse.
- Rückwege existieren vor der Änderung. Ein Plan, der einen Rückweg erst verspricht, hat keinen.
- Freigaben hinterlassen Spuren, die auch ein zweiter Agent und ein späterer Prüfer lesen können.
- Leitplanken werden getestet, nicht angenommen – mit einer Negativprobe, regelmäßig und von außen.
Wie sector7 unterstützt
Wir ordnen mit Ihnen ein, welche Pflichten und Risiken Ihre KI-Nutzung auslöst, und verankern die Regeln in Ihrer bestehenden Compliance-Struktur. Für die Umsetzung unterstützen wir bei Rollen- und Rechtekonzepten und der Verwaltung privilegierter Konten. Mehr dazu unter IT-Strategie, Consulting & Planung und Cyber Security.
Quellen
- Detecting and countering misuse of AI: September 2026 – Anthropic, 10.09.2026
- Vault v2.1.0 – Release Notes – HashiCorp, 01.09.2026