MCP, A2A und ACP in der Praxis: Wie eine Bank Tools und Agenten miteinander verbindet.

In den letzten Jahren folgten mehrere Model-Releases einem bestimmten Muster. Zunächst trat ein größeres Modell auf, das besseren Code schrieb, klarer argumentierte und längere Kontexte bewältigen konnte. Innerhalb weniger Wochen legte sich die Begeisterung jedoch, denn ein kluges Modell allein in einem Chatfenster kann immer noch nicht den Kontostand eines Kunden abrufen, einen verdächtigen Transaktionsvorgang blockieren oder die Kreditgeschichte eines Antragstellers einsehen. Intelligenz war nie das eigentliche Engpassproblem – die Verbindung schon.

Die ingenieurtechnischen Bemühungen haben sich vom reinen Modellumfang hin zur Protokollentwicklung verlagert. Drei Spezifikationen befassen sich mit dem Verbindungsproblem: MCP (Model Context Protocol), A2A (Agent-to-Agent) und ACP (Agent Communication Protocol). Gemeinsam legen sie fest, wie ein Modell auf Tools zugreift, wie ein Agent auf einen anderen zugreift und wie viele Agenten gemeinsam arbeiten können, ohne in Chaos zu geraten.

Ein Beispiel veranschaulicht alles Weitere: Eine Bank entwickelt einen KI-Assistenten, der Betrug erkennen, Kreditanträge bewerten und mit den Kernbankensystemen kommunizieren muss, gleichzeitig aber ausreichend überprüfbar sein muss, um einen Aufsichtsbehörde zufriedenzustellen.

Warum ein reines Modell Protokolle benötigt

Ohne weitere Eingriffe kann ein Sprachmodell nur Text vorhersagen. Wenn man es fragt, ob auf dem Konto eines Kunden in diesem Monat verdächtige Aktivitäten zu verzeichnen sind, lehnt es ab oder gibt eine flüssige, aber falsche Antwort – schließlich liegt das tatsächliche Transaktionsprotokoll außerhalb seines Sichtfelds.

Frühe Lösungen schlossen die Modelle direkt an REST-APIs an, einen Anschluss nach dem anderen. Ein Betrugsassistent erhielt speziellen Code für die Kernbank-API, noch mehr für das CRM und noch mehr für das Fallmanagement. Kleine Implementierungen kamen zurecht. Größere stießen auf drei Probleme:

• Nichts war wiederverwendbar. Der Core-Banking-Connector des Betrugsbekämpfungsteams war für das Kreditteam nutzlos, obwohl beide identische Transaktionsdaten benötigten, wodurch jedes Projekt von Grund auf beginnen musste.
• Der Zustand verschwand zwischen den Anfragen. APIs sind per Design zustandslos. Ein Analyst, der die Transaktionen eines Kunden abgerufen hatte und anschließend nach ungewöhnlichen Elementen in „diesen Daten“ suchte, stellte fest, dass eine einfache API-Integration keinen Zusammenhang zwischen den beiden Anfragen herstellte, es sei denn, die Entwickler erstellten manuell eine Speicherschicht.
• Rechte wurden nachträglich hinzugefügt. Jede Bankvorgangsart erfordert eine Berechtigungsprüfung sowie eine Aufzeichnung für Prüfer. Ein junger Betrugsanalyst kann die Transaktionshistorie einsehen, darf aber keine Überweisungen rückgängig machen. Die ad hoc Anbindung jeder API machte es einfach, solche feinen Regeln falsch anzuwenden, und erschwerte es, dies einem Prüfer nachzuweisen.

Ein Protokoll regelt den Vertrag einmalig. Keine Bank muss eigene Methoden entwickeln, damit ein Modell den Betrugsdetektor aufrufen kann, denn MCP stellt eine einzige Schnittstelle bereit. Kein Team muss eigene Wege finden, um einen Fall von einem Betrugsbeauftragten an einen Compliance-Beauftragten weiterzuleiten, denn A2A bietet eine solche Lösung. HTTP hat dies für vernetzte Anwendungen und SQL für Datenbanken getan: eine gemeinsame Sprache, die es unabhängig entwickelten Systemen ermöglicht, zusammenzuarbeiten.

Fünf Entwurfsphasen

Der Systementwurf hat in der Bankenbranche und anderswo fünf Phasen durchlaufen.

