Agent Plugins 1.0: Einmal entwickeln, in ChatGPT, Copilot, Cursor und VS Code ausführen

Daniel Reyes Principal Engineer (KI/ML), YuSMP Group · LLM-Integration, agentische Systeme und KI-natives Produktdesign für Teams in den USA und der EU

Die kurze Antwort

Was Agent Plugins 1.0 tatsächlich ist

Die Spezifikation definiert eine minimale Verzeichnisstruktur für verteilbare KI-Agenten-Erweiterungen. Ein konformes Plugin enthält:

• Ein plugin.json-Manifest mit der Identität des Plugins, der Schema-Version und den Einstiegspunkten.
• Ein optionales skills/-Verzeichnis mit Agent Skills — wiederverwendbare Bündel aus Anweisungen und Ressourcen, die Agenten aufrufen können.
• Eine optionale mcp.json, die die vom Plugin benötigten MCP-Server deklariert und dem Host-Client ermöglicht, Tool-Verbindungen automatisch bereitzustellen.

Das Format verwendet Reverse-Domain-Namespacing für clientspezifische Erweiterungsfelder, sodass Plattformen über die Basisspezifikation hinaus innovieren können, ohne die Interoperabilität zu brechen. Die Spezifikation beschränkt sich bewusst auf die Paketierung: Sie definiert, wie ein Plugin auf dem Datenträger aussieht, nicht wie Clients es installieren, präsentieren oder verteilen. Diese Auslassung ist beabsichtigt — sie ermöglicht es Cursor, eine andere Discovery-UI als VS Code zu bauen, während beide dasselbe Plugin-Verzeichnis lesen.

AWS implementiert Unterstützung an zwei Stellen: Kiro (Amazons KI-IDE, ein Launch-Client) erhält native Agent Plugins-Unterstützung für gebündelte Skills und MCP-Server, und das AWS Agent Toolkit liefert über 30 kuratierte Skills für Lambda, S3, DynamoDB und CDK. Google liefert Unterstützung über seine Agents CLI und das Data Agent Kit, das Agenten mit BigQuery, Spanner und Cloud SQL verbindet. Beide Unternehmen veröffentlichten ihre Implementierungen am selben Tag, an dem die Spezifikation startete.

Sechs Anbieter, eine Spezifikation — und ein auffälliges Fehlen

Die sechs Gründungsmitglieder decken den Großteil des Enterprise-KI-Tooling-Marktes ab. OpenAIs ChatGPT und Codex sind die am weitesten verbreiteten Consumer- und Developer-Endpunkte. Microsofts GitHub Copilot und VS Code erreichen zusammen Dutzende Millionen Entwickler. Amazons Kiro und AWS Agent Toolkit erreichen Enterprise-Cloud-Teams, die auf AWS-Infrastruktur aufbauen. Googles Agents CLI und Data Agent Kit erreichen Data-Engineering-Teams. Cursor und Vercel erreichen die Frontend- und Fullstack-Entwickler-Community direkt.

Das auffällige Fehlen ist Anthropic. Obwohl Anthropic sowohl MCP — das Kommunikationsprotokoll, auf dem Agent Plugins aufbaut — als auch das Agent-Skills-Format entwickelt hat, auf das die Spezifikation aufbaut, ist Anthropic kein TSC-Mitglied, und Claude Code ist zum Start kein kompatibler Client. Das hat praktische Konsequenzen: Teams, die Claude als primäre Agenten-Laufzeit standardisiert haben, können heute kein Agent Plugins-formatiertes Plugin installieren und damit rechnen, dass es funktioniert. Ob Anthropic dem TSC beitritt oder unabhängig kompatible Unterstützung liefert, ist Stand 8. August 2026 nicht angekündigt.

Die Governance-Struktur ist darauf ausgelegt, eine Übernahme durch ein einzelnes Unternehmen zu verhindern. Kein Anbieter hält eine Mehrheit der sechs TSC-Sitze, und die Spezifikation ist auf GitHub für Community-Beiträge offen. Die Satzung beschreibt das Komitee als neutralen Treuhänder — analog zur Art und Weise, wie die OpenJS Foundation Node.js verwaltet, anstatt dass Microsoft oder Google es unilateral kontrollieren.

