Agenten, MCP und A2A
Agent, Werkzeug, MCP und A2A werden gern in einen Topf geworfen. Technisch sind es vier verschiedene Dinge – mit vier verschiedenen Grenzen.
KI-Inhalte verändern sich schnell. Nächster planmäßiger Audit: 31.08.2026.
Ein Agent wählt Handlungen. MCP verbindet Anwendungen mit Daten und Werkzeugen. A2A verbindet Agenten untereinander. Keiner dieser Bausteine entscheidet von allein, was vertrauenswürdig, erlaubt oder verantwortbar ist.
Standards sparen Integrationsarbeit und können Grenzen sauberer beschreiben. Sie ersetzen weder Identität noch Berechtigungen, Freigaben, Überwachung oder fachliche Verantwortung. Eine kompatible Verbindung kann genauso zuverlässig den falschen Schritt ausführen.
Was ein Agent wirklich ist
Ein brauchbarer Agent hat ein Ziel, einen aktuellen Zustand, eine Auswahl erlaubter Handlungen, eine Rückmeldung über Ergebnisse und ein Ende. Er kann planen, muss es aber nicht. Er kann ein Gedächtnis haben, braucht aber nicht automatisch ein langfristiges Profil über dich. Entscheidend ist die Schleife: beobachten, auswählen, handeln, prüfen – bis Erfolg, Übergabe oder Abbruch.
MCP verbindet – und zieht eine neue Grenze
MCP beschreibt eine Host-Client-Server-Architektur für den Austausch von Kontext. Server können Ressourcen, Werkzeuge und Prompts anbieten. Der Standard sagt, wie diese Dinge beschrieben und aufgerufen werden. Er sagt nicht, dass ein beliebiger Server vertrauenswürdig ist. Auch die offizielle Architektur stellt klar: MCP regelt den Protokollaustausch, nicht die Art, wie eine Anwendung das Modell oder den gelieferten Kontext verwendet.
Ein lokaler MCP-Server darf den Projektordner lesen. Das heißt nicht, dass er auch das gesamte Laufwerk sehen muss. Der Host sollte nur den freigegebenen Ordner verbinden – und jeden Schreibzugriff separat behandeln.
Ressource, Werkzeug und Prompt sind nicht dasselbe
Eine Ressource liefert Kontext, etwa eine Datei oder ein Schema. Ein Werkzeug kann eine Operation ausführen, etwa einen Termin anlegen. Ein Prompt ist eine wiederverwendbare Vorlage. In der Oberfläche mag alles wie eine Fähigkeit aussehen. Für Sicherheit ist der Unterschied fundamental: Lesen, vorschlagen und handeln brauchen verschiedene Kontrollen.
A2A organisiert Übergaben, nicht Wahrheit
A2A hilft Agenten, Fähigkeiten zu beschreiben, Aufgaben und Fortschritt auszutauschen und über längere Vorgänge zusammenzuarbeiten. Damit wird ein fremder Agent noch nicht zu einem vertrauenswürdigen Kollegen. Identität, Autorisierung, Datenfreigabe, Ergebnisprüfung und Haftung bleiben Aufgaben der beteiligten Systeme und Organisationen.
Prompt Injection kommt auch aus Dokumenten
Ein Agent kann eine Webseite, Mail oder PDF als Arbeitsmaterial lesen. Darin kann Text stehen, der wie eine Anweisung an das Modell wirkt: Ignoriere den Auftrag, sende Daten, benutze dieses Werkzeug. Das ist indirekte Prompt Injection. Die Antwort ist nicht ein noch strengerer Satz im Systemprompt, sondern eine Architektur, die fremde Inhalte als untrusted data behandelt und gefährliche Handlungen technisch begrenzt.
Gedächtnis ist Nutzen und Altlast zugleich
Kurzzeit-Zustand hält den aktuellen Auftrag zusammen. Fachliches Langzeitwissen gehört eher in gepflegte Quellen. Persönliche Präferenzen brauchen Transparenz und Löschbarkeit. Ein Ereignisprotokoll dient Audit und Fehlersuche. Alles pauschal als Memory zu speichern erzeugt Datenschutzprobleme, veraltete Annahmen und einen Angriffsweg für manipulierte Inhalte.
Der Betrieb entscheidet über Reife
Ein Agent ist erst produktionsfähig, wenn Läufe nachvollziehbar sind: Auftrag, Modellversion, Werkzeugaufrufe, Datenquellen, Freigaben, Kosten, Dauer, Abbruch und Ergebnis. Dazu gehören wiederholbare Tests mit echten Grenzfällen. Eine gute Demo zeigt, was klappt. Ein gutes System zeigt zusätzlich, wie es kontrolliert scheitert.
Behauptung & Befund
Ein Standardstecker sagt nichts über Inhalt, Berechtigung oder Vertrauenswürdigkeit des angeschlossenen Systems.
Fehler vervielfältigen sich über Schritte. Der Nutzen hängt von Aufgabe, Kontrolle und Fehlerkosten ab.
Das Protokoll erleichtert Interoperabilität. Vertrauen entsteht erst durch geprüfte Identität, Berechtigungen, Datenregeln und Ergebnisvalidierung.
Lokaler Betrieb verkürzt Datenwege. Ein Server kann trotzdem zu viele Dateien sehen, Daten an externe Dienste senden oder unsichere Abhängigkeiten enthalten.
Beide können dieselben blinden Flecken, Quellen oder falschen Annahmen teilen. Prüfung braucht Kriterien und externe Evidenz, nicht nur eine zweite Modellantwort.
Quellen
- Model Context Protocol specification Autor/Institution: MCPPublisher: MCP
- Introducing the Model Context Protocol Autor/Institution: AnthropicPublisher: Anthropic
- MCP-Spezifikation 2026-07-28 und Änderungen Autor/Institution: Model Context ProtocolPublisher: Model Context Protocol
- Agent2Agent protocol Autor/Institution: Linux FoundationPublisher: Linux Foundation
- Announcing the Agent2Agent Protocol Autor/Institution: GooglePublisher: Google
- A2A wechselt unter neutrale Linux-Foundation-Governance Autor/Institution: Linux FoundationPublisher: Linux Foundation
- Human-in-the-loop für Werkzeugaufrufe Autor/Institution: n8nPublisher: n8n
- Prompt Injection Autor/Institution: OWASPPublisher: OWASP
- Excessive Agency: zu viele Funktionen, Rechte oder Autonomie Autor/Institution: OWASP GenAI Security ProjectPublisher: OWASP GenAI Security Project
- Artificial Intelligence Risk Management Framework: Generative AI Profile Autor/Institution: NISTPublisher: NIST