KI-Agenten in der Cloud-Infrastruktur: Automatisierte Incident-Untersuchung und -Behebung in Azure ohne Datenabfluss

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem Studio DennisCraft AI realisiere ich produktive KI-Systeme für DACH-Kunden in Logistik, Fintech und Industrieautomation — mit einem Stack aus Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Vor wenigen Wochen wurde durch semgrep im CI erkannt, dass ein generierter Workflow versehentlich einen Azure-Token im Prompt ablegte – ohne diesen Hook wäre der Fehler in den Produktivbetrieb gelangt.

Herausforderung: Automatisierte Incident-Reaktion in Azure & Datenschutz

Incident-Response-Automatisierung in Azure bringt typischerweise das Dilemma: Sie benötigen weitreichende Rechte für Ihre Agenten, riskieren damit aber ungewollten Datenabfluss oder Rechte-Eskalation. In produktiven Projekten habe ich wiederholt gesehen, dass KI-Agenten unmaskierte Logs, sensible Variablen oder gar Tokens an LLMs weiterreichen. Besonders kritisch im regulierten DACH-Umfeld — Stichwort DSGVO und ISO 27001.

Die Hauptprobleme:

Agenten mit zu breiten Azure-Berechtigungen (Contributor/Owner) werden zum Single Point of Failure.
Sensible Daten (Secrets, Tokens, Logs) können in LLM-Requests oder externen APIs abfließen.

Laut Microsoft Identity Threat Landscape 2023 (siehe Quelle) gehen 86% der Cloud-Data-Breaches auf Fehlkonfigurationen bei Identitäten und Zugriffsrechten zurück.

Architektur: Sichere Einbindung von KI-Agenten in Azure

Produktiv-Stack im Überblick

Komponente	Rolle	Risiko Datenabfluss
n8n	Orchestrierung der Workflows	Mittel (sensitive Variablen im Prozess)
Claude Code API	Log-Analyse, Playbook-Generierung	Hoch (Prompt kann Secrets enthalten)
Supabase, Postgres	Ergebnis- und Incident-Storage	Mittel (Incident-bezogene Daten)
Doppler	Secrets Management	Niedrig (bei korrekter Konfiguration)

Muster: Datenminimierung im LLM-Kontext

Ungefilterte Logs oder Umgebungsvariablen gehen nie direkt an Claude oder andere LLMs. Vor jedem Prompt werden sensible Felder per Regex ausmaskiert.

import re

def mask_secrets(log: str) -> str:
    # Maskierung von Tokens, Keys, Secrets (Azure, JWT, etc.)
    log = re.sub(r'(token|key|secret)\s*=\s*["\']?[\w-]+["\']?', r'\1=***', log, flags=re.IGNORECASE)
    # E-Mail-Adressen herausfiltern
    log = re.sub(r'[\w\.-]+@[\w\.-]+', '[EMAIL]', log)
    return log

Diese Maskierung ist fester Bestandteil jedes n8n-Moduls, das Daten an ein LLM geben könnte. CI/CD-Pipelines prüfen mit semgrep und bandit auf Regelverletzungen.

Agenten-Isolation und Rechtevergabe

Service Principals mit Least Privilege

Jeder Agent nutzt einen eigenen Service Principal mit minimal erforderlichen Rechten, z.B. nur "Virtual Machine Contributor" auf eine bestimmte Resource Group. Kein globaler Contributor/Owner auf Subscription-Ebene.

az ad sp create-for-rbac --name "incident-agent" \
  --role "Virtual Machine Contributor" \
  --scopes "/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Compute/virtualMachines"

Zentrale Verwaltung von Secrets mit Doppler

Alle Umgebungsvariablen, Tokens und Credentials werden ausschließlich über Doppler verwaltet — inklusive Audit-Logs und automatischer Rotation. Agenten persistieren keine Secrets in der Datenbank oder in Logs.

Workflow: Incident-Ermittlung und Remediation

Incident-Trigger

1. Azure Monitor meldet einen Incident an n8n (WebHook oder Event Grid). 2. n8n startet den Workflow, parst Details, ruft einen LLM-Agenten zur Analyse und Remediation-Vorschlag. 3. Maskierte Daten gehen an Claude zur Generierung eines Schritt-für-Schritt-Remediation-Plans.

// n8n Custom Function Node
const incident = items[0].json;
const maskedLog = $evaluateExpression('={{ $json["log"] }}', { mask: mask_secrets });
return [{ json: { incidentId: incident.id, log: maskedLog } }];

Validierung & Audit von Remediation

Remediation-Playbooks, die kritische Ressourcen betreffen, erfordern stets eine manuelle Freigabe in n8n. Alle Agenten-Aktionen werden in einer separaten Postgres-Tabelle für Audits protokolliert.

Automatisierung ohne Preisgabe von Secrets

Überall, wo möglich, nutzen Remediation-Skripte temporäre Tokens (Azure Managed Identity), niemals statische Secrets im LLM-Kontext. Sensible Operationen sind immer durch menschliche Freigabe abgesichert.

Sicherheitsprüfung: Statische & dynamische Analyse

semgrep, bandit & gitleaks

semgrep und bandit laufen in jedem CI/CD-Pipeline-Run und prüfen auf Muster für Datenabfluss, CWE-Schwachstellen und Fehler in der Authentifizierungslogik. gitleaks scannt alle Repos auf versehentlich eingecheckte Credentials.

semgrep --config=auto src/
bandit -r src/
gitleaks detect --source .

Cloud Security Posture Management & Compliance

Die Konfiguration von Agenten und Service Principals wird regelmäßig mit Azure Security Center und Azure Policy auf Einhaltung von DSGVO- und BSI-Grundschutz-Standards überprüft.

FAQ

Welche Rechte erhalten Ihre KI-Agenten?

Nur die für die Aufgabe minimal erforderlichen Rechte — keine globalen Contributor- oder Owner-Berechtigungen.

Werden Logs im Klartext an LLMs weitergegeben?

Nein, alle Logs und Incidents werden vor Weitergabe maskiert. Volle Logs stehen nur manuell und gesichert zur Verfügung.

Wie erfolgt die Rotation von Secrets?

Ausschließlich über Doppler, inklusive Audit-Log für jede Änderung und jeden Zugriff.

Welcher Stack für statische Codeanalyse wird genutzt?

semgrep für Mustererkennung, bandit für Python-Code und gitleaks für Secret-Scans in Repositories.

Können Agenten Infrastruktur-Fehler autonom beheben?

Nur bei nicht-kritischen Ressourcen und immer erst nach expliziter Freigabe des Remediation-Plans. Netzwerk- und Datenbankeingriffe erfordern stets einen manuellen Schritt.

In welcher Pipeline-Phase (statische Analyse, Laufzeit-Sandbox, manuelles Review) entdecken Sie die meisten Security-Issues bei KI-Agenten? Ich biete für DACH-CTOs einen kostenfreien 30-min Stack-Review für AI-Projekte in regulierten Sektoren an. Kontaktieren Sie mich via LinkedIn oder @ger_dennis_ai.