Wer gibt einen KI-Trade frei? Was Broker-MCP-Verbindungen tatsächlich erlauben

Ein Assistent kann dein Portfolio erklären, ohne es verändern zu dürfen. Er kann eine Order vorbereiten, die du selbst übermittelst. Oder er kann über eine Verbindung verfügen, die Orders direkt einreicht. Alle drei Varianten können als „Broker mit KI verbinden“ erscheinen.

Unser früherer Überblick zur MCP-Infrastruktur erklärt, wie Agenten Finanzwerkzeuge erreichen. Dieser Folgeartikel stellt eine engere Frage: Welcher Teil des verbundenen Systems entscheidet, ob eine vorgeschlagene Aktion tatsächlich ausgeführt werden darf?

Diese Unterscheidung ist schon vor der Modellauswahl oder dem Vergleich von Agentenargumenten wichtig. Eine überzeugende Antwort, ein Paper-Konto und eine Bestätigung sagen jeweils etwas anderes über das System aus.

Zugriff, Umgebung und Freigabe trennen

Am Anfang stehen drei Fragen.

Zugriff: Welche Aktionen kann die Verbindung ausführen? Positionen lesen, Einstellungen ändern, eine Order stornieren und eine Order einreichen sind unterschiedliche Berechtigungen.

Umgebung: In welchem Konto landet die Aktion? Beim Paper-Trading erfolgt sie in einer simulierten Umgebung. Das kann finanzielle Folgen beim Testen begrenzen. Es beantwortet aber nicht die Frage, ob jede Aktion eine menschliche Freigabe braucht.

Freigabe: Was muss passieren, bevor genau diese Aktion gesendet wird? Eine Prompt-Regel, ein Bestätigungsdialog im Host und ein Ausführungsdienst, der nicht autorisierte Anfragen zurückweist, liegen an unterschiedlichen Stellen des Systems.

Die MCP-Tools-Spezifikation empfiehlt menschliche Aufsicht und Bestätigungsoberflächen, überlässt die konkrete Interaktion aber der Implementierung. Laut Schemareferenz sind Tool-Annotationen ebenfalls nur Hinweise. Ein readOnlyHint beschreibt ein Tool; er beschränkt nicht die Befugnisse der serverseitigen Zugangsdaten.

Ein OAuth-Zustimmungsdialog bringt eine weitere Unterscheidung mit: Die Autorisierung einer Verbindung ist nicht zwangsläufig die Freigabe jeder späteren Order. Entscheidend sind der tatsächliche Berechtigungsumfang und die Freigaberegeln.

Was die drei Verbindungen dokumentieren

Diese Produkte stellen unterschiedliche Funktionen bereit. Verglichen werden dokumentierte Aktionsgrenzen, nicht die Eignung eines Brokers oder seine Sicherheit in einer Rangliste.

Verbindung	Dokumentierte Funktionen	Zu unterscheidende Freigabegrenze
Gehosteter SnapTrade-MCP-Server	Liest verbundene Brokerdaten und kann einen Link zur Brokeranbindung erzeugen. Laut Dokumentation kann diese MCP-Schnittstelle weder handeln noch Geld bewegen oder Kontoeinstellungen ändern; die Tokens sind auf Lesezugriff beschränkt.	Die Zustimmung erlaubt den Datenzugriff. Handelsfunktionen in anderen Teilen der SnapTrade-API gehören nicht zu dieser dokumentierten MCP-Schnittstelle.
IBKR AI Integration im Standardmodus	Recherche, Überwachung und Vorbereitung von Orderanweisungen.	Laut IBKR prüft und übermittelt der Nutzer jede Order selbst. Eine Anweisung vorzubereiten ist etwas anderes, als sie auszuführen.
Separat beschriebenes IBKR Autonomous Trading	Unterstützte KI kann innerhalb einer mit Geld ausgestatteten AI Partition handeln. Dabei gelten Produkt- und Kontobeschränkungen.	IBKR beschreibt einen Modus ohne Bestätigung jeder einzelnen Order. Die Seite nennt Voraussetzungen und eine geplante Verfügbarkeit für bestimmte Gesellschaften. Diese Prüfung bestätigt keine Verfügbarkeit für ein bestimmtes Leserkonto.
Alpaca MCP v2	Stellt Handels- und Datentools in auswählbaren Gruppen bereit. Die konfigurierte Handelsumgebung ist standardmäßig Paper-Trading.	Tool-Freigabe und Kontoumgebung müssen getrennt geprüft werden. Der untersuchte Order-Wrapper verlangt keinen Nachweis einer menschlichen Freigabe. Ein Host oder zusätzlicher Dienst kann diesen verlangen; das wurde hier nicht getestet.

