Sicherheit von A2A- und MCP-Agenten: Identität, Delegation und Audit-Trails

Prompt-Injection erhält den größten Teil der Aufmerksamkeit im Bereich der Sicherheit von LLM-Systemen, und das zu Recht, aber sie ist nicht das einzige Problem, sobald Agenten beginnen, Tools aufzurufen und Arbeit an andere Agenten zu delegieren.

MCP (Model Context Protocol) bietet einem Agenten strukturierten Zugriff auf Dateien, APIs, Datenbanken und Ticketing-Systeme. A2A (Agent-to-Agent) ermöglicht es einem Agenten, Aufgaben, Nachrichten und Artefakte an einen anderen Agenten zu senden, der möglicherweise zu einem anderen Team, Anbieter oder einer anderen Laufzeitumgebung gehört. Diese Protokolle sind nützlich, gerade weil sie Vertrauensgrenzen überschreiten, was bedeutet, dass Identität, Autorisierung, Delegationslimits und Audit-Trails zur ersten Priorität der Architektur werden und nicht nur optionale Hardening-Maßnahmen darstellen.

Dieser Artikel ist der kanonische Leitfaden für die Sicherheit von Agenten-Protokollen im Cluster LLM-Architektur. Er behandelt Bedrohungsmodelle, Identität, Gateways, Register, Delegation und Checklisten für den Produktivbetrieb. Für Eingabevalidierung, Ausgebe-Filterung und Muster zur Prompt-Sicherheit siehe stattdessen Praktische LLM-Sicherheitsmechanismen.

Sicherheitsmechanismen vs. Protokollsicherheit vs. Laufzeitrichtlinien

Diese drei Schichten lösen unterschiedliche Probleme und versagen auf verschiedene Weise, wenn sie vermischt werden.

LLM-Sicherheitsmechanismen (Guardrails) wirken auf Modell-Eingaben und -Ausgaben: Sie blockieren Injektionsmuster, filtern schädliche Inhalte, validieren die JSON-Struktur und erzwingen Regeln für Ton oder Compliance bei generiertem Text. Sie schützen die Konversationsschicht.

Protokollsicherheit wirkt an den Grenzen der Agenten: Wer darf welches MCP-Tool aufrufen, welcher Agent darf an welchen Peer delegieren, welche OAuth-Bereiche (Scopes) sind einer Aufgabe zugeordnet und ob ein nachgelagerter Agent im Namen eines Benutzers handeln darf. Sie schützt die Aktionsschicht.

Laufzeitrichtlinien befinden sich dazwischen: Eine Policy-Engine, die Anfragen gegen Regeln bewertet, unabhängig davon, ob der Auslöser natürliche Sprache oder ein strukturierter Protokollaufruf war. Sie kann menschliche Genehmigung vor der Ausführung eines Tools erfordern, den Ausgang (Egress) zu unbekannten Domänen blockieren oder die Delegation verweigern, wenn der Scope den des auslösenden Benutzers überschreitet.

Meine Meinung ist schlicht: Sicherheitsmechanismen ohne Protokollsicherheit produzieren höfliche Chatbots, die Daten dennoch über Tool-Aufrufe exfiltrieren. Protokollsicherheit ohne Sicherheitsmechanismen produziert gut authentifizierte Agenten, die dennoch bösartigen Anweisungen folgen, die in einem Artefakt eingebettet sind. Sie brauchen beides, plus Laufzeitrichtlinien für risikobehaftete Aktionen.

Bedrohungsmodell für A2A- und MCP-Agentensysteme

Beginnen Sie mit Assets und Gegnern, nicht mit einer Einkaufsliste von Kontrollmaßnahmen.

Schützenswerte Assets: Benutzerdaten in Prompts und Artefakten, Zugangsdaten für MCP-Server, über Tools erreichbare Produktionssysteme, Agenten-Reputation, Abrechnungskonten, die mit der Token-Nutzung verknüpft sind, und die Integrität der Audit-Logs.

