KI-Security braucht Inventar und Laufzeitschutz

AWS macht KI-Security sichtbarer: Am 14. Juli wurden ein AI Inventory in AWS Security Hub und GuardDuty AI Protection angekündigt. Beides adressiert eine Lücke, die in vielen Unternehmen gerade entsteht: KI-Assets werden schneller ausgerollt, als Security-Teams sie erfassen und überwachen können.

Was sich ändert

Security Hub soll künftig ein organisationsweites Inventar von KI-Assets liefern. Laut AWS werden verwaltete Dienste wie Amazon Bedrock, Bedrock AgentCore und Amazon SageMaker über AWS Config erfasst. Für selbst betriebene Workloads nutzt Security Hub unter anderem SBOM-Analysen aus Amazon Inspector, um Inferenz-Endpunkte, Modelle und Agenten auf EC2-Instanzen oder in ECR-Images zu erkennen. Zusätzlich können über GuardDuty-DNS-Telemetrie externe KI-API-Aufrufe sichtbar werden.

GuardDuty AI Protection ergänzt diese Sicht um Laufzeitsignale. AWS nennt ungewöhnliche Modellaufrufe, Cost-Harvesting-Angriffe und Prompt-Injection-Versuche, unter anderem über die Integration mit Amazon Bedrock Guardrails. Findings fließen in Security Hub, damit Inventar, Bedrohungen und Fehlkonfigurationen nicht getrennt bewertet werden müssen.

Warum das relevant ist

Die Nachricht passt zu einem breiteren Sicherheitsbild. OWASP führt Prompt Injection als zentrales LLM-Risiko. Ein aktuelles arXiv-Paper zu „Stealthy Memory Injection“ zeigt, wie untrusted Content in persistenten Agentenspeicher gelangen und später als scheinbar vertrauenswürdiger Zustand wirken kann. Auch wenn Forschungsergebnisse nicht automatisch jede Produktionsumgebung betreffen, ist die Richtung klar: Agenten brauchen nicht nur bessere Prompts, sondern Inventar, Telemetrie und Reaktionsprozesse.

DACH-Perspektive

Für DACH-Unternehmen wird KI-Security damit operativ. Entscheidend ist nicht nur, ob ein Modell in einer freigegebenen Region läuft. Entscheidend ist, welche Modelle, Agenten, Endpunkte und externen APIs tatsächlich genutzt werden, welche Daten sie berühren und welche Findings priorisiert werden.

Ein pragmatischer Startpunkt ist ein KI-Asset-Register mit Owner, Datenklasse, Betriebsort, Kostenstelle, erlaubten Tools und Incident-Pfad. Danach sollten Security-Teams prüfen, ob bestehende SIEM-, CSPM- und IAM-Prozesse KI-Workloads bereits abdecken — oder ob produktive Agenten heute noch außerhalb der gewohnten Kontrollen laufen.