MAESTRO — die Architektur hinter den Bedrohungen.
Ein Bedrohungskatalog nennt, was schiefgehen kann. MAESTRO nennt, wo in einem laufenden agentischen System jeder Ausfall sitzt.
MAESTRO — Multi-Agent Environment, Security, Threat, Risk, and Outcome — ist ein Threat-Modeling-Framework der Cloud Security Alliance speziell für agentische KI-Systeme. Es gliedert ein Multi-Agent-Deployment in sieben Architektur-Ebenen plus eine schichtübergreifende und fragt je Ebene, welche Komponenten eines laufenden Systems geprüft werden müssen. Hier ist es eine zweite Linse über dieselben 15 agentischen Bedrohungen: Die Sicherheitsübersicht gruppiert sie danach, wo ein Angriff eintritt — MAESTRO danach, welche Architektur-Ebene den Ausfall verantwortet.
Warum MAESTRO – und nicht STRIDE oder PASTA
Allgemeine Threat-Modeling-Frameworks wurden für deterministische Software gebaut. Agentische Systeme brechen fünf ihrer Annahmen auf einmal — autonome, nicht-deterministische Entscheidungen; adversariale Machine-Learning-Angriffe auf das Modell selbst; emergente Multi-Agent-Interaktion und -Kollusion; Zielfehlausrichtung; und eine KI-spezifische Supply-Chain aus Modellen, Datensätzen und Tools. MAESTRO existiert, um genau diese Lücken zu schließen.
STRIDE
FokusMicrosofts Bedrohungskategorien-Mnemonik (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) für Software-Komponenten.
Die agentische Lücke, die es offenlässtSetzt einen statischen, deterministischen Komponentengraphen voraus — kein Modell für Agenten-Autonomie, adversariales ML oder emergentes Multi-Agent-Verhalten.
PASTA
FokusRisikozentrierter, siebenstufiger Prozess, der Geschäftsziele mit technischen Bedrohungen abgleicht.
Die agentische Lücke, die es offenlässtSeine Stufen setzen ein entworfenes, vorhersagbares System voraus; autonome Entscheidungsfindung und ML-spezifische Angriffsflächen werden nicht modelliert.
LINDDUN
FokusPrivacy-Threat-Modeling (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance).
Die agentische Lücke, die es offenlässtBeschränkt auf Privacy; äußert sich nicht zu Agenten-Autonomie, Tool-Missbrauch oder Multi-Agent-Sicherheit.
OCTAVE
FokusOrganisatorische, asset-getriebene Risikobewertung (operationally critical threat, asset, and vulnerability evaluation).
Die agentische Lücke, die es offenlässtOperiert auf strategischer/organisatorischer Ebene, nicht auf der technischen agentischen Runtime; keine ML- oder Agentenverhaltens-Bedrohungen.
Trike
FokusAnforderungs- und Audit-Risikomodell auf Basis von Akteur–Asset–Aktion-Matrizen.
Die agentische Lücke, die es offenlässtManuell und deterministisch; skaliert nicht auf autonome, unvorhersagbare Agenten oder emergente Interaktion.
VAST
FokusVisual, Agile, Simple Threat Modeling, das über Prozess-/Anwendungsflussdiagramme im Enterprise-DevOps skaliert.
Die agentische Lücke, die es offenlässtFür traditionelle Software-Pipelines gebaut; keine Abdeckung von Agenten-Autonomie, adversarialem ML oder Multi-Agent-Kollusion.
Eine Referenzarchitektur, Einzelagent und Multi-Agent
Dieselben 15 Bedrohungen — zwei Linsen
Die Sicherheitsübersicht gruppiert die Bedrohungen danach, wo ein Angriff eintritt; MAESTRO danach, welche Architektur-Ebene den Ausfall verantwortet. Bewege den Zeiger über eine Bedrohung — sie leuchtet in beiden Linsen auf, und ihre Verortung erscheint oben.
Nach Angriffsfläche
Der Vertrauens- und Datenfluss durch einen Agenten definiert fünf Angriffsflächen. In einem MAS trägt die Inter-Agent-Fläche die meisten Bedrohungen — sie existiert erst, weil Agenten einander delegieren und vertrauen.
Alles, was das System liest — Nutzer-Prompts und nicht vertrauenswürdige Inhalte, die ein Agent aufnimmt —, wo Injection eindringt.
Persistenter Zustand und abgerufener Kontext, wo vergiftetes Memory jede spätere Entscheidung verzerrt.
Die Tools und externen Daten, die ein Agent aufruft, wo Missbrauch und vergiftete Ergebnisse Reichweite in Risiko verwandeln.
Nachrichten zwischen Agenten, wo ein vergifteter oder gefälschter Peer eine Kompromittierung durch das gesamte System trägt.
Was das System ausgibt oder auslöst, wo unvalidierte Ausgaben und übermäßige Autonomie realen Schaden verursachen.
Nach MAESTRO-Ebene
Jede Bedrohung sitzt dort, wo ihr Ausfall verantwortet wird — vom Foundation Model bis zum Agenten-Ökosystem, plus eine Ebene, die alle durchzieht. Einige treffen mehrere Ebenen.
Foundation Model
Ob dem zugrunde liegenden Modell und seinen Trainingsdaten vertraut werden kann — resistent gegen Poisoning und im Einklang mit seinem beabsichtigten Alignment.
Data Operations
Die Integrität von Vektor-Speichern, Retrieval-Pipelines und dem Prompt-Assembly, das den Arbeitskontext eines Agenten speist.
Agent Frameworks
Die Ausführungslogik, Workflow-Kontrolle und Autonomiegrenzen, die bestimmen, wie ein Agent plant und handelt.
Deployment & Infrastructure
Runtime- und Container-Sicherheit, Orchestrierung, Netzwerk und die MLSecOps-Pipeline, auf der ein Agent läuft.
Evaluation & Observability
Monitoring, Alerting, Logging und die Human-in-the-Loop-Schnittstellen, die das Verhalten eines Agenten nachvollziehbar machen.
Security & Compliance
Zugriffskontrolle, Policy-Durchsetzung und die regulatorischen Vorgaben, innerhalb derer ein Agent operieren muss.
Agent Ecosystem
Wie ein Agent mit Menschen, externen Tools und anderen Agenten im weiteren Ökosystem interagiert, an dem er teilnimmt.
Eine konkrete Kaskade: Ein Angreifer nutzt eine Schwachstelle in der Container-Infrastruktur (Ebene 4 — Deployment & Infrastructure) aus und erlangt Zugriff auf eine laufende Agenten-Instanz; von dort aus schleust er bösartige Daten in den Datenspeicher des Agenten ein (Ebene 2 — Data Operations), was das nächste Modell-Update vergiftet und so das Foundation Model kompromittiert (Ebene 1). Eine Ursache, drei Ebenen.
Der MAESTRO-Workflow
MAESTRO schreibt einen sechsstufigen Workflow vor, der die Sieben-Ebenen-Architektur auf ein konkretes Deployment anwendet und mit der Weiterentwicklung des Systems iteriert.
System-Dekomposition
Das System entlang der sieben Ebenen in Komponenten zerlegen; Fähigkeiten, Ziele und Interaktionen jedes Agenten definieren.
Ebenenspezifisches Threat-Modeling
Die eigene Bedrohungslandschaft jeder Ebene durchgehen und die identifizierten Bedrohungen auf die Besonderheiten des Systems zuschneiden.
Identifikation ebenenübergreifender Bedrohungen
Die Interaktionen zwischen den Ebenen analysieren und Schwachstellen-Kaskaden nachverfolgen, die keine einzelne Ebene für sich zeigt.
Risikobewertung
Wahrscheinlichkeit und Auswirkung jeder Bedrohung bewerten und mit einer Risikomatrix priorisieren.
Mitigationsplanung
Ebenenspezifische, ebenenübergreifende und KI-spezifische Mitigationen für die priorisierten Bedrohungen planen.
Umsetzung und Monitoring
Die Mitigationen umsetzen, fortlaufend auf neue Bedrohungen überwachen und das Threat-Modell mit der Weiterentwicklung des Systems aktualisieren.
Sicherheit