Realistische Gegner: Externe Benutzer, die öffentliche Agenten-Endpunkte missbrauchen, kompromittierte MCP-Server, die vergiftete Tool-Ergebnisse zurückgeben, bösartige Agenten, die Fähigkeiten in Agenten-Karten (Agent Cards) falsch darstellen, Insider, die Autorität übermäßig delegieren, und Manipulationen in der Lieferkette (Supply-Chain) bei Tool-Metadaten, die das Modellverhalten manipulieren.

Bösartige oder kompromittierte Tools (MCP)

Ein MCP-Server ist Code plus Daten, die dem Modell ausgesetzt sind. Ein feindlicher Server kann irreführende Tool-Beschreibungen zurückgeben, vom Modell übergebene Argumente exfiltrieren oder Aktionen ausführen, die über das hinausgehen, was der Benutzer beabsichtigt hat, wenn der Host Tool-Aufrufe ohne bereichsspezifische (scoped) Anmeldeinformationen ausführt.

Bösartige oder getäuschte Agenten (A2A)

Ein Agent, der Aufgaben annimmt, kann bösartig, kompromittiert oder einfach überberechtigt sein. Agenten-Karten (Agent Cards) beschreiben Fähigkeiten; sie beweisen die Identität nicht, es sei denn, Sie verifizieren Signaturen, TLS und das Vertrauen in den Aussteller.

Verwirrter Stellvertreter (Confused Deputy)

Agent B verfügt über die Berechtigung, auf eine Finanz-API zuzugreifen. Agent A, mit geringeren Berechtigungen, bittet B darum, „diese Rechnung zusammenzufassen“, während er eine Überweisungsanweisung in einem Artefakt einschmuggelt. B führt dies mit seinen eigenen Anmeldeinformationen aus, es sei denn, der Delegationsscope wird durchgängig durchgesetzt.

Überbreite Berechtigungen und versteckte Delegationsketten

Der Benutzer genehmigt einen Schritt. Der Orchestrierer verkettet stillschweigend drei A2A-Hops und fünf MCP-Aufrufe. Der Benutzer sieht den vollständigen Graphen nie, aber die Organisation ist für das Ergebnis verantwortlich.

Prompt-Injektion über Artefakte und Nachrichten zwischen Agenten

Injektion ist nicht nur ein Problem von Benutzernachrichten. Ein PDF-Artefakt, eine von einem Tool abgerufene Webseite oder eine Nachricht von Agent C kann Anweisungen enthalten, die auf das Modell von Agent D abzielen. Behandeln Sie alle protokollgetragenen Inhalte an der Modellgrenze als nicht vertrauenswürdige Eingaben.

Vergiftete oder irreführende Agenten-Karten

Beschreibungen und Fähigkeitsnamen sind Angriffsfläche für Prompts. Eine Karte, die safe_read_only_analysis (sichere schreibgeschützte Analyse) bewirbt, aber schreibfähige Backends akzeptiert, ist eine Schicht der Social Engineering, keine technische Garantie.

Identitätsmodell für Multi-Agent-Systeme

Protokollsicherheit beginnt mit klaren Identitätstypen und dem, was jeder von ihnen beweisen darf.

Die Agenten-Karte (Agent Card) von A2A bewirbt unterstützte Authentifizierungsschemata (OAuth 2.0, API-Schlüssel, mTLS und ähnliche Muster, die mit OpenAPI-Praktiken übereinstimmen) und Fähigkeiten mit optionalen Sicherheitsanforderungen. Die Karte ist Entdeckungs-Metadaten, kein Vertrauensanker. Clients beschaffen Anmeldeinformationen außerhalb des Bands (out of band) und senden sie in standardmäßigen HTTP-Headern bei jeder Anfrage; Server müssen bei jedem Aufruf validieren und 401 oder 403 zurückgeben, wenn Authentifizierung oder Scope fehlschlagen.

Interne vs. externe Ansichten desselben Agenten

Produktionsagenten veröffentlichen oft eine öffentliche Agenten-Karte mit einer begrenzten Fähigkeitsliste und eine reichhaltigere authentifizierte Karte für interne Aufrufer. Die A2A-Spezifikation erlaubt erweiterte Karten für authentifizierte Clients. Nutzen Sie diese Trennung bewusst: Partner sollten interne Fähigkeiten nicht sehen, und interne Orchestrierer sollten sich nicht allein auf öffentliche Entdeckung für die Autorisierung verlassen.

