Sicherheitsbewertung & Härtung

Unser Ansatz besteht darin, KI-Systeme so anzugreifen, wie es reale Angreifer tun, und sie anschließend gegen die im Rahmen eines Assessments identifizierten Angriffspfade zu härten — von der Modellextraktion bis zur Kompromittierung der Lieferkette. Herkömmliche Penetrationstests decken Ihre APIs, Infrastruktur und Authentifizierungsabläufe ab, prüfen jedoch nie, ob ein Angreifer Ihr feinabgestimmtes Modell stehlen, eine Backdoor in Ihre Abhängigkeitskette einschleusen oder Ihre RAG-Pipeline kapern kann. Diese Assessment-Methodik muss speziell auf die Fehlermodi von KI-Systemen zugeschnitten sein.

Angriffsflächen, die Ihr Sicherheitsteam noch nie getestet hat

Herkömmliche Penetrationstests decken Ihre APIs, Ihre Infrastruktur und Ihre Authentifizierungsabläufe ab. Sie testen nicht, ob ein Angreifer Ihr feinabgestimmtes Modell über 50,000 sorgfältig strukturierte Abfragen extrahieren kann. Sie erkennen nicht, ob ein vergifteter LoRA-Adapter in Ihrer HuggingFace-Abhängigkeitskette vor drei Monaten eine Backdoor eingeschleust hat. Sie prüfen nicht, ob Ihre RAG-Pipeline Anweisungen ausführt, die in ein abgerufenes Dokument eingebettet sind. Das sind die Angriffspfade, die KI-Systeme in der Produktion tatsächlich kompromittieren.

Dies sind keine theoretischen Risiken aus Konferenzvorträgen. Protect AI fand 352,000 verdächtige Dateien in 51,700 Modellen auf HuggingFace im April 2025. KI-gestützte Angriffe stiegen um 89% im Jahresvergleich, wobei 97% der kompromittierten Unternehmen über keine grundlegenden Zugriffskontrollen auf ihren KI-Systemen verfügten. Der Mercor-Lieferkettenangriff Anfang 2026 kompromittierte Tausende von Unternehmen über eine einzige Open-Source-Abhängigkeit.

Was wir tatsächlich testen — und was die meisten Assessments übersehen

Wir strukturieren Assessments entlang des MITRE ATLAS -Frameworks, das mittlerweile 84 Techniken über 16 Taktiken hinweg katalogisiert, die spezifisch auf KI-Systeme abzielen. Doch ein Framework ist eine Landkarte, kein Test. Unsere Methodik ist darauf ausgelegt, die katalogisierten Angriffe tatsächlich auszuführen, statt sie nur abzuhaken.

LLM-Deployments und Prompt-Injection

Wir testen indirekte Prompt-Injection über jeden Ingestion-Pfad: RAG-Retrieval, Tool-Ausgaben, von Nutzern hochgeladene Dokumente und an Agenten übermittelte E-Mail-Inhalte. Direkte Injection beherrscht die Schlagzeilen, aber Anthropic hat seine Metrik für direkte Injection im Februar 2026 vollständig eingestellt , weil indirekte Injection über den Retrieval-Kontext das ist, was Produktionssysteme tatsächlich zum Einsturz bringt. Zudem testen wir Multi-Turn-Manipulation, System-Prompt-Extraktion und die spezifischen Fehlermodi jedes von Ihnen eingesetzten Guardrail-Stacks.

Sicherheit auf Modellebene

Wir bewerten das Extraktionsrisiko, indem wir strukturierte Abfragekampagnen gegen Ihre API durchführen und messen, wie viel des Modellverhaltens ein Angreifer replizieren kann. Wir evaluieren die adversariale Robustheit sowohl mit gradientenbasierten Methoden (sofern wir Modellzugriff haben) als auch mit transferbasierten Blackbox-Angriffen (wie reale Angreifer vorgehen). Wir auditieren Ihre Trainingspipeline auf Schwachstellen durch Datenvergiftung (Data Poisoning) und prüfen sowohl Ihre direkten Trainingsdaten als auch die vorgelagerten Abhängigkeiten, aus denen sie stammen (ausführlich beschrieben in unserer Forschung zum Schutz von Unternehmen gegen Modellvergiftung).