Was v1.0 enthält — und was es bewusst auslässt

Die Spezifikation liefert ein wohldefiniertes v1.0, anstatt in der ersten Version jedes Problem lösen zu wollen. Was sie definiert: das Verzeichnislayout, das Manifest-Schema, wie Agent Skills deklariert werden, wie MCP-Server-Konfigurationen gebündelt werden und wie Clients das Format unter ihrem eigenen Namespace erweitern können, ohne die Portabilität zu brechen.

Was sie explizit nicht definiert:

• Berechtigungsmodell. Es gibt keinen Standard dafür, welche Fähigkeiten ein Plugin anfordern kann oder wie ein Client den Nutzer auffordern soll, diese zu erteilen.
• Sandboxing. Plugin-Code läuft in der Umgebung des Host-Clients. Die Spezifikation macht keine Aussagen zu Isolation, Ressourcenlimits oder Netzwerk-Egress-Beschränkungen.
• Signaturprüfung. In v1.0 gibt es keinen Mechanismus, mit dem ein Client verifizieren kann, dass ein Plugin von dem veröffentlicht wurde, der es behauptet, oder dass es beim Transport nicht manipuliert wurde.
• Secrets-Management. Plugins können MCP-Server aufrufen, die Zugangsdaten benötigen; wie diese Zugangsdaten gespeichert, rotiert oder widerrufen werden, liegt vollständig im Verantwortungsbereich des Clients.

Das TSC hat alle vier als künftige Aufgaben aufgelistet. Die unmittelbare Konsequenz ist, dass zwei Plugins, die in derselben VS Code-Sitzung installiert sind, dieselbe Vertrauensstufe teilen — es gibt keine feingranulare Eingrenzung. Ein Plugin, das über MCP auf ein internes Data Warehouse zugreift, läuft mit demselben impliziten Vertrauen wie ein Plugin, das Commit-Nachrichten automatisch vervollständigt.

Was das für Software-Teams in den USA, der EU und im DACH-Raum bedeutet

Der Effizienzgewinn bei der Paketierung ist real und unmittelbar. Wenn Ihr Team benutzerdefiniertes KI-Tooling pflegt — einen Skill-Satz, der Ihre internen APIs kapselt, sich mit Ihrem Data Warehouse verbindet oder Ihren Code-Stil durchsetzt — mussten Sie bisher für jedes KI-Tool, das Ihre Entwickler verwenden, separate Integrationen pflegen. Agent Plugins reduziert das auf ein einziges Artefakt, das Sie wie jedes andere interne Paket versionieren, überprüfen und verteilen.

Die geschäftliche Implikation ist, dass das Versprechen „einmal entwickeln, überall ausführen" für Agent Skills nun ohne die Wette auf das proprietäre Erweiterungsformat eines einzelnen Anbieters erreichbar ist. Wenn Ihr Team von Cursor zu VS Code migriert oder GitHub Copilot zu einem Workflow hinzufügt, der bereits ChatGPT Enterprise nutzt, geht das Plugin mit. Diese Portabilität reduziert die Wechselkosten, die Organisationen historisch an einen einzigen KI-Tooling-Anbieter gebunden haben.

Für EU-Teams unter DSGVO und EU-KI-Gesetz ist das fehlende Sicherheitsmodell das erste Compliance-Problem, das vor dem Produktivbetrieb eines Plugins gelöst werden muss. Ein Agent Plugin, das sich mit einem MCP-Server verbindet, der personenbezogene Daten verarbeitet, ist aus datenschutzrechtlicher Sicht eine Auftragsverarbeiterkonfiguration. Dieselben 72-Stunden-Meldepflichten bei Datenpannen, Datensparsamkeitsanforderungen und Auftragsverarbeitungsverträge, die für jedes andere Tool in Ihrem Stack gelten, gelten auch hier. Die Spezifikation wird das nicht durchsetzen; Ihr Compliance-Team benötigt ein Plugin-Review-Gate, das es tut.

