Zehn Projekte, ein Stack: Warum die AAIF-Konsolidierung die Sicherheitsfrage neu stellt

📷 "Apollo Guidance Computer (AGC) and Navigation System from the second Lunar Module, LM-2" by jurvetson is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Am 22. Oktober 2026 nahm die Agentic AI Foundation (AAIF) vier weitere Projekte auf: Agent Skills (Anthropic), Open Responses (OpenAI), OpenEnv (Hugging Face) und OpenSandbox (Alibaba). Die im Dezember 2025 mit drei Projekten gestartete Stiftung hostet damit nach elf Monaten zehn. Gut für adoptierende Teams – und Anlass für eine Frage, die oft untergeht: Was heißt es, wenn ein großer Teil der Trust-Annahmen des Agenten-Stacks unter einem Dach liegt?

Von drei auf zehn Projekte

Die AAIF ist ein Projekt der Linux Foundation, gegründet am 9. Dezember 2025 mit MCP, goose und AGENTS.md als Gründungsprojekten. Bis August 2026 wuchs sie auf mehr als 250 Mitglieder. Die zehn Projekte decken fast jede Schicht eines Agenten-Betriebs ab: MCP für Tool- und Datenzugriff, A2A für Agenten-Kommunikation, Open Responses als Modellschnittstelle, AGENTS.md und Agent Skills als instruktionstragende Formate, agentgateway und Agent Router als Traffic-Control-Plane, goose als Runtime sowie OpenEnv und OpenSandbox für Evaluierung und Isolation. Das ist eine Landkarte der Abhängigkeiten.

Zwei Achsen: A2A und MCP

MCP verbindet einen Agenten mit Dingen, die keine Agenten sind: Datenbanken, Dateisysteme, interne APIs. A2A verbindet einen Agenten mit einem anderen Agenten – potenziell von einer anderen Firma, auf einem anderen Modell, in einer anderen Organisation. A2A definiert Discovery über Agent Cards, Task-Delegation und Ergebnis-Austausch.

A2A erreichte im März 2026 die stabile v1.0-Spezifikation und ist seit dem 17. August 2026 Growth-Stage-Projekt der AAIF – im selben Haus wie MCP, aber mit getrennter Spezifikation. Die Stiftung nennt mehr als 150 unterstützende Organisationen und Produktionseinsätze in Lieferketten, Finanzdienstleistungen und mobilen Plattformen. Gemeinsame Governance heißt nicht gemeinsame Spezifikation: Die Protokolle bleiben eigenständig.

Seit dem 1. Oktober 2026 gibt es die offizielle A2A CLI – eine Oberfläche für Skripte, CI-Pipelines und Coding-Agenten:

# Agent Card eines entfernten Agenten lesen
a2a card get https://agent.example.com

# Auftrag senden und auf das Ergebnis warten
a2a send -a https://agent.example.com "Fasse dieses Dokument zusammen"

JSON-Ausgaben und definierte Exit-Codes machen sie automatisierbar; a2a server --exec verwandelt jedes stdin/stdout-Programm in einen A2A-Server – für Tests, nicht für Produktion.

Neutrale Governance ist kein Sicherheitsversprechen

Hier setzt die Analyse der Cloud Security Alliance (CSA) vom 29. Oktober 2026 an: Die AAIF löst das Governance-Problem, nicht das Sicherheitsproblem. Die öffentliche Projektliste führt zehn Projekte ohne Reifegrad- oder Security-Labels. Anders als bei der CNCF, deren Graduation ein externes Security-Review voraussetzt, fand die CSA keine veröffentlichte stiftungsweite Baseline – kein verpflichtendes Threat-Model, kein einheitlicher Disclosure-Prozess, kein Dritt-Audit für alle Projekte.

Dazu kommt ein stilles Migrationsrisiko: Die MCP-Revision vom 28. Juli 2026 entfernte Sessions auf Protokollebene, inklusive Mcp-Session-Id. Tooling, das Aktivität über Session-IDs korreliert oder beim Initialisierungs-Handshake Policy-Entscheidungen trifft, kann Sichtbarkeit verlieren, ohne einen Fehler zu melden. Neue Anknüpfungspunkte sind die Header Mcp-Method und Mcp-Name sowie OpenTelemetry-Trace-Propagation.

Instruktionen als Supply Chain

