KI-Sicherheit: Agenten unter strenger Aufsicht

In diesem „Consulting Briefing“ geht es um eine neue Spezies im Netzwerk: KI-Agenten. Die Kollegin aus HR kann man noch ins Meeting rufen, den Azubi ins Ticket schubsen – aber was macht man mit einem Rudel autonomer Agenten, die 24/7 Daten durchsuchen, Mails formulieren und Prozesse anstoßen? Kurz gesagt: Man behandelt sie wie sehr schlaue, sehr fleißige, aber komplett verantwortungslose Praktikanten. Und dafür braucht es Security und Compliance auf neuem Niveau.

Was ist neu bei Sicherheit und Compliance für KI-Agenten?

Die großen Hersteller, allen voran Microsoft, haben gemerkt: Ohne Transparenz und Kontrolle über KI-Agenten wird das nichts mit „Enterprise-ready“. Also entstehen gerade mehrere Bausteine, die Sie als IT-Entscheider kennen sollten:

• Agenten-Identitäten und -Inventar
  Mit Diensten wie Entra Agent ID wird für KI-Agenten im Prinzip ein eigener Identitätstyp eingeführt: Agenten lassen sich registrieren, bekommen eine eindeutige ID, Policies und Lebenszyklen – ähnlich wie Service-Accounts, nur mit mehr Intelligenz und mehr Risiko. Dazu gehören Funktionen wie Agenten-Inventar, Zugriffssteuerung und Schatten-KI-Erkennung („shadow AI“), also unkontrollierte Agenten oder Tools.

• Agenten-Kontrollzentralen
  Plattformen wie Agent 365 bündeln Agenten-Verwaltung: Registry, Zugriffsrechte, Telemetrie, Dashboards, Quarantäne für unsichere Agenten, Monitoring, wie Agenten mit Benutzern und Daten interagieren. Ziel: Ein zentrales Cockpit, in dem Sie sehen, welcher Agent was, wo und für wen tut – inklusive Alarmierung.

• Audit und Telemetrie für KI-Interaktionen
  Copilot- und KI-Interaktionen werden inzwischen tief in Audit-Logs protokolliert: Wer hat welchen Copilot genutzt, in welchem Dienst, welche Dateien wurden angefasst, welche Labels hatten diese Dateien, welche Aktionen wurden ausgelöst. Das läuft über Purview Audit und gehört zur Standard-Überwachung, sobald Audit aktiviert ist.

• Data Security Posture Management für KI (DSPM for AI)
  In Microsoft Purview gibt es mit DSPM for AI eine zentrale Oberfläche, um Datenrisiken rund um KI-Apps, Copilots und Agenten zu erkennen: Welche Agenten greifen auf welche Daten zu? Wo werden besonders viele schützenswerte Informationen von KI verarbeitet? Wo entstehen ungewöhnliche Zugriffe?

• Zero-Trust-Guidance speziell für Copilot und KI
  Die klassischen Zero-Trust-Prinzipien (explizite Verifizierung, geringstmögliche Rechte, „Assume Breach“) werden inzwischen explizit auf Copilot und KI-Begleiter angewendet. Es gibt konkrete Leitfäden, wie Identität, Daten, Apps, Geräte und Netzwerke für KI-Szenarien gehärtet werden sollen.

Zusammengefasst: Wir bekommen endlich Werkzeuge, um KI-Agenten nicht nur zu „aktivieren“, sondern sie wie ernstzunehmende Teilnehmer im Sicherheitsmodell zu behandeln.

Auswirkungen auf SOC-Workflows: Der Agent zieht mit ins SIEM

Für das SOC wird es damit deutlich spannender – und komplexer. Klassische Fragen wie „Welcher Benutzer hat was getan?“ werden erweitert um „Welcher Agent hat auf welche Daten zugegriffen, im Auftrag welchen Benutzers, über welchen Dienst?“.

Typische Veränderungen im SOC:

1. Neue Log-Quellen und -Typen

   • KI-spezifische Audit-Events (z. B. „Copilot hat Datei X gelesen“, „Agent Y hat Workflow Z ausgelöst“).

   • Agenten-spezifische Identitäten und Rollen im SIEM.

   • Korrelation: Benutzerlog, Agentenlog, DLP-Events, Entra-Events.

