Das Projekt asago: Open Source-Orchestrierung von KI-Sicherheit und Governance

Heute hat Red Hat asago angekündigt, ein gemeinschaftliches Open Source-Projekt für KI-Sicherheit in Partnerschaft mit Alquimia AI, Brave Software, der EvalEval-Koalition, IBM Research, der Interdisciplinary Transformation University Austria, Microsoft, dem MIT Lincoln Laboratory, der North Carolina State University, NVIDIA und dem Alan Turing Institute. In diesem Blog-Beitrag möchte ich näher erläutern, warum eine neue Community notwendig ist, welche Ziele wir verfolgen und wie der aktuelle Stand ist.

Das Open Source-Ökosystem für KI-Sicherheit ist vielfältig. Es gibt viele ausgereifte Projekte in den Themenbereichen wie Guardrails (Leitplanken), Evals, Red Teaming und agentischer Sicherheit. Diese werden durch umfassende Risiko-Frameworks, Ontologien und Mappings ergänzt. Diese wichtigen Projekte erfordern eine kontinuierliche Weiterentwicklung. Das KI-Sicherheitsteam von Red Hat arbeitet mit vielen dieser Upstream-Communities zusammen, leistet Beiträge und wird dies auch künftig tun.

Zusätzliche Herausforderungen für Unternehmen im Bereich KI-Sicherheit

Typische Unternehmen stehen jedoch über diese Tools hinaus vor weiteren Herausforderungen. Beim Onboarding neuer, potenziell individuell entwickelter KI-Agenten sind weitere Stakeholder, Assets und Prozesse beteiligt, die von bestehenden Tools nicht abgedeckt werden.

Das Onboarding neuer Agenten folgt in der Regel diesem Prozess:

• Richtlinienentwicklung: Teams erstellen schriftliche Richtliniendokumente, welche die Vorgaben für den KI-Einsatz im Unternehmen festlegen. Dabei beziehen sie sich häufig auf externe Vorschriften wie die KI-Verordnung der EU und ergänzen diese teils durch spezifische Einschränkungen für einzelne Use Cases (etwa strengere Regeln für KI-Agenten im Kundenkontakt).
• Risikoextraktion: Diese Dokumente müssen analysiert werden, um die darin enthaltenen theoretischen Risiken zu identifizieren.
• Risikopriorisierung: Es muss entschieden werden, welche dieser theoretischen Risiken auf den spezifischen Agenten zutreffen und welche technischen Risiken tatsächlich testbar sind.
• Generierung von Szenarien und Red Teaming: Technische Teams entwickeln anschließend Testszenarien für diese Risiken und führen sie in bestehenden Red Teaming-Frameworks aus.
• Iteration: Anschließend werden die Ergebnisse interpretiert, Leitplanken oder andere Korrekturen angewendet und der Agent erneut getestet, bis er bereit für das Deployment ist. Ein manueller Prozess verursacht jedes Mal einen erheblichen Mehraufwand.

Dieser Prozess führt zu verzögerten Freigaben und lückenhaften Audit-Trails. Dadurch lässt sich gegenüber internen oder externen Auditoren nur schwer nachweisen, was tatsächlich unternommen wurde.

Mit asago Probleme gemeinsam lösen

Das Projekt asago soll diese Herausforderungen bewältigen. Wir unterstützen Unternehmen dabei, ihre KI-Richtlinien in die Produktion zu überführen, ohne dass dafür Fachwissen für KI-Sicherheit erforderlich ist. Unser Ziel ist es nicht, bestehende Tools für KI-Sicherheit zu ersetzen. Vielmehr fungiert asago als Orchestrierungsschicht, um die Komponenten des IT-Ökosystems miteinander zu verbinden. Wir integrieren die besten verfügbaren Tools und schließen bestehende Lücken.

Dies muss natürlich ein gemeinschaftlicher Prozess sein. Wir sind überzeugt, dass kein Unternehmen dies allein bewältigen kann oder sollte. Angesichts der Vielfalt an Richtliniendokumenten, Modell- und Agententypen sowie Bereitstellungskontexten erfordert ein solches Projekt unterschiedliche Standpunkte. Vielfältiges Fachwissen ist dabei unverzichtbar.