Am unangenehmsten: die instruktionstragenden Formate. A2A v1.0 führte signierte Agent Cards ein, mit denen sich Identität und beworbene Fähigkeiten kryptografisch prüfen lassen. Die Agent-Skills-Spezifikation definiert Pflichtfelder für name und description, optionale Metadaten und ein experimentelles allowed-tools-Feld – aber nichts für Signatur, Hashing, Publisher-Identität oder Provenienz. AGENTS.md ist bewusst noch leichter gehalten. Beide tragen Anweisungen, die ein Agent mit erheblichen Rechten ausführt – ohne eingebaute Prüfung, wer sie geschrieben hat.

Eine Snyk-Studie vom Februar 2026 untersuchte 3.984 Skills aus öffentlichen Marketplaces: 534 (13,4 Prozent) hatten mindestens ein Critical-Problem, 1.467 (36,8 Prozent) mindestens ein Sicherheitsproblem, 76 bösartige Payloads wurden manuell bestätigt. Für MCP-Registries fand eine OX-Security-Analyse über 15.465 Server kein konsistentes Autorisierungsmodell und keine einheitliche Lifecycle-Verantwortung. Wer Skills und Server als Konfiguration behandelt statt als Softwareabhängigkeit, hat die Supply Chain offen.

Der Gateway als Single Point of Failure

Zwei der zehn Projekte sind Gateways – eine Position mit ungewöhnlicher Hebelwirkung. agentgateway routet LLM-Traffic über eine OpenAI-kompatible API, unterstützt MCP-Tool-Server und A2A und erzwingt JWT-, API-Key- und MCP-Authentifizierung sowie rollenbasierte Autorisierung in CEL. Agent Router, hervorgegangen aus dem Envoy AI Gateway und am 10. September 2026 zur AAIF gewechselt, verbindet Anwendungen mit Modellen und MCP-Tools und verwaltet Backend-Credentials über eigene Policy-Ressourcen.

Ein Gateway vor Agenten-Traffic ist eine verbreitete Empfehlung. Eines, das MCP-, A2A- und Modell-Traffic gleichzeitig terminiert, wird aber zum Punkt, an dem ein Parsing-Fehler oder ein Credential-Leak alle Protokolle trifft. Da OpenEnv MCP-Schnittstellen und OpenSandbox Ausführungs-APIs bereitstellen, kann eine Schwachstelle in gemeinsam genutzten Komponenten Gateway, Evaluierungsumgebung und Runtime zugleich betreffen. Eine koordinierte projektübergreifende Vulnerability-Behandlung auf Stiftungsebene ist öffentlich nicht dokumentiert.

Was Teams jetzt tun sollten

Zuerst ein Inventar: Welche der zehn Projekte sind im eigenen Umfeld vorhanden, auch indirekt über Vendor-Produkte, und welche Revision implementiert jede Komponente? AGENTS.md-Dateien und Skills verdienen dieselbe Aufmerksamkeit wie Code – Review bei Änderungen, Installation nur aus einer Allowlist, Scanning auf eingebettete Skripte und Instruction Injection. Danach: MCP- und A2A-Traffic durch ein policy-durchsetzendes Gateway routen und das Gateway selbst patchen; bei A2A signierte Agent Cards bevorzugen und unsigned Cards externer Parteien ablehnen; Monitoring von Session-IDs auf Header und Trace-Context umbauen; Agent-Code in eine Isolationsgrenze mit minimalen Rechten legen.

Fazit

Die Konsolidierung ist strategisch richtig: Sie nimmt Herstellern die Möglichkeit, über einen proprietären Konnektor Lock-in zu erzeugen, und gibt Architekturgremien eine neutrale Vertragspartei. Nur folgt daraus keine Sicherheitszusage. Die Stiftung verwaltet zehn Artefakte mit eigenen Maintainern, Release-Zyklen und Sicherheitshistorien; die Reife ist sichtbar ungleich.

Entscheidend sind die nächsten Monate an zwei Stellen: ob Agent Skills eine Signatur- und Provenienz-Erweiterung bekommt, vergleichbar mit A2A-Agent-Cards, und ob eine stiftungsweite Baseline aus Threat-Model, Disclosure-Prozess und Conformance-Tests entsteht. Solange beides fehlt, bleibt der AAIF-Stack eine Landkarte der Abhängigkeiten – und eine Einladung, jede davon selbst zu prüfen.