Verbindung

Gehosteter SnapTrade-MCP-Server

Dokumentierte Funktionen

Liest verbundene Brokerdaten und kann einen Link zur Brokeranbindung erzeugen. Laut Dokumentation kann diese MCP-Schnittstelle weder handeln noch Geld bewegen oder Kontoeinstellungen ändern; die Tokens sind auf Lesezugriff beschränkt.

Zu unterscheidende Freigabegrenze

Die Zustimmung erlaubt den Datenzugriff. Handelsfunktionen in anderen Teilen der SnapTrade-API gehören nicht zu dieser dokumentierten MCP-Schnittstelle.

Verbindung

IBKR AI Integration im Standardmodus

Dokumentierte Funktionen

Recherche, Überwachung und Vorbereitung von Orderanweisungen.

Zu unterscheidende Freigabegrenze

Laut IBKR prüft und übermittelt der Nutzer jede Order selbst. Eine Anweisung vorzubereiten ist etwas anderes, als sie auszuführen.

Verbindung

Separat beschriebenes IBKR Autonomous Trading

Dokumentierte Funktionen

Unterstützte KI kann innerhalb einer mit Geld ausgestatteten AI Partition handeln. Dabei gelten Produkt- und Kontobeschränkungen.

Zu unterscheidende Freigabegrenze

IBKR beschreibt einen Modus ohne Bestätigung jeder einzelnen Order. Die Seite nennt Voraussetzungen und eine geplante Verfügbarkeit für bestimmte Gesellschaften. Diese Prüfung bestätigt keine Verfügbarkeit für ein bestimmtes Leserkonto.

Verbindung

Alpaca MCP v2

Dokumentierte Funktionen

Stellt Handels- und Datentools in auswählbaren Gruppen bereit. Die konfigurierte Handelsumgebung ist standardmäßig Paper-Trading.

Zu unterscheidende Freigabegrenze

Tool-Freigabe und Kontoumgebung müssen getrennt geprüft werden. Der untersuchte Order-Wrapper verlangt keinen Nachweis einer menschlichen Freigabe. Ein Host oder zusätzlicher Dienst kann diesen verlangen; das wurde hier nicht getestet.

Die IBKR-Seite zeigt, warum der Produktname allein nicht ausreicht. Standardintegration und separat beschriebener autonomer Modus besitzen unterschiedliche Befugnisse zur Orderübermittlung. Laut Dokumentation storniert ein Widerruf der Verbindung zudem nicht automatisch offene oder teilweise ausgeführte Orders. Zugriffsentzug und Orderstornierung brauchen deshalb getrennte Verfahren. IBKR-FAQ zu Modi und Widerruf.

Auch eine Kontogruppe kann Schreibzugriffe enthalten

Die auf einen Commit festgelegten Alpaca-Toolset-Definitionen enthalten ein wichtiges Detail: Die Gruppe account umfasst patchAccountConfig. Neben Leseoperationen steht damit auch eine Änderung der Kontoeinstellungen zur Verfügung. Die Gruppe watchlists enthält ebenfalls Lese-, Erstellungs-, Änderungs- und Löschoperationen.

Die Deaktivierung der Gruppe trading belegt daher für sich genommen keinen reinen Lesezugriff. Gruppenbezeichnungen sind ein Ausgangspunkt. Die Prüfung muss bis zu den einzelnen Operationen reichen.

Die festgelegte Serverimplementierung wählt die Basis-URL für den Handel über ALPACA_PAPER_TRADE und filtert die Operationen getrennt nach Toolsets. Es handelt sich um unterschiedliche Mechanismen. Eine Änderung des einen belegt nicht die Wirkung des anderen.

Im geprüften Order-Wrapper erstellt die Aktienorder-Funktion eine Anfrage und übergibt sie an _post_order, das den Orderendpunkt aufruft. Dieser Wrapper verlangt weder einen Freigabe-Token noch einen menschlichen Bestätigungsschritt. Das ist ein Befund zu diesem Codepfad, kein Beleg dafür, dass jeder kompatible Host ohne Rückfrage handelt.

Die zugehörige Sicherheits-Middleware kennzeichnet zurückgegebene Daten als nicht vertrauenswürdig. Das betrifft die Interpretation der Tool-Ausgabe durch das Modell. Die Entscheidung, ob eine Order gesendet werden darf, ist eine andere Aufgabe.

Freigabe braucht eine klare Zuständigkeit