2. Neue Use Cases und Erkennungsregeln
   Beispiele für sinnvolle Detection Rules:

   • Agent greift in kurzer Zeit auf ungewöhnlich viele hochsensible Dateien zu.

   • Agent agiert außerhalb seines üblichen Kontextes (neuer Mandant, neue Region, neue Applikation).

   • Agent verwendet Anmeldeinformationen oder Verbindungen, die nicht zu seiner definierten Rolle passen.

   • DLP- oder Purview-Policies werden durch Agenten-Aktionen ausgelöst.

3. Playbooks für Agenten-Incidents
   Bei einem verdächtigen Agenten-Verhalten muss das SOC heute mehr tun als nur den Benutzer zu sperren:

   • Agent in Quarantäne setzen oder deaktivieren.

   • Agenten-Berechtigungen zurücksetzen.

   • Konfiguration und „Wissen“ des Agenten prüfen (z. B. Prompt-Vorlagen, hinterlegte Konnektoren).

   • Prüfen, welche Daten bereits abgeflossen sein könnten.

4. Erweiterte Forensik
   Forensische Analysen müssen auch KI-spezifische Fragen beantworten:

   • Welche Eingaben (Prompts) hat der Agent bekommen?

   • Welche Antworten oder Aktionen kamen zurück?

   • Welche Dateien, Chats, Mails waren involviert?

Kurz: Das SOC bekommt eine neue Dimension – Identität, Gerät, Anwendung, Daten… und jetzt Agent.

Richtlinien und Kontrollen: Vom „Copilot einschalten“ zur Agenten-Governance

Auf Policy-Ebene reicht es längst nicht mehr, irgendwo pauschal „Copilot erlaubt“ anzukreuzen. Unternehmen brauchen ein eigenes Policy-Set für KI-Agenten. Typische Bausteine:

1. Agenten-Lebenszyklus definieren

   • Wer darf Agenten anlegen, konfigurieren, veröffentlichen (z. B. in Power Platform, Azure AI, Agent 365)?

   • Wie werden Agenten getestet, freigegeben, dokumentiert?

   • Wie werden Agenten wieder außer Betrieb genommen (Deprovisioning)?

2. Rollen und Verantwortlichkeiten

   • Fachverantwortlicher für den Zweck des Agenten (z. B. HR-Agent, Finanz-Agent).

   • Technisch Verantwortlicher für Konfiguration, Konnektoren, Logs.

   • Security-Verantwortlicher für Risikoanalyse, Freigabe, Monitoring.

3. Identität und Berechtigung

   • Jeder Agent bekommt eine eigene Identität (z. B. über Entra Agent ID oder einen dedizierten Service Principal).

   • Strikte Rollen- und Rechtevergabe (Least Privilege) – der Agent hat genau die Rechte, die er braucht, nicht „Tenant.Global.Reader + alles“.

   • Service-Berechtigungen regelmäßig überprüfen und rezertifizieren.

4. Datenzugriffe und Klassifizierung

   • Sensible Daten werden sauber klassifiziert und gelabelt (Purview/Sensitivity Labels).

   • KI-Agenten dürfen z. B. Dateien mit bestimmten Labels nur lesen, nicht zusammenfassen oder exportieren.

   • Explizite Verbote: Keine Verarbeitung bestimmter Datentypen (z. B. besonders sensible personenbezogene Daten) durch Agenten.

5. Shadow AI und „wilde“ Agenten verhindern

   • Nutzung von Secure Web / AI Gateways, um unkontrollierte Zugriffe auf externe KI-Dienste zu blocken oder zumindest zu protokollieren.

   • Klare Vorgaben: Welche KI-Dienste sind erlaubt, welche verboten, welche nur in einer Sandbox.

Agenten-Sicherheit in Zero Trust integrieren

Wie bringt man das Ganze jetzt sauber in eine Zero-Trust-Strategie? Ein pragmatischer Ansatz:

1. Identität: Agenten als „First-Class Citizens“

   • KI-Agenten werden wie Benutzer und Service-Accounts im Identitätsmodell geführt.

   • Für Agenten gelten MFA-ähnliche Kontrollmechanismen, z. B. starke Authentifizierung über Zertifikate, Policies, Conditional Access-Profile.

   • Agenten bekommen eigene Rollen, die in Rezertifizierungsprozesse eingebunden sind.

2. Daten: „Need to know“ – auch für KI

   • Datenklassifizierung und Labels sind Pflicht, nicht Kür.

   • KI-Agenten werden nur auf definierte Datendomänen losgelassen (z. B. Projektwissen, interne Doku, nicht aber HR-Akten oder Aufsichtsratspostfach).

   • DLP- und Purview-Policies schließen explizit Agenten-Aktivitäten ein.

