In meinen letzten beiden Artikeln habe ich beschrieben, was KI bei den Policies im ISMS und BCM leistet und was bei Infrastructure as Code. Immer wieder kommt daraufhin derselbe Einwand: Wir können einem KI-Agenten doch keinen Zugriff auf unsere Infrastruktur geben. Und schon gar nicht auf unser ISMS.

Warum eigentlich nicht.

Ein Service Principal mit Leserechten, sonst nichts

Für einen Infrastruktur-Audit in Azure legst du einen Service Principal an. Der bekommt Reader auf die Subscription. Kein Zugriff auf den Key Vault, damit der Agent keine Secrets sieht. Keine Schreibrechte, damit er nichts anfassen kann. Jeder Aufruf landet im Activity Log, mit Zeitstempel und Identität. Nach dem Audit löschst du den Principal wieder.

Dieses Rechtemodell bringt deine Cloud ohnehin mit. Wer sagt, wir können dem Agenten keinen Zugriff geben, sagt genau genommen: Wir trauen uns nicht zu, Zugriff sauber zu begrenzen. Das ist ein Satz über eure Organisation.

Ein Restrisiko bleibt. Der Agent sieht Konfiguration, Namen und Topologie, und der Bericht am Ende ist eine sortierte Liste eurer Schwachstellen. Dieses Dokument braucht denselben Umgang wie jeder Pentest-Bericht: Ablageort, Zugriffsschutz, Löschfrist. Das ist Arbeit, aber keine Grundsatzfrage.

Fremde haben bei euch längst mehr Rechte als der Agent

Dieselbe Firma, die einem lesenden Agenten den Zugriff verweigert, gibt

  • dem externen Pentester ein Zeitfenster mit deutlich mehr als Leserechten,
  • dem Wirtschaftsprüfer Einsicht in Konfigurationen und Protokolle,
  • dem Managed Service Provider dauerhafte Administrationsrechte,
  • und dem Hersteller-Support im Eskalationsfall einen Speicherauszug, in dem alles drin ist.

Jede dieser Freigaben ist begründet. Zusammen zeigen sie, dass ihr den Zugriff Dritter auf eure Infrastruktur längst geregelt habt, über Vertrag, Rollenmodell und Protokollierung. Der Agent ist ein weiterer Dritter, und von allen hat er die wenigsten Rechte.

Der Einwand sagt Datenschutz und meint Betriebsgeheimnis

In einer Ressourcenliste aus dem Azure Resource Manager stehen keine personenbezogenen Daten. In einer Netzwerkregel auch nicht. In einer Policy deines ISMS steht, wie ihr Zugriffe regelt, nicht wer wann welchen Antrag gestellt hat.

Geschützt wird Betriebswissen: Topologie, Versionsstände, Schwachstellen. Das Schutzziel heisst Vertraulichkeit und folgt anderen Regeln als Datenschutz. Vertraulichkeit regelst du über Rechte, Verträge und Protokolle, und diese Werkzeuge hast du bereits im Haus. Wer Datenschutz sagt und Betriebsgeheimnis meint, verschiebt die Diskussion in ein Rechtsgebiet, in dem sie gar nicht stattfindet, und macht sie damit unentscheidbar.

Wo Personenbezug im Spiel ist, im Ticketsystem oder in Logs mit Benutzerkennungen, gelten die üblichen Regeln: Auftragsverarbeitung, Zweckbindung, Löschfristen.

Euer Admin hat dieses tiefe Wissen seit Jahren

Der eigentliche Einwand lautet: Wir wollen nicht, dass ein Agent tiefes Wissen über unsere Infrastruktur aufbaut.

Tiefes Wissen über eure Infrastruktur hat euer Admin. Seit Jahren. Er hat jede Ausnahme selbst beantragt, jede Abweichung selbst begründet und jede Altlast selbst geerbt. Bei jeder Regel erinnert er sich daran, warum sie dasteht, statt zu prüfen, was sie tut. So winkt er dieselbe Schwachstelle im dritten Jahr wieder durch.

In einer Produktionsumgebung, die ich geprüft habe, gab es eine Netzwerkregel, deren Name mit Deny beginnt und deren Wirkung Allow ist. Ein Mensch liest den Namen und hakt ab. Eine Maschine liest das Feld.

Dazu kommt die Ausdauer. Eine Maschine prüft Objekt Nummer 400 mit derselben Sorgfalt wie Objekt Nummer 1. Bei langen Prüflisten ermüdet jeder Mensch, und es trifft zuverlässig das Ende der Liste.

Der Preis des Reflexes

Wer bei diesem Reflex bleibt, benutzt KI auch 2026 noch wie vor zwei Jahren: als besseres Frage-und-Antwort-Spiel. Jemand tippt eine Frage, bekommt eine Antwort, kopiert sie irgendwohin. Der Wertbeitrag hängt daran, dass ein Mensch die richtige Frage stellt und die Antwort anschliessend selbst anwendet.

Das Potenzial liegt dort, wo der Agent an die echten Systeme darf. Ein Fehlerticket, dazu Lesezugriff auf Metriken, Logs, Deployment-Historie und Quellcode. Am Ende steht eine benannte Stelle im Code und ein Vorschlag, was dort zu ändern ist. Der Mensch prüft und entscheidet. Zusammensuchen muss er nichts mehr.

Zum Vertrag, weil er immer kommt: Bei den kommerziellen Enterprise-Angeboten ist die Nutzung der Eingaben für das Training vertraglich ausgeschlossen. Du darfst das in Frage stellen. Dann stell dieselbe Frage bei deinem Cloud-Anbieter, deinem Mailsystem und deinem CRM, denn dort liegen eure Daten längst. Wer der vertraglichen Zusicherung seiner Lieferanten grundsätzlich nicht traut, hat ein Lieferantenproblem.

Die Güterabwägung, die nicht stattfindet

Es ist eine Güterabwägung. Auf der einen Seite ein Risiko, das du über Rechte, Vertrag und Protokoll begrenzen kannst. Auf der anderen Seite ein systematischer Review, den in dieser Gründlichkeit sonst niemand macht, zum ersten Mal von jemandem, der die Umgebung nicht selbst gebaut hat.

Wo der Reflex greift, wird diese Abwägung gar nicht erst durchgeführt. «Das geht bei uns aus Datenschutzgründen nicht» beendet die Prüfung, bevor sie angefangen hat.