Authentifizierung und Autorisierung für MCP und A2A

Authentifizierung beantwortet die Frage: Wer ruft an? Autorisierung beantwortet die Frage: Was dürfen sie tun?

MCP-Tool-Zugriff

Definieren Sie für jede MCP-Verbindung:

• welcher Agenten-Host verbinden darf
• welche Tools für diesen Host aktiviert sind
• welcher OS-Benutzer oder welches Dienstkonto Seiteneffekte ausführt
• ob der menschliche Benutzer jeden mutierenden Aufruf genehmigen muss

Bevorzugen Sie Tool-Whitelists (Allowlists) gegenüber „alles verbinden“-MCP-Konfigurationen. Ein Coding-Agent benötigt keine MCP-Server für die Personalabteilung im selben Profil wie ein öffentlicher Support-Bot.

A2A-Agentenzugriff

Definieren Sie für jede Agenten-Peer-Beziehung:

• welche Aufrufer-Agenten-IDs welche Fähigkeiten aufrufen dürfen
• maximale Delegations Tiefe
• welche Artefakttypen die Grenze überschreiten dürfen
• ob der Benutzerkontext als signierte Claims propagiert werden muss

Ordnen Sie OAuth-Bereiche (Scopes) (oder Äquivalente) Fähigkeiten zu, nicht pauschaler Agenten-Administration. Least-Privilege auf der Token-Ebene ist besser als Hoffnung auf der Prompt-Ebene.

Gateway-erzwungene vs. pro-Agent-Richtlinien

Pro-Agent-Richtlinien funktionieren, wenn ein Team den gesamten Graphen besitzt und Releases koordiniert sind. Gateway-erzwungene Richtlinien funktionieren, wenn mehrere Teams, Mandanten oder Anbieter ein Agentennetzwerk teilen und Sie einen Ort benötigen, um Allowlists, Rate-Limits und Audits durchzusetzen.

A2A-Gateway als Steuerungsebene

Ein A2A-Gateway ist durch das Protokoll nicht strikt erforderlich, wird jedoch notwendig, wenn Agentenverkehr zentraler Governance bedarf.

Ein Gateway übernimmt typischerweise:

• Authentifizierungs-Terminierung und Token-Austausch
• Routing zum richtigen Agentendienst nach Fähigkeit oder Mandant
• Richtlinienprüfungen, bevor Aufgaben akzeptiert oder weitergeleitet werden
• Aushandlung der Protokollversion
• Rate-Limiting und Missbrauchserkennung
• Strukturierte Audit-Emission bei jeder Übergabe der Aufgabe

Wann ein Gateway übertrieben ist vs. notwendig

Ein Gateway ist oft übertrieben für einen einzelnen Orchestrierer und zwei Spezialisten-Agenten in einem Kubernetes-Namespace, der von einem Team verwartet wird. Es wird notwendig, wenn Partner Ihre Agenten aufrufen, wenn mehrere Geschäftsbereiche Infrastruktur teilen, wenn Compliance einheitliches Logging erfordert oder wenn Sie nicht jedem Agenten-Implementierung vertrauen können, Richtlinien korrekt durchzusetzen.

Kombinieren Sie ein A2A-Gateway mit einem MCP-Gateway (oder MCP-Proxy), damit Tool-Zugriff dieselbe Behandlung erhält: Identität, Allowlists, Egress-Kontrollen und Audit an der Tool-Grenze und nicht nur an der Chat-UI.

Partnerorientierte vs. interne Agenten-Karten

Veröffentlichen Sie unterschiedliche Entdeckungs-Metadaten für externe und interne Aufrufer. Externe Karten exponieren schmale Fähigkeiten und strengere Authentifizierung. Interne Karten können Wartungs- oder Admin-Fähigkeiten auflisten, dürfen aber niemals ohne stärkere Authentifizierung erreichbar sein, als die öffentliche Karte impliziert.

Agenten-Register und Entdeckungssicherheit

Entdeckung ist Teil der Angriffsfläche. Jeder, der kontrolliert, welche Agenten „verfügbar“ erscheinen, kontrolliert, wohin Orchestrierer Arbeit senden.