3. Anwendungen und Infrastruktur

   • Freigaben für Konnektoren und Plug-ins (z. B. zu SAP, CRM, externen APIs) laufen über standardisierte Freigabeprozesse.

   • Agenten, die Workflows oder Automationen anstoßen (z. B. Tickets, Bestellungen), werden wie andere Integrationslösungen behandelt: mit Testumgebungen, Change-Prozess, Rollback-Plan.

4. Netzwerk und Zugriffskontext

   • Kontextbasierte Richtlinien: Ein Agent, der im Namen eines Benutzers in einem hochsensiblen Kontext agiert, unterliegt strengeren Kontrollen.

   • Regionale Vorgaben (Datenresidenz, EU-Tenant, NIS2-Anforderungen) werden in die Agenten-Konfiguration eingearbeitet.

5. Sichtbarkeit, Automatisierung, Orchestrierung

   • KI-Agenten tauchen im zentralen Security Dashboard auf – nicht in einem separaten „KI-Playground“.

   • SOC-Playbooks berücksichtigen Agenten: automatische Quarantäne, Policy-Härtung, gezielte Alerting-Regeln.

   • Regelmäßige Reviews: Welche Agenten sind produktiv, was tun sie, welche Risiken haben sich geändert?

Reporting: Agenten kommen in den Lagebericht

Der Vorstand wird künftig nicht nur fragen: „Wie viele Angriffe haben wir abgewehrt?“, sondern auch: „Wie sicher ist unser KI-Einsatz?“. Dafür braucht es ein paar neue Kennzahlen im Reporting:

• Anzahl produktiver Agenten nach Bereich (HR, Finance, IT, Kundenservice usw.).

• Anteil der Agenten mit vollständiger Risikoanalyse und Freigabe.

• Anzahl und Schwere von Incidents, bei denen Agenten beteiligt waren.

• Blockierte oder eingeschränkte Agenten-Aktivitäten durch DLP- oder Purview-Policies.

• Entwicklung der Datenrisiken rund um KI (z. B. aus DSPM for AI-Berichten).

Damit wird KI-Sicherheit vom „spannenden Projekt“ zum festen Bestandteil von GRC- und NIS2-Reporting – gerade für kritische Infrastrukturen, Gesundheitswesen und öffentliche Hand extrem relevant.

Konkrete Empfehlungen für Ihr Unternehmen

Zum Mitnehmen für die nächste Runde im Architektur- oder Security-Board:

1. Inventar schaffen:
   Legen Sie ein zentrales Verzeichnis aller KI-Agenten an – inkl. Zweck, Verantwortlichen, Datenquellen und Berechtigungen.

2. Agenten-Rollenmodell definieren:
   Bauen Sie ein eigenes Rollen- und Berechtigungsmodell für Agenten auf und verknüpfen Sie es mit Zero Trust (Least Privilege, regelmäßige Rezertifizierung).

3. Audit & Monitoring aktiv und ausgewertet:
   Stellen Sie sicher, dass KI-Audit-Logs vollständig aktiviert sind, im SIEM landen und mit sinnvollen Detection Rules hinterlegt werden.

4. Purview & DSPM for AI nutzen:
   Nutzen Sie Datenklassifizierung, Labels, DLP und DSPM for AI, um KI-Zugriffe auf sensible Daten gezielt zu steuern und zu überwachen – nicht nur „alles oder nichts“.

5. Klare Freigabeprozesse einführen:
   Kein Agent ohne Freigabe: Risikoanalyse, Testphase, dokumentierte Konfiguration, definierter Scope, sauberer Rollout.

6. Shadow AI eindämmen:
   Kontrollieren Sie Zugriffe auf externe KI-Dienste, setzen Sie Gateways ein und definieren Sie verbindliche „Allow/Block/Review“-Listen.

7. Reporting professionalisieren:
   Führen Sie KI-spezifische KPIs in Security- und Compliance-Berichten ein. KI-Agenten gehören in den gleichen Steuerungsrahmen wie andere kritische Systeme.

Kurz gesagt: KI-Agenten werden bleiben – und sie werden mehr. Wer sie frühzeitig in Zero Trust, SOC-Workflows und GRC-Reporting einbettet, hat in zwei Jahren keinen panischen „KI-Aufräumtag“, sondern eine saubere, auditierbare und vor allem steuerbare Agenten-Landschaft. Genau das sind die Themen, die wir im „Consulting Briefing“ regelmäßig weiterdrehen werden.