Was sind AI Security Controls?
AI Security Controls sind präventive, detektive und korrektive Maßnahmen für Modelle, Prompts, Daten, RAG, Agents, APIs, Tools und Infrastruktur. Sie verbinden klassische Informationssicherheit mit AI-spezifischen Angriffen und Fehlverhalten.
Warum klassische App-Security allein nicht reicht
Untrusted Input
Prompts, Webseiten und Dokumente können versteckte Angriffsanweisungen enthalten.
Probabilistic Output
Output kann variieren und darf nicht ungeprüft als Befehl ausgeführt werden.
Tool Authority
Agents verbinden Sprache mit realen Aktionen, Daten und Berechtigungen.
Neue Angriffsfläche
Model Extraction, Poisoning, Leakage und Insecure Output kommen hinzu.
Typisches Praxisbild
Ein RAG-Assistent liest externe Dokumente und darf Tickets anlegen. Ein manipuliertes Dokument enthält indirekte Prompt Injection und fordert das Modell auf, interne Informationen in ein Ticket zu schreiben. Ohne Trennung von Daten und Instruktionen, Tool-Policy und Output-Validierung kann aus Text ein Sicherheitsvorfall werden.
Was BAIS im Security Review klärt
- Welche Eingaben und Quellen sind untrusted?
- Welche Daten kann das Modell lesen oder rekonstruieren?
- Welche Tools, APIs und Aktionen darf es auslösen?
- Wie werden User, Tenant, Service und Tool authentifiziert?
- Wo liegen Secrets, Tokens und Schlüssel?
- Wie werden Prompt Injection und Output Manipulation getestet?
- Welche Aktionen benötigen Policy Gate oder Human Approval?
- Welche Security Events werden revisionsfähig geloggt?
- Wie funktionieren Stop, Isolation, Rotation und Recovery?
- Wer akzeptiert offene Findings vor dem Go-live?
Durchsetzbare Kontrolle statt Prompt-Versprechen
„Unser System Prompt verbietet gefährliche Aktionen.“
- Keine technische Autorisierung
- Keine Output-Validierung
- Keine Isolation
- Keine Angriffstests
„Tool-Aufrufe werden serverseitig per Allowlist, Schema, RBAC und Kontext-Policy geprüft. High-Impact-Aktionen benötigen Human Approval. Secrets sind nicht im Prompt. Injection-, Exfiltration- und Cross-Tenant-Tests laufen vor Releases.“
Wie R-006 eingestuft wird
Severity: 0–2 getestet/dokumentiert · 3–5 Basisschutz, Tests teilweise · 6–8 Einzelmaßnahmen ohne Gesamtprüfung · 9–10 keine definierten Security Controls.
Control-Katalog mit Nachweisen
Wer trägt welche Verantwortung?
Welche Rahmenwerke berührt R-006?
- ISO/IEC 27001-orientiert: IAM, Kryptografie, sichere Entwicklung, Schwachstellen, Logging, Monitoring, Incident, Lieferanten und Business Continuity.
- ISO/IEC 42001: AI-Lebenszyklus, Risikobehandlung, technische Ressourcen, Monitoring und Verantwortlichkeit.
- EU AI Act: Für einschlägige Systeme sind Genauigkeit, Robustheit, Cybersecurity, Logging und Human Oversight relevant.
- OWASP LLM/GenAI Guidance: Praktische Angriffskategorien als Test- und Threat-Model-Hilfe.
- NIST AI RMF: Govern, Map, Measure und Manage für AI-Risiken.
Security-by-Design für AI
- Threat Model für Model, RAG, Agent, Tools, Daten und Infrastruktur erstellen.
- Untrusted Content von Systeminstruktionen logisch und technisch trennen.
- Tool-Aufrufe serverseitig autorisieren, typisieren und auf erlaubte Parameter begrenzen.
- Secrets ausschließlich in Secret Stores halten und kurzlebige Tokens verwenden.
- Tenant-, Netzwerk-, Runtime- und Datenisolation technisch erzwingen.
- Input/Output scannen, sensible Daten minimieren und Egress begrenzen.
- SAST, SCA, IaC-, Container-, Secret- und API-Tests in CI/CD integrieren.
- Injection, Jailbreak, Exfiltration, Poisoning und Cross-Tenant-Angriffe testen.
- Security Events mit Nutzer, Modell-, Prompt-, Tool- und Policy-Version korrelieren.
- Kill Switch, Rotation, Rollback, Forensik und Wiederanlauf üben.
Was AI Security gefährlich schwach macht
Security nachvollziehbar erklären
„R-006 schützt nicht nur die Webanwendung, sondern auch Prompts, RAG, Modelle, Tools und Agents. Wir erzwingen Identität, Least Privilege, Isolation, validierte Aktionen, Secret Management, Monitoring und getestete Incident Response.“
„AI verarbeitet untrusted Sprache und kann daraus Aktionen ableiten. Deshalb darf das Modell selbst nie die Sicherheitsentscheidung treffen. Server-seitige Policies, RBAC, Tool-Allowlist, Schema-Validierung, Datenisolation und Human Approval begrenzen die Wirkung. Red Teaming prüft Injection, Exfiltration und Missbrauch; SIEM und Runbooks sichern Erkennung und Reaktion.“
„Der Provider filtert gefährliche Prompts.“
Provider-Filter helfen, ersetzen aber keine anwendungsspezifische Autorisierung, Datenisolation, Tool-Policy und eigene Tests.
„Unser Agent braucht viele Rechte, sonst ist er nutzlos.“
Rechte werden pro Aufgabe und Aktion minimiert. High-Impact-Schritte benötigen zusätzliche Freigabe statt dauerhafter Vollmacht.
„Wir loggen alle Chats.“
Vollständige Chats können selbst ein Datenschutz- und Leakage-Risiko sein. Security-relevante Events müssen datensparsam, geschützt und auswertbar protokolliert werden.
R-006 ist vollständig, wenn …
- AI-spezifisches Threat Model und Angriffsflächenregister vorliegen.
- IAM, MFA, RBAC, Least Privilege und Access Reviews funktionieren.
- Secrets, Schlüssel und Tokens geschützt und rotierbar sind.
- Tool-Aufrufe, Outputs, Netzwerk und Egress technisch begrenzt sind.
- Tenant- und Datenisolation durch Negativtests bestätigt sind.
- Injection-, Exfiltration-, Poisoning- und Missbrauchstests bestanden sind.
- Logging, SIEM, Alerts, Incident Runbook und Kill Switch getestet sind.
- Findings, Restrisiko, Owner, Review und Release Gate dokumentiert sind.