Register vs. bekannte Agenten-Karten-URLs

Kleine Bereitstellungen nutzen bekannte URLs pro Agent (/.well-known/agent-card.json). Enterprise-Bereitstellungen fügen ein Register hinzu, das Agenten-IDs, Versionen, Endpunkte, Eigentümer und Policy-Tags indiziert. Das Register ist ein Policy-Objekt: Einträge sollten protokollieren, welche Mandanten welche Agenten entdecken dürfen, nicht nur, wo sie leben.

Versionierung, Deprecation und Eigentum

Register-Einträge benötigen Eigentümer, Änderungshistorie und Deprecations-Daten. Ein Orchestrierer, der Agenten-Karten cacht, muss diese bei TTL-Ablauf aktualisieren und Signaturen verifizieren, wo unterstützt. Veraltete Karten sind der Grund, warum abgelehnte Fähigkeiten lange nach einer Sicherheitslücken-Patchung weiterhin Traffic erhalten.

Enterprise-interne Netzwerke vs. externe Partner

Interne Agenten-Meshes können sich auf mTLS und privates DNS verlassen. Partner-Agenten benötigen explizite Föderationsregeln, vertraglich umschriebene Fähigkeiten und stärkere Artefakt-Inspektion, da Sie ihre Laufzeitumgebung nicht kontrollieren.

Delegation über Agentengrenzen hinweg

Delegation ist der Punkt, an dem A2A-Sicherheit gewonnen oder verloren geht. Wenn Agent A eine Aufgabe an Agent B sendet, müssen drei Fragen klare Antworten haben:

1. Wessen Autorität wird ausgeübt? Die des Benutzers, die des Dienstkontos von A oder ein kombiniertes delegiertes Token?
2. Was darf B mit dieser Autorität tun? Nur-lesende Analyse oder mutierende Tools im Namen von A?
3. Wer ist verantwortlich, wenn B den Scope überschreitet? A, B, die Gateway-Richtlinie oder der Mensch, der einen unklaren Prompt genehmigt hat?

Propagierung der Benutzerabsicht vs. Überdelegation

Übertragen Sie signierte Delegations-Claims, die Benutzer-ID, ursprüngliche Aufgaben-ID, erlaubte Fähigkeiten, Ablaufdatum und maximale Hop-Anzahl enthalten. Nachgelagerte Agenten müssen Aufgaben ablehnen, die den Scope stillschweigend erweitern. Wenn B höhere Privilegien benötigt, als A besaß, wechseln Sie zu input_required und holen Sie explizite menschliche Genehmigung ein, anstatt Tokens unsichtbar zu aktualisieren.

Human-in-the-Loop-Genehmigungsflüsse für risikobehaftete Delegationen werden in A2A-Streaming und Async-Tasks für langlaufende Agenten-Workflows behandelt, wo input_required ein erstklassiger Aufgabenstatus ist und kein Fehler.

Trennung von Reasoning und Ausführungsberechtigungen

Ein Agent kann breiten Lese-Zugriff benötigen, um zu planen, während Schreib-Tools hinter Genehmigung liegen. Trennen Sie Anmeldeinformationen oder nutzen Sie unterschiedliche MCP-Profile für Planung vs. Ausführung, damit ein Modellfehler die Produktion nicht sofort mutieren kann.

Audit-Trails und Nachweis der Antwortherkunft

Wenn Sie eine Delegationskette nicht rekonstruieren können, können Sie ein Incident nicht erklären, ein Audit nicht bestehen oder eine Abrechnungsanomalie nicht streitig machen.

Loggen Sie auf drei Ebenen:

Gateway: Authentifizierungsergebnis, Policy-Entscheidung, geroutete Agenten-ID, Aufgaben-ID, Eltern-Aufgaben-ID, Rate-Limit-Ereignisse.

Agent: Aufgabenstatusübergänge, gesendete/empfangene Nachrichten, Modell-/Tool-Inokationen (Argumente bei Bedarf redacted), erstellte Artefakte, nach außen delegierte Aufgaben.

MCP-Server: Tool-Name, aufrufende Agenten-ID, Benutzerkontext, Erfolg/Misserfolg, Latenz, betroffene Zeilen oder Ressourcen-IDs (sofern von der Policy erlaubt).

