KI-Sicherheit für Cloud-Operations-Teams in DACH

Prompt Injection bei Ops-Agenten ist ein Zugriffskontroll-Problem

Prompt Injection ist untrusted Content, der Ihren Agenten anweist, Policy zu ignorieren: Ticket-Text, Log-Zeile, eingefügte Kunden-E-Mail oder eine bösartige README in einem Repo, das der Agent liest. Bei einem internen Chatbot, der nur Text für Menschen entwirft, ist der Schaden peinlich. Bei einem Agenten mit Anbindung an Terraform-Pläne, Kubernetes-Changes oder Ticketing mit erhöhten Rechten ist es nicht von einem verwirrten Insider mit Ihren Keys zu unterscheiden.

Verteidigung ist geschichtet und im guten Sinne langweilig: Jede externe oder nutzergelieferte Zeichenkette als feindlichen Input behandeln; High-Impact-Tools hinter menschlicher Freigabe oder enger, separater Rollen halten; Tool-Aufrufe mit Prompt-Hash und Caller-Identität loggen; einem Agenten nie ein Superset dessen geben, was der On-call-Engineer ohnehin hatte. Red-Team gegen eigene Runbooks - „was, wenn diese Alert-Beschreibung Safeguards ignoriert“ - schlägt ein Dashboard, das Prompts „riskant“ labelt, ohne IAM zu ändern.

Tool- und IAM-Least-Privilege für Agenten

Ein Agent ist ein neuer Principal in Ihrem Identitätsmodell. Teilt er eine breite Automation-Rolle, die woanders genutzt wird, können Sie nicht unterscheiden, welche Aktion das Modell war, welche ein Skript und welche ein Angreifer, der das Modell steuert. Das Muster, das Audit-Gespräche übersteht: eine Rolle pro Agent-Workflow, auf die APIs und Ressourcen scoped, die der Workflow braucht, mit Session- oder Token-Lebensdauer kurz genug, dass eine Runaway-Schleife ausläuft, bevor Schaden sich ausbreitet.

Tools mappen wie Break-glass: jede aufrufbare Funktion ist eine API mit eigener Risikoklasse. Read-only-Diagnostik zuerst; mutierende Changes nur über guarded Paths (Plan-only, Approval-Queue, Change Window). Credentials, die der Agent nutzt, unabhängig von menschlichem SSO rotieren und widerrufen, wenn der Workflow abgeschaltet wird. ISO-27001-Zugriffskontrolle (A.5.15, A.8.2) und SOC-2-Logical-Access-Themen gelten für Service Principals wie für Personen.

• ✓Getrennte Rollen für „Incident zusammenfassen“ vs „Remediation anwenden“ - nie eine Super-Rolle, weil Wiring einfacher ist.
• ✓Deny-by-default auf Data-Plane-Mutationen; Allow-Lists pro Environment (Dev darf auto-fixen; Prod nicht).
• ✓Jeden Tool-Call in CloudTrail, Azure Activity Log oder GCP Audit Logs der Agent-Identität zuordnen, nicht einem shared Lambda-Admin.

Secrets in Kontextfenstern und Subprozessoren

Ops-Agenten verleiten Teams, Connection Strings, Kubeconfigs, Token-Dumps und Kundendaten „nur dieses eine Mal“ in Prompts zu pasten. Kontextfenster sind keine Vaults: Vendor-Logging, Retention für Abuse-Monitoring, Fine-tuning nur wenn der Vertrag es verbietet - und Replikation über Traces und Support-Tickets. DSGVO und Kunden-AVVs gelten weiter, wenn die Nutzlast ein Log-Ausschnitt mit Personenbezug ist.

Engineering soll Secrets über Referenzen routen, nicht Literale: zur Laufzeit scoped aus einem Secrets Manager holen, vor Modell-Sicht redigieren, Key-ähnliche Muster in ausgehenden Prompts blockieren. Subprozessor-Due-Diligence für den Model-Provider gehört ins gleiche Register wie Ihr Observability-Vendor: Region, Retention, Training-Opt-out, ob Support Prompts lesen darf. Das löst kein größeres Kontextfenster.

Logging und Nachweise für SOC 2, ISO 27001 und DORA

Auditoren und Aufsicht verlangen rekonstruierbare Timelines: wer den Agenten aufrief, welche Tools liefen, was im Estate änderte, ob Logs manipulationssicher sind. DORA Artikel 17-23 erwarten Major-Incident-Records mit verteidigbaren Zeitstempeln; ISO 27001 Schutz und Review von Logs (A.8.15, A.8.16); SOC 2 Monitoring und Logging passend zum Risiko. Ein Agent ohne strukturierte Audit-Trails ist eine Lücke, die Sie bei der ersten Stichprobe entdecken.

Minimum viable evidence für Ops-KI: unveränderlicher oder WORM-fähiger Storage für security-relevante Agent-Logs, Correlation-IDs von Chat-Session zu CloudTrail-Events, Retention aligned zum ISMS (nicht SaaS-Default), Runbooks mit exakten Queries für Timelines aus dem Archiv. Lebt der einzige Record in einer Vendor-UI mit 30-Tage-Retention, haben Sie keinen Nachweis - nur Bequemlichkeit.

EU-AI-Act-Literacy überlappt mit Cloud-Betrieb

Die meiste interne Ops-KI ist unter dem AI Act minimal oder limited risk, aber horizontale Pflichten bleiben: AI Literacy (Artikel 4), ehrliches Inventar mit Klassifikationsbegründung, Transparenz, wo Nutzer mit KI interagieren (Artikel 50). Das überlappt sauber mit Cloud-Governance, die Sie ohnehin brauchen - Access Reviews, Vendor Management, Change Control - wenn Sie Agenten als Produktionssysteme statt Experimente behandeln.

High-Risk-Annex-III-Domänen sind in reiner Ops-Tooling selten, Grenzfälle gibt es, wenn KI Beschäftigung, Kredit oder kritische Infrastruktur beeinflusst. Einzeiler-Klassifikationen schreiben, solange Designs frisch sind; Legal einbinden, wenn Workflows regulierte Outcomes berühren. Literacy ist keine jährliche E-Learning-Checkbox - sondern dass On-call weiß, dass Agenten injectable sind, Freigaben existieren und wo Logs liegen.

Was Stratoworks umsetzt - Kontrollen, kein KI-Security-SaaS

Der Markt bietet KI-Firewalls, Prompt-Filter und Governance-Plattformen. Manche sind sinnvolle Schichten; keine ersetzt IAM, Logging, Secrets-Hygiene und Runbooks auf Ihren Cloud-Accounts. Stratoworks verkauft diese Produkte nicht. Wir designten Agent-Grenzen in Ihrer Landing Zone: scoped Rollen in Terraform, Export von Agent- und Platform-Logs in kundenkontrollierten EU-Speicher, Approval-Gates für mutierende Tools, Anbindung an ISMS und Incident-Prozess.

Ist Copilot oder Agent-Framework gewählt, härten wir das Estate darunter - Least Privilege, Evidence-Pfade, Redaction-Patterns, Tabletops inklusive Prompt Injection. Ergebnis: Ops-KI, die Ihr Team betreiben und Compliance stichproben kann, ohne zu tun, als würde ein separates KI-Security-Abo eine zertifizierte Kontrolle ersetzen.

FAQ