1. Ein einfaches LLM. Das Modell antwortet ausschließlich auf Grundlage von Schulungsdaten. Es kann erklären, was KYC ist, kann aber nicht feststellen, ob das Profil eines bestimmten Kunden den KYC-Vorgaben der Bank entspricht, da es niemals die Unterlagen dieses Kunden sieht.
2. Retrieval-augmented Generation. Das Modell verbindet sich mit einem Dokumentenspeicher wie dem Compliance-Handbuch sowie früheren regulatorischen Leitlinien, sodass die Antworten auf aktuellen, internen, organisationsbezogenen Inhalten beruhen und nicht auf allgemeinem Schulungswissen.
3. Agenten. Das Modell kann nicht nur Informationen abrufen, sondern auch handeln. Ein Compliance-Assistent kann nun die KYC-Richtlinien zitieren und gleichzeitig die im System gespeicherten Dokumente eines Kunden darauf überprüfen, um Abweichungen zu erkennen.
4. Mehr-Agenten-Systeme. Ein Agent, der gleichzeitig Betrugserkennung, Kreditprüfung und Kundenkommunikation übernimmt, wird unzuverlässig und schwer zu steuern. Die Aufgaben werden auf Spezialisten aufgeteilt, wie einen Betrugsagenten, einen Kreditagenten und einen Kundenkommunikationsagenten, wobei jeder in einem spezifischen Bereich Experte ist.
5. Protokolle. Wenn es viele Agenten und Systeme gibt, ist eine Standardmethode erforderlich, damit sie einander finden, Kontext teilen und sicher kommunizieren können. MCP, A2A und ACP erfüllen diesen Bedarf.

Die meisten Banken befinden sich heute zwischen der dritten und vierten Stufe. Es gibt einzelne Agenten, oft einen pro Anwendungsfall, doch ohne ein gemeinsames Protokoll zwischen ihnen erfordert jeder neue Agent weiterhin individuelle Integrationen. Genau dazu dienen die Protokolle, diese Lücke zu schließen.

Toolaufrufe – die Schicht unter MCP

Vor MCP gab es Toolaufrufe, auch Funktionsaufrufe genannt. Sie ermöglichen es einem Modell, eine externe Aktion anzufordern anstelle nur Text zu erzeugen, und MCP basiert darauf.

Die Mechanik ist einfach. Für jedes verfügbare Tool schreibt ein Entwickler ein JSON Schema, das einen Namen, eine Beschreibung sowie typisierte Parameter enthält, und sendet es zusammen mit dem Prompt an das Modell. Wenn das Modell feststellt, dass ein Tool benötigt wird, führt es nichts aus. Sein Ausgabeobjekt ist ein strukturiertes JSON-Objekt, das den Namen des Tools angibt und Argumente liefert, wobei die umgebende Anwendung die Funktion ausführt und das Ergebnis an das Modell zurückgibt. Ein Bankingschema sieht so aus:

{
  "name": "get_customer_transactions",
  "description": "Returns transactions for a customer above a given amount, within a date range",
  "parameters": {
    "type": "object",
    "properties": {
      "customer_id": {"type": "string"},
      "min_amount": {"type": "number"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"}
    },
    "required": ["customer_id", "start_date", "end_date"]
  }
}

Falls ein Betrugsanalyst um die Ansicht der kürzlichen, großen Transaktionen eines Kunden bittet – Transaktionen im Wert von über fünftausend Dollar im vergangenen Monat – wird zur Beantwortung nicht auf das Gedächtnis zurückgegriffen. Stattdessen gibt das Modell einen Aufruf an get_customer_transactions ab, wobei der Kunden-ID, der Betragsschwelle sowie des Zeitraums angegeben werden. Die Anwendung fragt anschließend die Kernbankdatenbank ab, übermittelt die tatsächlichen Datensätze zurück und das Modell wandelt sie in eine verständliche Zusammenfassung um.

Einfache Tools, die einzelne Modelle mit wenigen fest programmierten Funktionen verarbeiten, funktionieren gut. Probleme entstehen, wenn Dutzende von Tools über Kernbank-, Betrugs-, CRM- und Dokumentensysteme verteilt sind, wobei zusätzliche Tools ohne Neuverteilung bei jedem Kunden hinzugefügt werden müssen, oder wenn ein Tool von den Betrugs- und Kreditassistenten sicher geteilt werden muss. MCP zielt genau auf diese Probleme ab.

MCP im Detail

MCP kam Ende 2024 von Anthropic als offener Standard für die Verbindung von KI-Anwendungen mit externen Systemen. Man kann sich darunter einen universellen Adapter vorstellen. Früher erforderte die Verbindung eines Bank-Assistenten mit dem Kernbankensystem, dem Betrugsprüfsystem und dem CRM drei inkompatible Integrationen. Jetzt kann jeder MCP-kompatible Client mit jedem MCP-kompatiblen Server kommunizieren – genauso wie jedes USB-Gerät in jeden USB-Port passt.

Die Arithmetik von M mal N

Das zugrundeliegende Problem ist kombinatorischer Natur. Die Verbindung von M Tools mit N Anwendungen erzeugt eine Matrix, die mit zunehmender Größe beider Zahlen unübersichtlich wird. Eine Bank mit fünf internen Systemen und vier Assistenten (Betrugsprävention, Kredite, Kundenservice, Compliance) bräuchte bis zu zwanzig individuelle Verbindungsstücke. Ein Standardprotokoll reduziert dies auf fünf plus vier, da jedes System und jeder Assistent MCP nur einmal implementiert.

Drei Rollen

• Host: die KI-Anwendung, die der Benutzer tatsächlich sieht, beispielsweise die Benutzeroberfläche eines Betrugsanalysten-Assistenten.
• Client: eine Komponente innerhalb des Hosts, die eine Verbindung zu einem MCP-Server verwalten und die Kommunikation auf Protokollebene abwickeln.
• Server: die Seite, die Funktionen bereitstellt, also Daten oder Aktionen. Eine Bank könnte einen Server vor der Kernbanking-Plattform, einen weiteren vor dem Betrugspräventions-System und einen dritten vor dem Dokumentenarchiv betreiben, wobei jeder von dem Team gewartet wird, das das dahinterliegende System betreut.

Drei Primitive, die ein Server anbieten kann

• Ressourcen enthalten nur zum Lesen zugängliche Daten, die das Modell in den Kontext einbeziehen kann, beispielsweise einen Kontoauszug oder den Status von KYC-Dokumenten. Ähnlich wie eine GET-Anfrage liefern sie Informationen, ändern aber nichts.

Tools führen Aktionen aus, wie zum Beispiel das Einfrieren eines Teils eines Kontos oder das Versenden eines Falls an einen Compliance-Beauftragten. Ähnlich wie eine POST-Anfrage ändern sie den Zustand, wodurch sie zu den Elementen werden, die in einer Bank am dringendsten menschliche Genehmigungen benötigen.

Prompts sind wiederverwendbare, parametrisierte Vorlagen, die das Modell dazu anleiten, eine ordnungsgemäße Anfrage zu erstellen. Ein Beispiel ist ein standardmäßiger Prompt zur Eskalation von Betrugsfällen, den jeder Analyseassistent auf dieselbe Weise verwendet, sodass kein Team seine eigene, leicht abweichende Version pflegen muss.

Stichprobenziehung, Erkundung und Übertragung

Durch Stichprobenziehung kann ein Server vom LLM des Hosts eine Ergänzung anfordern und dabei das Denkvermögen des Modells für eine Unteraufgabe nutzen. Ein Dokumentenspeicherserver könnte dies nutzen, um vom Modell eine Zusammenfassung eines langen Kreditvertrags zu erhalten, bevor dieser zurückgegeben wird, wobei ein menschlicher Analytiker diese Zusammenfassung noch einmal prüft, bevor er handelt.

Die Entdeckung erfolgt, wenn ein Client sich verbindet und einen Server fragt, welche Ressourcen, Tools und Anweisungen dieser anbietet, wodurch MCP dynamisch bleibt. Sobald das Betrugsbekämpfungsteam ein neues Tool zur Überprüfung der Gerätehistorie eines Kunden veröffentlicht, kann jedes verbundene Assistenten dieses sofort nutzen, ohne dass der Client-Code geändert werden muss.

Das Übertragungsformat ist JSON-RPC 2.0, über einen von zwei gängigen Transportmechanismen. Stdio eignet sich für einen Server, der auf dem eigenen Rechner des Clients läuft. HTTP mit Server-Sent Events oder streambares HTTP eignet sich für einen entfernten Server. Auf einen Kernbankserver im Rechenzentrum hinter einer Firewall würde man über entferntes HTTP mit angemessener Authentifizierung zugreifen, nicht über Stdio.

Sicherheit

In regulierten Branchen verdient MCP seinen Lebensunterhalt, obwohl es keine Kontrollmechanismen automatisch bereitstellt. Es bietet Ingenieuren einen einheitlichen Ort, an dem diese Mechanismen entwickelt und umgesetzt werden können, anstatt die Sicherheit bei jeder Integration neu zu erfinden. Eine Produktionsumgebung für Bankdienste sollte Folgendes beinhalten:

• OAuth 2.1 erfordern, wenn Clients sich bei Servern authentifizieren;
• jedem Tool nur die notwendigen Berechtigungen gewähren, sodass das Token eines Junior-Analysten nicht auf Funktionen wie approve_wire_transfer zugreifen kann;
• für jeden Aufruf eines Tools ein Protokoll-Eintrag anfertigen;
• eine ausdrückliche menschliche Bestätigung vor jedem aufrüstbaren Vorgang verlangen, beispielsweise beim Einfrieren eines Kontos oder Aufheben einer Sperrung.

Wie eine MCP-Implementierung aussieht

Eine typische Bankumgebung setzt sich aus drei Schichten zusammen. Der Host ist die Chat-Oberfläche oder die Agenten-Plattform, die der Benutzer sieht, beispielsweise ein Ermittlungsassistent. Ein MCP-Client innerhalb des Hosts öffnet Sitzungen mit Servern, sendet Entdeckungsanfragen und leitet Toolaufrufe hin und her. Jeder Server vertritt ein einzelnes Datensystem – beispielsweise das Kernbankwesen, den Betrugsdetektor oder den Dokumentenspeicher – und wird von dem jeweiligen Team gewartet und geschützt.

Eine Betrugsuntersuchung zeigt den Anfragenweg auf:

1. Ein Analyst möchte alle Transaktionen eines Kunden im Wert von über zehntausend Dollar in den letzten dreißig Tagen sowie eine Überprüfung, ob sich die Gerätefingerprint kürzlich geändert hat.
2. Die LLM des Hosts ermittelt, dass zwei Toolaufrufe erforderlich sind, und weist den Client an, auf dem Server des Kernbankwesens get_transactions und auf dem Server des Betrugsdetektors get_device_history auszuführen.

Der Client sendet JSON-RPC-Anfragen über HTTPS an beide Server.

Jeder Server überprüft den OAuth-Bereich des Analysten sowie dessen Recht, die Daten dieses Kunden anzusehen, fragt sein eigenes Backend-System ab und gibt eine Antwort zurück.

Der Client übermittelt beide Antworten an das Modell, das sie zu einem zusammenfassenden Bericht verbindet.

Alles – sowohl die Anfragen und Antworten als auch die Identität des Analysten – wird im Audit-Log festgehalten.

Ein minimaler Python-Server, der das offizielle SDK-Muster verwendet, zeigt, wie wenig Code ein solches Tool benötigt:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("core-banking-server")
@mcp.tool()
def get_transactions(customer_id: str, min_amount: float, days: int) -> list:
    """Fetch transactions above a threshold for a customer, scoped to the caller's authorization."""
    # In production this calls the real core banking API,
    # scoped and logged, never queried directly by the model.
    return query_core_banking(customer_id, min_amount, days)
@mcp.tool()
def place_transaction_hold(transaction_id: str, reason: str) -> dict:
    """Places a temporary hold on a transaction pending review. Requires human confirmation before execution."""
    return execute_hold(transaction_id, reason)
if __name__ == "__main__":
    mcp.run(transport="stdio")

Die beiden darin enthaltenen Tools erfordern in der Praxis unterschiedliche Handhabung. get_transactions ist ein lesender, ressourcenähnlicher Mechanismus, der ohne BestätigungsSchritt ausgeführt werden kann. place_transaction_hold ändert hingegen den Zustand in einem echten Finanzsystem, weshalb er niemals einfach deshalb ausgelöst werden darf, weil das Modell es verlangt. Die AnwendungsSchicht sollte ihn zunächst durch explizite Bestätigung eines Analysten leiten lassen.

Einige Gewohnheiten halten Produktionsserver gesund:

• Geben Sie jedem Server ein einziges System zur Verarbeitung, nicht einen Monolithen, der Kernbankwesen, Betrugserkennung und CRM umfasst.
• Schreiben Sie Toolbeschreibungen so, wie es für die Dokumentation eines neuen Analysten üblich wäre, denn das Modell entscheidet ausschließlich anhand dieses Textes, wann ein Tool angewendet werden soll.
• Versionieren Sie die Tool-Schemata. Eine Änderung eines erforderlichen Parameters in get_transactions ohne Vorankündigung stört alle darauf angewiesenen Assistenten, einschließlich solcher außerhalb des Betrugserkennungsteams.

Gehen Sie davon aus, dass jeder Tool-Aufruf als unzuverlässiger Eingang für das nachgeschaltete System gilt, und überprüfen Sie ihn, da ein manipulierter Modellausgang sonst einen nicht autorisierten Aufruf versuchen könnte.

A2A – Agenten, die mit anderen Agenten kommunizieren

MCP kümmert sich um die Verbindungen von Modellen zu Tools. A2A, das Google 2025 eingeführt hat und das nun von der Linux Foundation betreut wird, handelt eine andere Verbindung ab: einen autonomen Agenten, der einen anderen aufruft, insbesondere dann, wenn verschiedene Teams oder Anbieter sie entwickelt haben.

Ein einziger Agent reicht nicht aus, denn ein einzelner Agent, der Betrug, Underwriting und Kommunikation bewältigt, entwickelt sich zu einem umfangreichen System, das schwer zu steuern ist, und es wird sehr schwierig, einem Prüfer nachzuweisen, welche Logik welche Entscheidungen getroffen hat. Spezialisten, die Aufgaben untereinander delegieren, arbeiten effizienter und sicherer.

Delegation basiert auf der Agentenkarte, einer maschinenlesbaren Angabe darüber, was ein Agent tun kann. Sie ähnelt der Tool-Liste eines MCP-Servers, beschreibt jedoch die Fähigkeiten eines gesamten Agents und nicht einzelne Funktionen. Ein koordinierender Customer Assistant Agent liest die Karte des Betrugsagenten und erfährt so, dass dieser umstrittene Transaktionen überprüfen kann, liest die Karte des Kreditagenten und erfährt, dass dieser die Eignung für eine Umschuldung beurteilen kann, und wählt anschließend den richtigen Delegierten für die Anfrage des Kunden aus.

Koordination beschreibt, wie die Agenten Aufgaben weitergeben, vorläufige Ergebnisse übertragen und über einen standardmäßigen Transportweg Erfolge oder Misserfolge melden. Jede Seite betrachtet die andere als Black Box. Der Kundenservice-Agent muss nicht wissen, wie der Betrugspräventions-Agent konstruiert ist, ob er MCP-Tools im Kernbanking aufruft, welches Modell ihn steuert oder wie viele Schritte er durchläuft. Er benötigt lediglich die Fähigkeiten des Agenten sowie eine Möglichkeit, ihm Arbeit zuzusenden.

Zwei Bankbeispiele veranschaulichen dies. Zunächst meldet ein Kunde eine unbekannte Abbuchung in Höhe von fünfhundert Dollar und fragt gleichzeitig nach einem besseren Hypothekenzinssatz. Der Assistent kümmert sich weder selbst um das eine noch um das andere. Er leitet den Streitfall an den Betrugspräventions-Agenten und die Hypothekenfrage an den Kreditagenten weiter, führt beide Prozesse parallel aus und fügt die Antworten anschließend zu einer einzigen Antwort zusammen.

Zweitens prüft der Betrugsagent diese Gebühr, indem er die MCP-Server für das Kernbankwesen sowie den Betrugsdetektor aufruft, um Transaktions- und Geräteaufzeichnungen abzurufen. Wenn sein Vertrauen in eine Betrugsdiagnose gering ist, vermeidet er Vermutungen und leitet den Fall über A2A an einen Compliance-Prüfagenten weiter, der strengere regulatorische Vorgaben anwendet und gegebenenfalls an einen menschlichen Compliance-Beauftragten weiterleitet. Kundenserviceassistent, Betrugsagent, Compliance-Prüfagent, Mensch – das ist die strukturierte Delegation, für die A2A konzipiert ist.

ACP, die Nachrichtenschicht

Während A2A sich auf die Delegation von Aufgaben konzentriert, kümmert sich ACP um die Kommunikation in mehragentigen Gesprächen, insbesondere um den Zustands-, Speicher- und Fehlermanagement bei längeren Interaktionen.

• Architektur. Gespräche werden zu Sequenzen von eingegebenen Nachrichten. Jede Nachricht enthält Inhalte sowie Metadaten zum Absender, zum Thread und zur erwarteten Antwort. Eine Eskalation von Betrugsfällen zur Compliance beinhaltet daher mehr als nur den Fall selbst: strukturierte Felder für Fall-ID, anfragenden Agenten, Dringlichkeit und erwarteten Antworttyp.
• Nachrichtenübermittlung. Die Struktur ersetzt den rohen Text – genauso wie eine E-Mail einen Betreff, einen Absender und einen Textkörper hat und nicht aus einem einzigen Textblock besteht. Wenn Dutzende von Agenten an einem einzigen Kreditworkflow arbeiten, muss jede Nachricht den richtigen Agenten sowie den richtigen Bearbeiter innerhalb dessen erreichen.

Zustand. Eine Prüfung, die über einen Eignungsprüfer, einen Risikoprüfer und einen Genehmigungsprüfer läuft, muss über mehrere Austausche hinweg ihren Zustand beibehalten. ACP legt Konventionen für das Hinzufügen und Aktualisieren gemeinsam genutzten Zustands fest, wie beispielsweise abgeschlossene Überprüfungen und ausstehende Dokumente, damit kein Prüfer die Anwendung aus den Augen verliert, selbst wenn der Prozess mehrere Tage andauert.

Gedächtnis. Das kurzfristige Gesprächsgedächtnis, das mit der aktuellen Anwendung verbunden ist, wird von dem langfristigen Gedächtnis getrennt aufbewahrt, das zwischen Sitzungen übertragen wird – beispielsweise die bekannte Präferenz eines Kunden für einen Festzinskredit, die das Gespräch ohne wiederholte Fragen gestalten sollte.

Fehlerbehandlung. Ein fehlgeschlagener Aufruf eines Agenten in der Bankwirtschaft kann nicht einfach verschwinden. Nehmen wir an, der Risiko-Agent kann aufgrund eines Ausfalls keine Kreditberichte abrufen. ACP definiert strukturierte Fehler, wodurch der koordinierende Eignung-Agent zwischen einem weiteren Versuch, einer Übertragung an einen menschlichen Prüfer oder einer Pause entscheiden kann, und verhindert so, dass eine unvollständige oder fehlerhafte Entscheidung unbemerkt durchgeht.

Vergleich der fünf Ansätze

Wenn man sie nebeneinander stellt, unterscheiden sich die Optionen in einigen Aspekten:

• Was sie miteinander verbinden. Eine einfache API verbindet eine Anwendung mit einer anderen. Tool Calling verbindet ein Modell mit einer Funktion. MCP verbindet ein Modell oder eine Anwendung mit Tools, Daten und Anfragen. A2A verbindet Agenten miteinander. ACP verbindet Agenten auf der Nachrichtenebene miteinander.
• Standardisierung zwischen Anbietern. Einfache APIs nicht. Tool Calling teilweise. MCP, A2A und ACP ja.
• Entdeckung von Funktionalitäten. Keine für einfache APIs und Toolaufrufe. Dynamisch bei MCP, über Agent-Karten bei A2A, eingeschränkt bei ACP.
• Einbau von Zustands- und Speicherkonventionen. Keine für einfache APIs und Toolaufrufe, teilweise bei MCP und A2A, sowie Schwerpunkt bei ACP.
• Bankbeispiel. Das Core-Banking kommuniziert mit einem CRM; ein Assistent ruft eine fest programmierte Saldo-Funktion auf; ein Assistent entdeckt und ruft einheitlich Core-Banking-, Betrugs- und Dokumentenwerkzeuge auf; ein Betrugsagent delegiert an einen Compliance-Review-Agenten; der Zustand einer mehrtägigen Kreditfreigabe wird über drei Agenten hinweg verfolgt.

Diese Optionen ergänzen sich, sind aber keine Konkurrenten. Ein Produktionsbankassistent wird wahrscheinlich MCP nutzen, um Agenten mit den Kernsystemen zu verbinden, A2A für die Delegation unter Spezialisten sowie ACP-Vereinbarungen, um langfristige, mehragentige Workflows wie die Kreditprüfung von Anfang bis Ende zusammenzuführen.

Eine Kundennachricht, von Anfang bis Ende

Nehmen wir eine einzige Nachricht: Der Kunde erkennt eine Gebühr von fünfhundert Dollar nicht und möchte außerdem Informationen zu einem besseren Hypothekenzinssatz erhalten. Der gesamte Systemstack reagiert Schritt für Schritt.

1. Der Kunde sendet die Nachricht an den KI-Assistenten, die Host-Anwendung innerhalb der Bank-App.
2. Über A2A leitet der Assistent die Frage zum Betrug an den Betrugsspezialisten und die Frage zur Hypothek an den Kreditexperten weiter, wobei beide gleichzeitig bearbeitet werden.

Der Betrugsbekämpfungsspezialist ruft über MCP den CRM-Server auf, um den Kontakt- und Beschwerdehistorien zuzugreifen, sowie den Kernbankserver für die umstrittene Transaktion. Nach Anwendung seiner Betrugsregeln ruft er erneut über MCP das place_transaction_hold-Tool des Kernbankservers auf. Dieser Aufruf wird an einen menschlichen Analysten zur Bestätigung weitergeleitet, bevor eine Änderung des Status vorgenommen wird.

Der Kreditberater holt über MCP die aktuellen Hypothekendetails sowie das Kreditprofil aus dem Kernbanksystem, vergleicht sie mit den aktuellen Zinntabellen und erstellt eine Empfehlung. Da ein Neukreditzins nur mit der Freigabe eines Prüfers vergeben werden kann, wird nichts ausgeführt; stattdessen werden die Empfehlung sowie die dazugehörigen Unterlagen in einem für Menschen bestimmten Zusammenfassungsdokument bereitgestellt.

Sowohl die Spezialisten als auch der Berater melden sich über A2A beim Assistenten zurück, wobei sie ACP-ähnliche strukturierte Nachrichten verwenden, die den Fallstatus, ausstehende menschliche Genehmigungen sowie Erkenntnisse enthalten.

Der Assistent verwendet MCP, um dem Kunden eine E-Mail zu senden, in der die Sperrung bestätigt wird, und protokolliert jeden Tool-Aufruf, jede Übertragung sowie jede Entscheidungsgrenze im Prüfsystem – schließlich erwarten die Aufsichtsbehörden genau diese Nachverfolgbarkeit, falls der Fall überprüft wird.

Interoperabilität in einer Bank sieht daher so aus: Es gibt kein einziges riesiges Modell, das versucht, alles zu erledigen, sondern spezialisierte Agenten mit kontrolliertem Tool-Zugang, die jeweils ihre Aufgabe gut erledigen, ergänzt durch eine klare Prüfspur.

Sicherheit über Agenten und Protokolle hinweg

• Prompt-Injektion. Eine bösartige Anweisung, die in einem Dokument, E-Mail oder hochgeladenen Datei versteckt ist, kann versuchen, den nächsten Schritt eines Agents zu übernehmen. Stellen Sie sich einen betrügerischen Streitfall vor, der versteckten Text enthält, der den Betrugsagenten anweist, die Forderung ohne Überprüfung zu genehmigen. MCP-Tools ändern den tatsächlichen Zustand, wodurch die Gefahr real ist. Gegenmaßnahmen: Behandeln Sie alle abgerufenen Inhalte als unzuverlässig, erlauben Sie niemals, dass die Ausgabe des Modells ein hochriskantes Tool wie place_transaction_hold ohne Policy-Prüfung auslöst, und beschränken Sie, welche Tools das Modell in einem bestimmten Kontext sehen kann.
• Authentifizierung. Jeder MCP-Client-Server-Verbindung sowie jede A2A-Übertragung erfordert eine Authentifizierung, in der Regel über OAuth 2.1, sodass ein anonymer Anrufer kein Kernbanking-Tool ausführen oder Aufgaben an den Compliance-Review-Agenten zuweisen kann.

Authorization. Die Authentifizierung bestimmt, wer anruft, während die Autorisierung festlegt, was dieser Anrufer tun darf. Ein authentifizierter Betrugsbekämpfungssystem muss weiterhin auf die Verwendung eines Tools zur Genehmigung von Änderungen der Hypothekenzinsen verzichten, da dies außerhalb seines Aufgabenbereichs liegt – unabhängig davon, wie überzeugend seine Begründung erscheint.

Zero trust. Im Prinzip wird kein Glied in der Kette standardmäßig vertraut, weder das Modell, noch ein anderes System, noch ein nachgelagerter Server. Die Richtlinien werden bei jedem Ausführungsvorgang überprüft, anstatt einfach hingenommen zu werden, nur weil der Vorgang innerhalb des eigenen KI-Systems der Bank startet.

Human approval. Maßnahmen mit finanziellen, sicherheitstechnischen oder regulatorischen Auswirkungen, wie das Einfrieren eines Kontos, das Aufheben einer Sperrung oder die Genehmigung eines Kredits, müssen durch menschliche Bestätigung abgesegnet werden. Dies ist eine auf die Risiken abgestimmte Konstruktionsentscheidung und kein Mangel der Technologie.

Auditrückverfolgung. Protokollieren Sie jeden Aufruf eines Tools, jede Delegation sowie jede Änderung des Zustands ausreichend detailliert, um nachvollziehen zu können, was geschehen ist und warum. Wenn eine Aufsichtsbehörde fragt, warum ein Konto sechs Stunden lang blockiert blieb, muss die Bank in der Lage sein, die genaue Abfolge der Entscheidungen der Mitarbeiter sowie der Tool-Aufrufe nachzuweisen – nicht nur eine Schätzung.

Welche Richtung geht es ein?

Die Reisrichtung ist leicht zu erkennen. Protokolle wie MCP werden zur Schicht der Gerätedriver in der KI – einem Standardweg von jedem Modell zu jedem Tool ohne spezielle Zusatzlösungen. Man kann damit rechnen, dass KI-Betriebssysteme zu einer eigenständigen Kategorie werden, wobei MCP-basierte Server als erstklassige Infrastruktur wie Datenbanken und Nachrichtenwarten fungieren, während ein Kernbankserver etwas ist, in das jedes interne KI-Projekt ohne Neuentwicklung eingebunden werden kann. Es werden vorgeprüfte, auditierte Server-Märkte entstehen, sodass eine Bank einen kompatibilitätsgeprüften KYC-Verifizierungsserver nutzen kann, anstatt selbst einen zu entwickeln. Zudem wird es Tools zur Steuerung geben, die das Auditen von MCP-Aufrufen sowie A2A-Delegationen ermöglichen, da Compliance- und Risikoteams diese Transparenz benötigen, bevor etwas mit echtem Geld zu tun hat. Und man kann erwarten, dass dieselben Muster weit über die Bankenbranche hinaus in alle Bereiche vordringen, in denen ein Reasoning-System eine standardisierte, audierbare Methode zum Handeln in der Welt benötigt.

Die Kurzfassung

Ein Modell allein kann keinen Saldo überprüfen, ein Embargo verhängen oder eine Hypothek bewerten. MCP standardisiert die Art und Weise, wie auf Tools, Daten und Anweisungen zugegriffen wird, wodurch ein Betrugsassistent und ein Kreditassistent denselben Kernbankserver teilen können, ohne doppelte Integrationen. A2A standardisiert die Weise, wie Spezialisten Aufgaben untereinander weitergeben, ohne die internen Abläufe des anderen kennen zu müssen. ACP standardisiert die Kommunikation, den Zustandsverlauf sowie die Fehlerbehandlung in langen Workflows wie der mehrtägigen Kreditfreigabe. In einer Bank sind diese Protokolle keine bloßen Bequemlichkeiten – sie sorgen dafür, dass Autorisierungen, Audit-Spuren sowie menschliche Genehmigungen in großem Umfang durchsetzbar sind.

Zwei Designregeln ergeben sich daraus. MCP trennt schreibgeschützte Ressourcen von Tools, die den Zustand ändern, und das Autorisierungsdesign sollte dieser Trennung folgen, da das Überprüfen eines Gleichgewichts und das Senden eines Wire Carries sehr unterschiedliche Risiken mit sich bringen. Zudem sind menschliche Genehmigungsmechanismen sowie Audit-Spuren für jeden Protokollaufruf Kernanforderungen; daher gehören sie in die erste Codezeile und nicht in einen späteren Patch.