Integrität der Lieferkette

Wir verfolgen jedes Modellartefakt bis zu seiner Quelle zurück: vortrainierte Gewichte, Fine-Tuning-Datensätze, Adapter-Schichten und Versionen von Serving-Frameworks. Wir prüfen Ihre ML-Infrastruktur auf bekannte Schwachstellen — PyTorch, vLLM und Triton Inference Server wiesen 2025–2026 allesamt CVEs auf — und verifizieren, dass Ihre Modellserialisierung sichere Formate nutzt. Die $12 Milliarden an Verlusten durch kompromittierte ML-Modelle im Jahr 2025 stammten überwiegend aus Lieferkettenangriffen, nicht aus direkter Modellausnutzung (siehe unsere Forschung zur Absicherung des ML-Lieferketten-Lebenszyklus).

Agentische Systeme

Wir testen die Angriffsfläche, die die OWASP Agentic AI Top 10 definiert: Ziel-Hijacking (Goal Hijacking), Werkzeugmissbrauch (Tool Misuse), Identitätsmissbrauch, Speichervergiftung (Memory Poisoning) und kaskadierende Ausfälle über Multi-Agenten-Workflows hinweg. Die OpenClaw-Krise im Jahr 2026 — bei der 21,000+ Instanzen eines KI-Agenten mit 135,000 Sternen kritischen Schwachstellen ausgesetzt waren — zeigte, was geschieht, wenn Agenten ohne solche Tests ausgeliefert werden (ausführlich beschrieben in unserer Forschung zur Absicherung der Mensch-KI-Schnittstelle).

Härtung, die die Funktionsweise Ihres Systems nachhaltig verändert

Ein Assessment ohne Remediation ist lediglich ein teures PDF. Unser Ansatz integriert die Härtungskontrollen direkt in Ihr System.

• Abwehr auf Inferenzebene: Erkennung von Abfrageanomalien, die Datenverkehr mit Extraktionsmustern identifiziert — systematische Eingabeabdeckung, Grenzbereichssondierung und automatisierte Paraphrasierungsdurchläufe — und ihn von legitimer Nutzung unterscheidet. Eingabevalidierungspipelines werden auf Ihr spezifisches Bedrohungsmodell abgestimmt, statt generische Regex-Filter einzusetzen, die semantische Angriffe übersehen und legitime Abfragen blockieren.
• Härtung der Lieferkette: Modellverifikations-Pipelines, die die Provenienz von Artefakten prüfen, Serialisierungsformate validieren, auf bekannte bösartige Muster scannen und Signaturanforderungen durchsetzen, bevor ein Modellartefakt in Ihre Deployment-Pipeline gelangt — plus Abhängigkeitsüberwachung, die kompromittierte vorgelagerte Pakete abfängt, bevor sie die Produktion erreichen.
• Härtung agentischer Systeme: Berechtigungsgrenzen für den Tool-Zugriff, Ausgabevalidierung zwischen einzelnen Agentenschritten und Verhaltensüberwachung, die erkennt, wenn das Ausführungsmuster eines Agenten von seinem erwarteten Workflow abweicht.

Ihr SIEM wurde entwickelt, um Anomalien im menschlichen Verhalten zu erkennen. Ein Agent, der 10,000 Abfragen in Folge ausführt, wirkt auf solche Systeme völlig normal, selbst wenn er unter der Kontrolle eines Angreifers steht.

Wann Sie dies nicht benötigen

Wenn Sie eine verwaltete API (OpenAI, Anthropic, Google) ohne Fine-Tuning, ohne RAG, ohne Tool-Nutzung und ohne sensible Daten in Prompts aufrufen, beschränkt sich Ihr Sicherheitsrisiko auf API-Schlüsselverwaltung und Datenhandhabung. Eine standardmäßige Überprüfung der Anwendungssicherheit deckt dies ab — Sie benötigen kein KI-spezifisches Assessment.