Was das für den DACH-Markt bedeutet. Deutschland ist einer der drei größten europäischen Märkte für Enterprise-KI-Tooling — Industrie 4.0, SAP, BMW und Siemens treiben die Adoption, und viele deutsche Entwicklungsteams setzen VS Code und GitHub Copilot bereits im großen Maßstab ein. Agent Plugins bietet diesen SAP/Microsoft-Stack-Teams sofortige Effizienzgewinne. Gleichzeitig kollidiert das in v1.0 fehlende Sicherheitsmodell direkt mit den Empfehlungen des BSI (Bundesamt für Sicherheit in der Informationstechnik): Die BSI Grundschutz-Bausteine und der Mindeststandard KI fordern nachweisbare Zugangskontrolle, Isolation und Auditierbarkeit — genau das, was die Spezifikation als künftige Arbeit auflistet. Für DSGVO-pflichtige Unternehmen gilt zudem: Ein MCP-verbundenes Plugin, das personenbezogene Daten berührt, qualifiziert als Auftragsverarbeiter nach Art. 28 DSGVO und erfordert entsprechende Verträge. FinTech-Anbieter unter DORA müssen Plugin-Installationen darüber hinaus als operationale Risikoquelle behandeln und in ihr IKT-Risikomanagement einbeziehen.

Für FinTech- und HealthTech-Teams, die SOC 2, HIPAA oder DORA unterliegen, bedeutet das fehlende Sandboxing, dass Sie nicht davon ausgehen können, dass ein Plugin eingegrenzt ist. Ein Plugin mit MCP-Server-Zugang kann prinzipiell Produktionsinfrastruktur erreichen — die Spezifikation verhindert das nicht, und v1.0-Clients haben unterschiedliche Niveaus nativer Eingrenzung. Behandeln Sie Plugin-Installationen in regulierten Umgebungen genauso wie jedes andere Drittanbieter-Tool: Sicherheitsüberprüfung, Least-Privilege-Credential-Scoping und Egress-Monitoring vor der Freigabe.

Die Anthropic-Lücke ist ein praktischer Entscheidungspunkt für Teams, die Claude einsetzen. Wenn Ihre Agenten-Workflows heute auf Claude Code oder Claudes Tool-Use-Fähigkeiten basieren, werden Agent Plugins-formatierte Skills auf dieser Plattform zum Start nicht nativ laufen. Sie haben drei Optionen: separate Paketierung für Anthropic-Umgebungen pflegen, abwarten, ob Anthropic Kompatibilität liefert, oder Agenten auf eine TSC-Mitgliedsplattform migrieren. Keine dieser Optionen ist aufwendig, aber die Entscheidung sollte bewusst getroffen werden, bevor ein Entwickler ein Plugin auf Claude zu installieren versucht.

Was jetzt zu tun ist

• Inventarisieren Sie das KI-Tooling Ihres Teams. Welche der sechs Launch-Clients — ChatGPT, Copilot, Cursor, Kiro, VS Code, Codex — nutzen Ihre Entwickler und Data-Teams? Das bestimmt, wie relevant Agent Plugins-Kompatibilität für Sie jetzt ist.
• Definieren Sie eine Plugin-Governance-Richtlinie vor der ersten Installation. Wer kann Plugins für den Produktivbetrieb freigeben? Welche Sicherheitsüberprüfung ist erforderlich? Wo werden MCP-Server-Zugangsdaten gespeichert? Das jetzt zu etablieren, solange das Ökosystem neu ist, ist weit günstiger als ein Datenleck nachträglich aufzuarbeiten.
• Wenn Sie benutzerdefinierte KI-Tools pflegen, prüfen Sie die Agent Plugins-Paketierung. Das Format ist minimal genug, dass die Migration eines bestehenden Skill-Satzes ein überschaubares Projekt ist. Die Auszahlung ist Portabilität über alle aktuellen und künftigen kompatiblen Clients.
• Verfolgen Sie Anthropics Reaktion. Wenn Claude in Ihrem Stack ist, abonnieren Sie Anthropics Changelog und das Agent Plugins-GitHub-Repository für Ankündigungen zur Kompatibilität.
• Gehen Sie nicht davon aus, dass die künftigen Sicherheitsarbeiten der Spezifikation vor Ihrer Compliance-Deadline eintreffen. Planen Sie auf Basis dessen, was v1.0 tatsächlich definiert, nicht was eine künftige Version hinzufügen könnte.

Häufig gestellte Fragen