Korrelatieren Sie mit Trace-ID über alle Ebenen hinweg. Beobachtbarkeit für LLM-Systeme behandelt Instrumentierungs-Backends; dieser Artikel definiert, was erfasst werden muss, damit diese Backends sinnvolle Signale haben.

Die Herkunft der finalen Antwort sollte beantworten: Welcher Benutzer, welche Orchestrierer-Aufgabe, welche Spezialisten-Agenten, welche Tools, welche Artefakte haben den Text beeinflusst, den der Benutzer gesehen hat, und welche Policy-Gates wurden dabei ausgelöst.

Laufzeitrichtlinie, Egress und Secrets

Laufzeit-Policy-Engines (OPA, Cedar, benutzerdefinierte Regel-Dienste) bewerten strukturierte Ereignisse: „Tool X mit Args Y für Benutzer Z.“ Sie ergänzen Sicherheitsmechanismen, da sie nicht davon abhängen, dass sich das Modell gut verhält.

Menschliche Genehmigung gehört in die Laufzeitrichtlinie für irreversible oder kostspielige Aktionen: Zahlungen, externe E-Mails, Produktionskonfigurationsänderungen, Privilegvergaben.

Egress-Kontrollen begrenzen, welche Domänen MCP-Server und Agenten aufrufen dürfen. Ein Agent, der sowohl Secrets lesen als auch an beliebige URLs POSTen kann, ist ein Datenverlust, der nur darauf wartet.

Secrets gehören niemals in Agenten-Karten oder Prompts. MCP-Hosts sollten kurzlebige Anmeldeinformationen zur Ausführungszeit aus einem Secrets-Manager injizieren. Für Transportverschlüsselung, Schlüsselverwaltung und Basis-Infrastruktur-Sicherheitsmuster siehe Architekturmuster zur Datensicherung.

Push-Benachrichtigungs-Webhooks in asynchronen A2A-Flows benötigen dieselbe Sorgfalt: Verifizieren Sie die Senderidentität, lehnen Sie veraltete Ereignisse ab und behandeln Sie eine Webhook-Payload niemals allein als Autorisierung.

Referenzarchitektur zur Sicherheit

Das folgende Diagramm fasst ein produktionsorientiertes Layout für A2A außen, MCP innen-Bereitstellungen im großen Maßstab zusammen.

Der Orchestrierer sieht Spezialisten-Agenten über A2A. Spezialisten sehen Tools über MCP. Benutzer erhalten niemals rohe MCP-Anmeldeinformationen, und Partner erhalten niemals interne Fähigkeitsoberflächen ohne Policy-Review.

Für Protokollkonzepte (Agenten-Karten, Aufgaben, Artefakte) siehe Was ist das A2A-Protokoll?. Für Adoption und Enterprise-Einordnung siehe Google A2A-Protokoll im Jahr 2026. Für Topologie, wenn viele Agenten koordinieren, siehe Multi-Agent-Orchestrierungsmuster.

Produktions-Checkliste für A2A- und MCP-Sicherheit

Bevor Sie Agenten-Protokolle über ein vertrauenswürdigen Sandbox hinaus exponieren, verifizieren Sie:

Identität und Authentifizierung

• Keine anonymen Agenten in Produktionspfaden
• Jeder MCP- und A2A-Aufruf bei jeder Anfrage authentifiziert
• OAuth-Bereiche oder Äquivalente auf Fähigkeiten/Tools, nicht pauschale Administration, abgebildet
• Öffentliche vs. authentifizierte Agenten-Karten-Ansichten bewusst definiert

Delegation und Richtlinien

• Delegations-Token tragen Benutzer-ID, Aufgaben-ID, Scope, Ablauf, Hop-Limit
• Nachgelagerte Agenten lehnen Scope-Erweiterung ohne explizite Genehmigung ab
• Hochrisiko-Tools erfordern Laufzeitrichtlinie oder menschliche Genehmigung
• Reasoning und Ausführung nutzen, wo möglich, separate Anmeldeinformationen

Entdeckung und Register

