In 30 Sekunden
- Zwei Arten von Werkzeugen: Websuche, X-Suche und Code-Ausführung führt SpaceXSI auf eigenen Servern aus; bei Remote-MCP baut SpaceXSI die Verbindung zum MCP-Server auf und ruft ihn selbst auf. Eigene Funktionen (Function Calling) führt dagegen die Anwendung des Unternehmens aus, die Anfrage pausiert dafür.
- Außerhalb der Standortzusage: Auch über den US-Endpunkt gilt die US-Zusage laut xAI nicht für serverseitige Werkzeuge. Sie können Daten außerhalb der USA verarbeiten.
- Remote-MCP ohne Freigabeschritt: Der Parameter
require_approvalwird laut Doku nicht unterstützt. Ohneallowed_toolssieht das Modell alle Werkzeuge eines MCP-Servers. - Ergebnisse bleiben unsichtbar: Die API zeigt, welche serverseitigen Werkzeuge mit welchen Argumenten aufgerufen wurden, gibt deren Ergebnisse aber nicht zurück.
Executive Summary
Serverseitige Werkzeuge sind bequem, verlagern aber Ausführung und Kontrolle zu SpaceXSI. Für öffentliche Recherche ohne Personenbezug ist das vertretbar, lesender Zugriff auf interne Daten über Remote-MCP nach Prüfung ebenfalls. Kritische oder schreibende Aktionen gehören als eigene Funktion in die eigene Anwendung. Die Datenfrage löst auch das nicht: Was eine eigene Funktion zurückgibt, geht wieder an SpaceXSI.
Was Unternehmen jetzt tun sollten
- Architektur, vor dem PilotJe Werkzeug entscheiden: serverseitig bei SpaceXSI oder als eigene Funktion. Kritische und schreibende Aktionen als eigene Funktion bauen, lesenden MCP-Zugriff nur nach Prüfung von Rechten und Daten freigeben.
- Datenschutz, vor dem ersten AufrufKlären, ob Prompts, Werkzeugaufrufe oder Ergebnisse eigener Funktionen Personendaten enthalten. Der Auftragsverarbeitungsvertrag verlangt dafür die ZDR-API, für Werkzeuge kommt die fehlende Standortzusage hinzu.
- Plattformteam, im BetriebWerkzeuge pro Anfrage begrenzen (
allowed_tools, Domain- und Handle-Filter,max_turns) und die protokollierten Werkzeugaufrufe samt Argumenten auswerten.
Der Beitrag richtet sich an Plattform-, Sicherheits- und Datenschutzteams, die mit der Grok-API einen Agenten bauen wollen, der recherchiert, rechnet oder interne Systeme anspricht. Wer nur Texte erzeugt, braucht ihn nicht. Sinnvoll beginnt man mit einer Liste der geplanten Werkzeuge und einer Frage je Eintrag: Wer führt es aus, und welche Daten verlassen dabei die eigene Umgebung?
Wo die Werkzeuge im Angebot von xAI stehen
Werkzeuge sind ein Teil der Grok-API, also des Entwicklerangebots, das die Seite xAI für Unternehmen neben Grok Voice und Grok Business einordnet. Dieser Beitrag behandelt die Werkzeuge, die eine Anwendung der API pro Anfrage mitgibt. Nicht behandelt werden die Konnektoren im Chat-Produkt Grok Business und Enterprise (dazu der Beitrag zu Grok Business und Enterprise) und die Dokumentensuche über Collections, für die der Beitrag zu Files und Collections eigene Regeln beschreibt.
Die Werkzeugübersicht von xAI unterscheidet zwei Arten. Eingebaute Werkzeuge wie Websuche, X-Suche, Code-Ausführung, Bilderzeugung und Collections-Suche laufen laut xAI auf den Servern von SpaceXSI: Die Anwendung gibt nur die Konfiguration mit, die API führt aus und liefert die Antwort. Beim Function Calling definiert die Anwendung eigene Werkzeuge, das Modell fordert einen Aufruf an, und die Anwendung entscheidet, was passiert. Remote-MCP liegt dazwischen: Der MCP-Server gehört dem Unternehmen oder einem Dritten, die Verbindung baut aber SpaceXSI auf.
Die Grenze zwischen beiden Arten ist die eigentliche Architekturentscheidung. Serverseitig heißt: weniger Code, aber Ausführung, Standort und Einsicht liegen bei SpaceXSI. Eine eigene Funktion kostet Entwicklungsaufwand und bringt dafür die Kontrolle über die Ausführung zurück, nicht über die Daten: Ihr Ergebnis geht wieder an SpaceXSI.
Wie eine Anfrage mit Werkzeugen abläuft
Laut der Seite zur erweiterten Nutzung führt SpaceXSI serverseitige Werkzeuge automatisch aus, sobald das Modell sie wählt. Ruft das Modell dagegen eine eigene Funktion auf, pausiert die Ausführung, und die API gibt den Aufruf an die Anwendung zurück. Erst wenn die Anwendung das Ergebnis anhängt und eine neue Anfrage stellt, geht es weiter. Dieses Ergebnis landet damit ebenfalls bei SpaceXSI: Eigene Funktionen verlagern die Ausführung ins Unternehmen, nicht den Datenfluss. Was zurückgegeben wird, sollte deshalb auf das Nötige beschränkt sein. Die Animation zeigt diesen Ablauf schematisch.
Redaktionelle, schematische Darstellung von AI-Fabrik nach der xAI-Dokumentation zu Werkzeugen, erweiterter Nutzung und Werkzeugdetails. Reihenfolge und Zahl der Aufrufe wählt das Modell selbst; eine Anfrage kann auch nur serverseitige oder nur eigene Werkzeuge nutzen.
Zwei Punkte aus dem Ablauf sind für die Kontrolle entscheidend. Erstens formuliert das Modell die Suchanfragen selbst. Die Doku zur X-Suche sagt ausdrücklich, dass die Ergebnisse variieren, weil das Modell seine Suchbegriffe wählt. Was im Prompt steht, kann also in Suchbegriffen an externe Dienste gelangen. Zweitens gibt die API laut Werkzeugdetails nur die Aufrufe mit ihren Argumenten zurück, nicht die Ausgaben der serverseitigen Werkzeuge. Wer prüfen will, welche Seite oder welcher MCP-Rückgabewert eine Antwort beeinflusst hat, sieht nur die Quellenangaben und die Aufrufliste.
Was die einzelnen Werkzeuge erlauben und begrenzen
| Werkzeug | Steuerung laut Doku | Preis laut Preisseite |
|---|---|---|
| Websuche | Bis zu fünf erlaubte oder ausgeschlossene Domains, nicht beides zugleich; Bildanalyse optional | 5 US-Dollar je 1.000 erfolgreiche Aufrufe, dazu Tokens |
| X-Suche | Bis zu 20 erlaubte oder ausgeschlossene Handles, Zeitraum; Bild- und Videoanalyse optional, standardmäßig aus | Seit 21.09.2026 je Abruf: 5 US-Dollar je 1.000 Posts, 10 US-Dollar je 1.000 Profile |
| Code-Ausführung | Python in einer Sandbox ohne Netzwerkzugang, kein Zustand zwischen Anfragen | 5 US-Dollar je 1.000 Aufrufe |
| Remote-MCP | Server-URL, allowed_tools, Token und Header; keine Freigabe per require_approval | Keine Aufrufgebühr, nur Tokens |
| Eigene Funktion | Ausführung, Prüfung und Protokoll vollständig in der eigenen Anwendung | Nur Tokens |
Quellen: xAI-Dokumentation zu Websuche, X-Suche, Code-Ausführung, Remote-MCP und Preise, abgerufen am 13. November 2026. Abgerechnet werden laut xAI nur erfolgreiche Werkzeugaufrufe.
Die Code-Ausführung ist das am besten abgeschottete Werkzeug: laut Doku eine isolierte Python-Umgebung ohne Zugang zu externen Netzwerken, deren Zustand nach der Anfrage verschwindet. Die Daten, mit denen sie rechnet, kommen aber aus dem Prompt und laufen damit über SpaceXSI. Websuche und X-Suche lassen sich über Filter eingrenzen. Die Filter beschränken, wo gesucht wird, nicht, was das Modell als Suchbegriff verwendet.
Der Parameter max_turns begrenzt laut Doku die Zahl der Runden im Agentenablauf, nicht die Zahl der Werkzeugaufrufe, denn in einer Runde kann das Modell mehrere Werkzeuge parallel aufrufen. Für die Kostenkontrolle reicht er deshalb allein nicht. Eine eigene Rechnung zur Größenordnung: Ruft ein Recherche-Agent pro Anfrage im Schnitt dreimal die Websuche auf, kosten 10.000 Anfragen allein für die Aufrufe 150 US-Dollar, die Tokens kommen hinzu. Die Zahl der Aufrufe je Anfrage ist eine Annahme, sie muss im Pilot gemessen werden.
Remote-MCP: bequem, aber ohne Freigabe
Bei Remote-MCP gibt die Anwendung eine Server-URL mit, und laut Doku verwaltet SpaceXSI die Verbindung und die Interaktion mit dem Server. Ein optionales Token setzt xAI als Authorization-Header bei den Anfragen an den MCP-Server. Daraus folgen drei Punkte, die wir als redaktionelle Schlussfolgerung festhalten:
- Erreichbarkeit: Weil SpaceXSI die Verbindung aufbaut, muss der MCP-Server für die Server von SpaceXSI erreichbar sein. Ein Server, der nur im Firmennetz läuft, funktioniert so nicht, ohne ihn nach außen zu öffnen.
- Zugangsdaten: Das Token geht mit jeder Anfrage an SpaceXSI und wird von dort an den MCP-Server weitergereicht. Es sollte deshalb nur so viel dürfen wie das Werkzeug, eng befristet sein und nicht für andere Systeme gelten.
- Keine Freigabe im Ablauf:
require_approvalwird nicht unterstützt. Ein Werkzeug, das der MCP-Server anbietet und das nicht überallowed_toolsausgeschlossen ist, kann das Modell ohne Zwischenschritt aufrufen.
xAI empfiehlt selbst, mit allowed_tools nur die nötigen Werkzeuge freizugeben, etwa nur lesende. Das ist sinnvoll, ersetzt aber keine Rechteprüfung auf dem MCP-Server. Für schreibende Aktionen in Fachsystemen halten wir den Weg über eine eigene Funktion für den belastbareren: Die Anfrage pausiert, die Anwendung prüft Ziel und Umfang, holt bei Bedarf eine Freigabe ein und protokolliert die Ausführung.
Prompt-Injection über Suchergebnisse: Websuche und X-Suche bringen fremde Inhalte in den Kontext, die Anweisungen enthalten können. xAI zeigt in einem eigenen Leitfaden zehn präparierte Angriffe gegen einen simulierten Mail-Assistenten. Jede der vier Abwehrmaßnahmen (Seiten als Daten behandeln, Werkzeuge je Schritt begrenzen, Argumente prüfen, Versand von einem Menschen bestätigen lassen) verfehlte allein mindestens einen Angriff, alle vier zusammen stoppten in dem Durchlauf alle zehn. Das ist eine Demonstration des Herstellers mit einem Durchlauf je Einstellung, keine unabhängige Prüfung. Die Lehre gilt trotzdem: Ein Agent, der im Web liest und zugleich Aktionen auslösen kann, braucht mehrere Schutzschichten.
Personendaten und Verarbeitungsort
Laut Regionen-Doku garantiert xAI beim globalen Endpunkt keinen Verarbeitungsort. Der US-Endpunkt sichert Verarbeitung und Speicherung in den USA zu, nimmt aber Files, Collections und serverseitige Werkzeuge wie Websuche, X-Suche und Code-Ausführung ausdrücklich aus. Diese funktionieren dort weiter, können aber Daten außerhalb der USA verarbeiten. Wo genau, sagt die Doku nicht. Eine EU-Region gibt es nicht.
Hinzu kommt der Vertrag. Der Auftragsverarbeitungsvertrag vom 22. September 2026 verlangt, dass Kunden personenbezogene Daten nur über die ZDR-API verarbeiten, also mit eingeschalteter Null-Speicherung. Die Sicherheits-FAQ führt Werkzeuge nicht unter den Funktionen, die mit ZDR wegfallen. Allerdings fällt die gespeicherte Gesprächsfortsetzung weg, und für den Zustand des Werkzeugablaufs verweist xAI dann auf verschlüsselte Inhalte, die die Anwendung selbst mitführt. Ohne ZDR speichert SpaceXSI Anfragen und Antworten 30 Tage.
Für Unternehmen in der EU heißt das: Sollen Personendaten in Prompts, Werkzeugaufrufe oder Funktionsergebnisse gelangen, verlangt der Auftragsverarbeitungsvertrag die ZDR-API für das ganze Team. Das ist eine Voraussetzung, keine Freigabe: Rechtsgrundlage und Übermittlung in Drittländer ohne zugesagten Ort sind gesondert zu prüfen. Die Grundlagen dazu, vom Vertragspartner bis zu den Behördenverfahren, stehen im EU-Check zu Grok.
Was offen bleibt: Die Doku nennt nicht, welcher Suchdienst hinter der Websuche steht, wo serverseitige Werkzeuge rechnen und ob die intern verwendeten Ergebnisse serverseitiger Werkzeuge unter die 30-Tage-Speicherung fallen. Diese drei Fragen sollten Unternehmen vor einem Pilot mit Personenbezug schriftlich bei xAI klären.
Wie viel Aufwand angemessen ist
| Stufe | Typischer Einsatz | Empfohlene Werkzeugwahl und Kontrollen |
|---|---|---|
| Basis | Markt- oder Themenrecherche mit öffentlichen Quellen, keine Personendaten im Prompt | Websuche und X-Suche serverseitig, Domain- und Handle-Filter, max_turns, Prüfung der Quellenangaben |
| Standard | Agent liest interne Daten über MCP oder eigene Funktionen, ohne zu schreiben | MCP nur mit allowed_tools für lesende Werkzeuge und eigenem, eng begrenztem Token; Auswertung der Aufrufargumente; Datenschutzprüfung |
| Erweitert | Schreibende Aktionen in Fachsystemen, Personendaten, Kundenkontakt | Aktionen nur als eigene Funktionen mit Rechteprüfung und Freigabe außerhalb des Modells; ZDR; schriftliche Klärung von Verarbeitungsort und Speicherung; wiederholbare Tests gegen Prompt-Injection |
Einteilung nach möglicher Wirkung und Umkehrbarkeit, Empfehlung von AI-Fabrik. Auch ein kleines Team braucht für schreibende Aktionen die erweiterte Stufe, eine reine Recherche dagegen keinen Konzernprozess.
Pilotfragen vor dem ersten Agenten
- Welche Werkzeuge braucht der Fall, und welches davon erreicht interne Systeme oder löst Aktionen aus? Kritische und schreibende Aktionen gehören als eigene Funktion in die Anwendung.
- Können Personendaten in den Prompt gelangen, auch indirekt über Suchbegriffe, die das Modell formuliert, oder über Ergebnisse eigener Funktionen? Wenn ja: ZDR für das Team und Bewertung der Übermittlung ohne zugesagten Ort.
- Ist ein geplanter MCP-Server für SpaceXSI erreichbar, ohne mehr freizugeben als nötig, und welche Rechte hat das Token?
- Reicht es für Nachvollziehbarkeit und Revision, bei serverseitigen Werkzeugen nur die Aufrufe mit Argumenten zu sehen, nicht deren Ergebnisse?
- Welche Obergrenzen gelten für Runden, Filter und Kosten je Anfrage, und wer wertet die Nutzungszahlen aus?
Fazit: Serverseitig recherchieren, selbst handeln
Die serverseitigen Werkzeuge der Grok-API sind für öffentliche Recherche schnell eingerichtet und günstig, für Firmendaten geben sie Ausführung und Einsicht aus der Hand. Eine tragfähige Aufteilung: Recherche ohne Personenbezug serverseitig, lesender MCP-Zugriff auf interne Daten nach Prüfung, kritische und schreibende Aktionen als eigene Funktion mit eigener Prüfung. Datenschutzrechtlich bleibt jede dieser Varianten eine Übermittlung an SpaceXSI.
Die nächste Entscheidung: Welche Werkzeuge des geplanten Agenten werden eigene Funktionen, und wer verantwortet deren Regeln?
Quellen
Anbieter (abgerufen am 13. November 2026)
- SpaceXSI (xAI): Tools Overview, Advanced Usage, Tool Usage Details
- SpaceXSI (xAI): Web Search, X Search, Code Execution, Remote MCP Tools
- SpaceXSI (xAI): Pricing (Werkzeugpreise)
- SpaceXSI (xAI): Regional Endpoints und Security FAQ (Speicherung, ZDR)
- SpaceXSI (xAI): Prompt Injection Defenses (Herstellerdemonstration)
Vertrag
- SpaceXSI: Data Processing Addendum, gültig ab 22. September 2026