Ein Preprint von Yao et al. vom 2. November 2026 untersucht Bestätigungen zwischen MCP-Servern und Hosts. Die Autoren berichten über Lücken zwischen diesen Ebenen in den untersuchten Systemen. Es handelt sich um eine neue Vorabveröffentlichung, keine finanzspezifische Untersuchung. Sie belegt nicht das Verhalten der hier beschriebenen Brokerverbindungen. Relevant ist die Architekturfrage: Wer erzwingt tatsächlich den Halt vor der Aktion?

Für einen Ablauf mit Freigabe jeder einzelnen Order schlagen wir folgende Aufteilung vor. Sie ist ein zu prüfender Entwurf, keine implementierte Integration.

1. 01Vorschlagen

   Welche genaue Aktion wird angefragt?

   Konto und Umgebung · Instrument · Kauf oder Verkauf · Menge · Ordertyp und Preisbedingungen

2. 02Prüfen

   Passt der Vorschlag zu den geltenden Regeln und dem aktuellen Stand?

   Regelversion · Positionsstand · offene Orders · fehlende Informationen

3. 03Freigeben

   Wer hat diese Version genehmigt, und wo wird eine Ablehnung durchgesetzt?

   Authentifizierte Freigabe · Vorschlagskennung · Ablaufzeit · Ablehnungspfad

4. 04Übermitteln und abgleichen

   Was hat der Broker angenommen, abgelehnt oder ausgeführt?

   Übermittlungskennung · Brokerantwort · unklarer Status · spätere Ausführungen

In diesem Entwurf bezieht sich die Freigabe auf eine bestimmte Version der Aktion. Ändern sich danach Konto, Instrument, Umfang oder Orderbedingungen, sind eine neue Prüfung und Freigabe nötig. Diese Regel wird von der Ausführungskomponente durchgesetzt. Ein vom Modell erzeugtes Feld approved: true ist kein unabhängiger Autorisierungsnachweis.

Die Zugangsdaten für die Übermittlung bleiben hinter dieser Komponente. Kann der Agent dieselben Daten über einen anderen Server oder einen direkten API-Pfad verwenden, lässt sich die vorgeschlagene Prüfstufe umgehen.

Auch fehlgeschlagene Übergaben prüfen

Eine Demonstration mit bestätigter Order prüft einen einzigen Ablauf. Aussagekräftiger ist eine Prüfung, die auch Ablehnung, fehlenden Kontext und unklare Ergebnisse abdeckt.

Vorgeschlagenes Szenario	Zu prüfendes Verhalten bei Freigabe jeder Order
Die Verbindung soll nur lesen können	Schreibwerkzeuge fehlen oder werden abgewiesen. Neben neuen Orders auch Kontoeinstellungen und Stornierungen prüfen.
Der Nutzer lehnt die Freigabe ab oder schließt den Dialog	Keine Anfrage zur Orderübermittlung erreicht den Broker.
Die vorgeschlagene Menge ändert sich nach der Freigabe	Die alte Freigabe kann die geänderte Anfrage nicht autorisieren.
Benötigte Positionen, Bewertungen oder Informationen zu offenen Orders fehlen	Die konfigurierte Regelprüfung liefert ausdrücklich ein ungeklärtes Ergebnis, statt stillschweigend eine Nullexposition oder eine bestandene Prüfung anzunehmen.
Die Übermittlung endet mit einer Zeitüberschreitung	Vor einem weiteren Versuch die ursprüngliche Anfrage mit dem Brokerstatus abgleichen.
Der Zugriff wird widerrufen, während eine Order offen ist	Den getrennten Prozess zur Erkennung und Behandlung offener Orders bestätigen.

Vorgeschlagenes Szenario

Die Verbindung soll nur lesen können

Zu prüfendes Verhalten bei Freigabe jeder Order

Schreibwerkzeuge fehlen oder werden abgewiesen. Neben neuen Orders auch Kontoeinstellungen und Stornierungen prüfen.

Vorgeschlagenes Szenario

Der Nutzer lehnt die Freigabe ab oder schließt den Dialog

Zu prüfendes Verhalten bei Freigabe jeder Order

Keine Anfrage zur Orderübermittlung erreicht den Broker.

Vorgeschlagenes Szenario

Die vorgeschlagene Menge ändert sich nach der Freigabe

Zu prüfendes Verhalten bei Freigabe jeder Order

Die alte Freigabe kann die geänderte Anfrage nicht autorisieren.

Vorgeschlagenes Szenario

Benötigte Positionen, Bewertungen oder Informationen zu offenen Orders fehlen

Zu prüfendes Verhalten bei Freigabe jeder Order