• Agenten-Register-Einträge haben Eigentümer und Versionshistorie
• Agenten-Karten bei TTL-Ablauf aktualisiert; Signaturen verifiziert, wo unterstützt
• Partner-Agenten mit expliziten Skill-Allowlists föderiert

Audit und Beobachtbarkeit

• Gateway-, Agenten- und MCP-Ebenen emittieren korrelierte Audit-Ereignisse
• Delegationsketten mit Eltern- und Kind-Aufgaben-IDs protokolliert
• Artefakt-Herkunft für finale Antworten aufgezeichnet
• Trace-IDs verbinden sich mit Beobachtbarkeits-Backends

Missbrauch und Resilienz

• Rate-Limits pro Benutzer, Agent und Mandant
• Timeout-Richtlinien für delegierte Aufgaben
• Egress-Allowlists auf Tool-Servern
• Secrets in einem Manager, nicht in Karten, Prompts oder Repos

Fazit

Die Interoperabilität von A2A und MCP ist mächtig, weil Agenten und Tools über Team- und Anbietergrenzen hinweg zusammengesetzt werden können, aber diese Macht ist unsicher ohne Identität, Autorisierung, Delegationslimits und Audit-Design. Sicherheitsmechanismen schützen die Modellkonversation; Protokollsicherheit schützt die Aktionen, die Agenten im Namen von Benutzern ausführen.

Behandeln Sie Agenten-Karten als Anzeigen, Delegation als einen signierten Vertrag, MCP-Tools als privilegierte Codeausführung und Audit-Logs als die Beweiskette, die Sie benötigen, wenn um 2 Uhr nachts etwas Interessantes passiert.

Bauen Sie das Gateway, wenn Governance einen einzigen Chokepoint benötigt. Trennen Sie Anmeldeinformationen, bevor Sie Agenten trennen. Protokollieren Sie jeden Hop, damit die Antwort „das Modell hat entschieden“ nie der finale Incident-Bericht ist.

Häufig gestellte Fragen

Was ist der Unterschied zwischen LLM-Sicherheitsmechanismen und A2A-MCP-Agentensicherheit? Sicherheitsmechanismen begrenzen Modell-Eingaben und -Ausgaben. Protokollsicherheit begrenzt, wer Tools aufrufen, Aufgaben delegieren und im Namen wessen handeln darf, über MCP und A2A hinweg mit Identität, Autorisierung und Audit-Trails.

Wie sollte Agenten-Identität in einer A2A-Bereitstellung funktionieren? Trennen Sie menschliche, Agenten-Dienst- und Aufgaben-Identitäten. Validieren Sie Anmeldeinformationen bei jeder Anfrage, nutzen Sie bereichsspezifische Tokens und behandeln Sie Agenten-Karten als Entdeckungs-Metadaten, nicht als Vertrauensbeweis.

Was ist das Problem des verwirrten Stellvertreters in Multi-Agent-Systemen? Es tritt auf, wenn ein privilegierter Agent oder Tool eine sensible Aktion ausführt, weil ein weniger privilegierter Aufrufer Anweisungen über Delegation oder Artefakte eingeschmuggelt hat. Erzwingen Sie den Scope bei jedem Hop.

Brauchen Sie ein A2A-Gateway in der Produktion? Single-Team-interne Bereitstellungen können Richtlinien pro Agent durchsetzen. Multi-Tenant-, Multi-Anbieter- oder Partner-orientierte Netzwerke benötigen normalerweise ein Gateway für zentrale Authentifizierung, Routing, Rate-Limits und Audit.

Was sollte ein A2A-MCP-Audit-Log enthalten? Benutzer-ID, Agenten-ID, Aufgaben-ID, Eltern-Aufgaben-ID, Tool-Aufrufe, Policy-Entscheidungen, Artefakte und Zeitstempel, korreliert mit Trace-IDs über Gateway-, Agenten- und MCP-Ebenen hinweg.

Quellen

• A2A-Protokoll – Enterprise-fähige Sicherheitsthemen: https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• A2A-Protokoll – Spezifikationsübersicht: https://a2a-protocol.org/latest/specification/
• A2A-Protokoll – Streaming- und Push-Benachrichtigungssicherheit: https://a2a-protocol.org/latest/topics/streaming-and-async/