Wenn es sich bei Ihrem Modell um einen einfachen Klassifikator handelt, der intern ohne externe API und ohne Re-Training-Pipeline betrieben wird, ist Ihre Angriffsfläche begrenzt und eine kurze Überprüfung des Bedrohungsmodells angemessen. Vollständige Tests der adversarialen Robustheit für einen internen Stimmungsanalyse-Klassifikator hinter einer Firewall hieße, $30,000 auszugeben, um ein Risiko von $500 abzusichern.

Wir sagen dies in aller Deutlichkeit, weil Glaubwürdigkeit für uns mehr zählt als Umsatz. Die Unternehmen, die diese Arbeit benötigen, wissen genau, wer sie sind: jeder mit feinabgestimmten Modellen, RAG-Pipelines zur Verarbeitung externer Inhalte, agentischen Systemen mit Werkzeugzugriff, Modellen in regulierten Branchen oder KI-Systemen, die Entscheidungen mit finanziellen oder sicherheitsrelevanten Konsequenzen treffen.

Der regulatorische Druck ist real und hat Fristen

Die Durchsetzung des EU AI Act beginnt im August 2026. Hochrisiko-KI-Systeme erfordern ein dokumentiertes Risikomanagement, technische Robustheitstests und Data-Governance-Kontrollen. Bei Nichteinhaltung drohen Bußgelder von bis zu 7% des weltweiten Jahresumsatzes oder EUR 35 Millionen. Das NIST hat sein Cybersecurity Framework Profile for AI im Dezember 2025 veröffentlicht, welches KI-spezifische Risiken auf CSF 2.0-Kontrollen abbildet. Diese Frameworks tauchen nun zunehmend in Beschaffungsanforderungen und Risikoprüfungen auf Vorstandsebene auf.

Die Herausforderung besteht darin, dass kein einzelnes Framework alle Aspekte abdeckt. Wir ordnen Ihre Assessment-Ergebnisse denjenigen Frameworks zu, die Ihre Aufsichtsbehörden, Prüfer und Kunden fordern — und erzeugen so Nachweise, die Compliance-Anforderungen erfüllen, weil sie aus echten Tests stammen und nicht aus reinen Checklisten-Übungen.

Plattform-Tools vs. individuelles Assessment

Automatisierte KI-Sicherheitsplattformen (HiddenLayer, Mindgard, Giskard) führen bekannte Angriffsmuster in großem Maßstab aus. Sie sind nützlich für kontinuierliche Regressionstests nach einem ersten Assessment, stellen jedoch keinen Ersatz für das initiale Assessment selbst dar. Ein Scanner versteht Ihre Geschäftslogik nicht, weiß nicht, welche Modellausgaben sicherheitskritische Konsequenzen haben, und kann nicht beurteilen, ob Ihr Bedrohungsmodell Ihrer tatsächlichen Deployment-Architektur entspricht.

Wir setzen diese Tools dort ein, wo sie einen Mehrwert schaffen. Kontinuierliches automatisiertes Red Teaming gehört in Ihre CI/CD-Pipeline, sobald wir festgelegt haben, worauf getestet werden muss. Doch die Angriffspfade, auf die es in Ihrem konkreten System am meisten ankommt, erfordern jemanden, der sowohl die KI-Fehlermodi als auch Ihren betrieblichen Kontext versteht, um sie aufzuspüren.

Für Unternehmen, die Modelle mehrerer KI-Anbieter (OpenAI, Anthropic, Google, Open-Source-Modelle) einsetzen, bewerten wir die Sicherheitsgrenzen jedes Anbieters unabhängig und testen die Integrationspunkte, an denen Daten zwischen ihnen fließen. Die Angriffsfläche eines Multi-Vendor-Stacks ist nicht die bloße Summe der Risiken der einzelnen Anbieter — sie liegt in der Interaktionsschicht, an der Annahmen über die Sicherheitsgarantien eines Anbieters bei der Übergabe an einen anderen zusammenbrechen.