Die konfigurierte Regelprüfung liefert ausdrücklich ein ungeklärtes Ergebnis, statt stillschweigend eine Nullexposition oder eine bestandene Prüfung anzunehmen.

Vorgeschlagenes Szenario

Die Übermittlung endet mit einer Zeitüberschreitung

Zu prüfendes Verhalten bei Freigabe jeder Order

Vor einem weiteren Versuch die ursprüngliche Anfrage mit dem Brokerstatus abgleichen.

Vorgeschlagenes Szenario

Der Zugriff wird widerrufen, während eine Order offen ist

Zu prüfendes Verhalten bei Freigabe jeder Order

Den getrennten Prozess zur Erkennung und Behandlung offener Orders bestätigen.

Das sind Akzeptanzkriterien, die ein Prüfer ausführen und dokumentieren kann. Wir haben sie nicht gegen die drei Dienste ausgeführt.

Zeitüberschreitungen verdienen einen eigenen Eintrag. Alpacas geprüfter Wrapper warnt ausdrücklich, dass eine Anfrage den Broker bereits erreicht haben kann, obwohl die Antwort verloren ging. Eine Fehlermeldung beweist daher nicht, dass keine Order existiert. Festgelegter Übermittlungscode.

Prüfvorlage herunterladen. Serverversion, Host-Konfiguration, Berechtigungen der Zugangsdaten, Kontoumgebung und Belege für jedes Ergebnis festhalten. Ungeprüfte Zeilen bleiben als solche markiert. Die Vorlage dokumentiert eine Prüfung; sie setzt keine Berechtigungen durch.

Wo der Anlegerkontext hingehört

Eine Ausführungsgrenze braucht auch einen Prüfmaßstab. Portfolioexposition, Ausschlüsse und Anlageregeln müssen das System in nutzbarer Form erreichen.

Der TradingAgents–Investboard-Connector dokumentiert die Bereitstellung von Regel- und Positionskontext. Anschließend wird die fertige Analyse zur Speicherung und Mandatsprüfung an Investboard gesendet, das David Bartas gegründet hat. Unsere Connector-Fallstudie trennt die Verarbeitung dieser Aufzeichnungen vom Modellverhalten und der Prüfung am echten Server.

Das ist eine Aufgabe für Kontext und Protokolle. Ein gespeichertes Ergebnis der Mandatsprüfung belegt keine Durchsetzung beim Broker. Eine Verbindung zu einem Ordergateway bräuchte einen separat implementierten und getesteten Ausführungspfad. Die vorgeschlagene Architektur setzt Investboard nicht voraus; andere Systeme oder versionierte lokale Aufzeichnungen können dieselben Aufgaben erfüllen.

Eine brauchbare Aufzeichnung verbindet den ursprünglichen Vorschlag, die geprüften Eingaben, die Freigabe und das spätere Brokerergebnis. Bleibt eine Übergabe ungeklärt, sollte das ausdrücklich als „unbekannt“ erhalten bleiben.

Quellen und Umfang

Dieser Artikel wurde mit KI-Unterstützung anhand von Primärdokumentation und Quellcode erstellt, die am 4. November 2026 geprüft wurden. Es wurden kein Modellbenchmark, kein Sicherheitsaudit, kein authentifizierter Kontotest und keine Bewertung von Anlageergebnissen durchgeführt.

Die Alpaca-Codebefunde beziehen sich auf Commit 63cc4278d87b31f3ed4efcfaa55624095c6d7be8. Die gehostete Dokumentation wurde mit Stand des genannten Datums geprüft; sie ist keine unveränderliche Momentaufnahme des Dienstes. Verfügbarkeit, Tools und Host-Regeln können sich ändern.

• Protokoll: MCP-Tools-Spezifikation, Version 2025-11-25 und Schema der Tool-Annotationen.
• Alpaca: Festgelegte README, Serveraufbau, Toolsets, Order-Wrapper und Ausgabe-Middleware.
• Interactive Brokers: Dokumentation zu AI Integration und Autonomous Trading, einschließlich der Einschränkungen zu Voraussetzungen und Verfügbarkeit.
• SnapTrade: Funktionen und Authentifizierung des gehosteten MCP-Servers. Diese Angaben betreffen die MCP-Schnittstelle, nicht jede SnapTrade-API.
• Forschungskontext: Yao et al., When Neither Side Confirms, Preprint v1, eingereicht am 2. November 2026. Die Ergebnisse werden den Autoren zugeschrieben und wurden für diesen Artikel nicht reproduziert.
• Anlegerkontext: TradingAgents–Investboard-Dokumentation und unsere frühere reproduzierbare Fallstudie. Die Prüfung im November wiederholt deren Offline-Experimente nicht.