Deshalb arbeiten wir mit Partnern aus Technologieunternehmen, Forschungseinrichtungen, Community-Allianzen und Regierungsorganisationen zusammen. Gemeinsam entwickeln wir nicht nur den Code, sondern stellen auch sicher, dass wir die relevanten Fragen stellen und beantworten. Als globale Community müssen wir eine ausreichende sprachliche und geografische Repräsentation sicherstellen. Wir starten mit Partnern in den USA, im Vereinigten Königreich und in Europa. Wir laden weitere Mitwirkende ein, sich uns über die unten stehenden Links anzuschließen.

Eine sich weiterentwickelnde technische Architektur

Die technische Architektur wird sich mit dem Projekt weiterentwickeln. Hier ist unsere erste Vorschau. Das Verfahren ist in 2 Abschnitte unterteilt:

Abbildung 1: Blaue Knoten stellen Daten dar. Gelbe Knoten stellen funktionale Komponenten dar.

Vom Richtliniendokument zu Szenarien

Im ersten Abschnitt werden Risiken aus Richtliniendokumenten extrahiert und dem IBM Risk Atlas zugeordnet. Diese in einer Risk Card indexierten Risiken decken die gesamte Bandbreite der theoretischen Risiken ab, die Gegenstand der Richtlinie sind. Einige davon sind technische Risiken, die sich mit asago automatisieren und beheben lassen. Die Hauptkomponente hierfür ist der Policy Mapper.

Die nächste Herausforderung besteht darin, das passende Szenario für das Red Teaming zu erstellen. Dies ist noch nicht spezifisch für eine bestimmte Library. Der Scenario Generator bewertet die Besonderheiten des jeweiligen Agenten im Hinblick auf die identifizierten Risiken und prüft die erforderlichen Testarten. Diese bilden das Szenario. An diesem Punkt verfügen wir über eine Reihe von Szenarien. Diese können für den spezifischen Agenten im Kontext der Unternehmensrichtlinien evaluiert und abgewehrt werden.

Abbildung 2: Blaue Knoten stellen Daten dar. Gelbe Knoten stellen funktionale Komponenten dar.

Iterative Szenarien für Empfehlungen über Red Teaming

Im zweiten Abschnitt, einer iterativen Schleife, nutzen wir diese Szenarien zur Erstellung von Run-Artefakten für die entsprechenden Red Teaming- oder Eval-Frameworks. Hier beginnt der datengesteuerte Ansatz. Gängige Eval- und Red Teaming-Frameworks werden auf EvalHub mit synthetisch generierten Datensätzen und Umgebungen ausgelöst, die auf die Szenarien abgestimmt sind.

Die Ergebnisse werden an einen Recommender-Prozess weitergeleitet, um Lösungsvorschläge für Fehler beim Red Teaming bereitzustellen. Wir planen ein flexibles Spektrum an Empfehlungen, das mit Leitplanken beginnt und künftig weitere Komponenten des Stacks umfasst. Diese Komponenten sind bereitstellbar (etwa mit Kubernetes Custom Resources (CRs) oder ConfigMaps) und lassen sich erneut testen.

Dies ist lediglich die anfängliche Architektur. Die Architektur wird sich gemeinsam mit der Community weiterentwickeln.

Was können Sie heute tun?

Unsere heutige Ankündigung zeigt die Roadmap für die Community auf. Die Entwicklung ist bereits aktiv, sodass Sie schon jetzt mit unserer Arbeit experimentieren können. Auf der GitHub-Seite von asago können Sie bereits die Arbeit zum Policy Mapping hier einsehen, Beispiele finden Sie hier. Sehen Sie sich auch midojo an, ein Open Source-Framework für Sicherheitstests von KI-Agenten gegen Indirect Prompt Injection.  

Schließlich können Sie und Ihr Unternehmen sich uns als Mitwirkende anschließen. Wir benötigen Input von vielen Organisationen, insbesondere aus verschiedenen Sprachräumen, Kulturen und Regionen. Erfahren Sie hier mehr und beteiligen Sie sich.

Das beste Ergebnis für KI-Sicherheit ist eines, das nicht von einem einzelnen Unternehmen kontrolliert wird. Das Projekt asago ist unser Beitrag zu diesem Ziel – mit einer Infrastruktur, die von einer offenen Community mit vielfältigen Perspektiven entwickelt wird. Das Projekt befindet sich noch in der Anfangsphase. Es gibt noch viel zu tun. Genau deshalb ist jetzt der beste Zeitpunkt, um sich mit einzubringen.