API-Keys für Trading-Bots Rechte, IP-Sperre, Rotation.

Ein API-Key für einen Trading-Bot braucht genau die Rechte, die der Bot für seine Aufgabe nutzt, und keine darüber hinaus: Lesen und Handeln ja, Auszahlung nie. Dazu gehört eine IP-Sperre auf die feste Adresse Ihres Servers, damit ein abgeflossener Schlüssel von fremden Rechnern aus nutzlos ist. Diese Checkliste richtet sich an private Trader ebenso wie an Unternehmen, die eigene Bots betreiben. Sie zeigt, wie Sie Lese- und Handelsschlüssel trennen, welcher Schlüsseltyp (HMAC, Ed25519 oder RSA) sinnvoll ist, wo Schlüssel auf dem Server liegen sollten und was im Ernstfall zu tun ist. Ein eigener Abschnitt behandelt Schlüssel für Sprachmodelle wie die OpenAI-API, die in vielen Bots inzwischen mitlaufen; dort gibt es seit September 2026 Ablaufdaten und neue Kontrollen für Admins. Die Angaben zu Binance, Kraken und OpenAI geben den Stand Oktober 2026 wieder. Oberflächen und Regeln der Anbieter ändern sich regelmäßig.

Welche Rechte braucht ein API-Key für einen Trading-Bot?

Ein API-Key (Programmierschlüssel) ist für die Börse oder den Broker gleichbedeutend mit Ihrem Konto: Wer ihn hat, kann alles tun, was die freigeschalteten Rechte erlauben. Deshalb gilt das Prinzip der minimalen Rechte (Least Privilege): Jeder Schlüssel bekommt nur, was sein Prozess wirklich braucht. Bei Binance stehen Stand Oktober 2026 unter anderem die Rechte Lesen, Spot- und Margin-Handel, Futures-Handel und Auszahlung zur Wahl. Kraken unterteilt feiner, etwa in „Query Funds“ (Kontostand abfragen), „Create & Modify Orders“, „Cancel/Close Orders“ und „Withdraw Funds“ (Auszahlung).

Statt eines Generalschlüssels für alles lohnt sich die Trennung nach Aufgaben. Kraken empfiehlt in seiner Entwickler-Dokumentation ausdrücklich, Marktdaten, Handel und Buchhaltung über getrennte Schlüssel laufen zu lassen. Eine typische Aufteilung:

Der Vorteil zeigt sich im Ernstfall. Fließt der Reporting-Schlüssel ab, sieht ein Angreifer Ihre Kontostände, kann aber keine Order platzieren. Müssen Sie einen Schlüssel sperren, laufen die anderen Prozesse weiter. Wenn ich Trading-Systeme entwickle, bekommt deshalb jeder Prozess einen eigenen, sprechend benannten Schlüssel, damit sich jede Order einem System zuordnen lässt.

Auszahlung aus, IP-Sperre an: die zwei wichtigsten Einstellungen.

Ein Trading-Bot muss kein Geld abheben. Das Auszahlungsrecht ist deshalb der eine Haken, den Sie bei einem Bot-Schlüssel nie setzen sollten. Kraken formuliert es in der Dokumentation direkt: Ein Schlüssel, der nur Orders platziert, braucht „Withdraw Funds“ nicht. Ein kompromittierter Schlüssel mit Auszahlungsrecht ist ein unmittelbares finanzielles Risiko, weil Guthaben dann auf fremde Adressen wandern kann.

Die zweite Einstellung ist die IP-Sperre (IP-Whitelist): Der Schlüssel funktioniert nur von den Adressen aus, die Sie hinterlegen. Binance rät dringend davon ab, andere Rechte als Lesen ohne passende IP-Beschränkung freizugeben; für das Auszahlungsrecht ist eine Beschränkung im IPv4-Format Pflicht. Seit dem 30.01.2023 lassen sich von Binance erzeugte Schlüssel ohne IP-Beschränkung ohnehin nur noch auf Lesen setzen. Kraken beschreibt das IP-Whitelisting als Einzelmaßnahme, die fast jeden Missbrauch verhindert, selbst wenn der Schlüssel abfließt.

Praktisch setzt das eine feste öffentliche IP-Adresse voraus. Ein VPS (virtueller Server im Rechenzentrum) hat sie in der Regel, ein privater Internetanschluss mit wechselnder Adresse oft nicht. Wer den Bot zu Hause betreibt, müsste die Freigabe bei jedem Adresswechsel anpassen oder auf die IP-Sperre verzichten. Für Handelsschlüssel ist Letzteres keine gute Option. Ziehen Sie den Bot auf einen neuen Server um, gehört die neue Adresse vor dem Umzug in die Freigabe und die alte danach heraus.

HMAC, Ed25519 oder RSA: welcher Schlüsseltyp ist sicherer?

Börsen-APIs prüfen jede private Anfrage über eine Signatur. Beim klassischen HMAC-Verfahren erzeugt die Börse ein Paar aus API-Key und geheimem Schlüssel (Secret). Beide Seiten kennen dasselbe Geheimnis, das Verfahren ist symmetrisch. Bei Ed25519 und RSA erzeugen Sie selbst ein Schlüsselpaar und hinterlegen bei der Börse nur den öffentlichen Teil; der private Schlüssel verlässt Ihren Server nicht. Binance unterstützt alle drei Varianten und empfiehlt in der API-Dokumentation ausdrücklich Ed25519, weil es unter den unterstützten Typen die beste Leistung und Sicherheit biete.

Asymmetrische Schlüssel lösen nicht jedes Problem. Liegt der private Ed25519-Schlüssel ungeschützt auf dem Server, ist er genauso angreifbar wie ein HMAC-Secret. Der Gewinn liegt woanders: Das Geheimnis existiert nur an einer Stelle, wird nie aus einer Weboberfläche kopiert und lässt sich zusätzlich mit einer Passphrase schützen.

Zur Signatur gehören Schutzmechanismen gegen wiederholt eingespielte Anfragen. Binance verlangt einen Zeitstempel und akzeptiert die Anfrage nur innerhalb eines Zeitfensters (recvWindow, Standard 5.000 Millisekunden, maximal 60.000); die Dokumentation empfiehlt 5.000 oder weniger. Kraken verlangt eine Nonce, also eine pro Schlüssel strikt steigende Zahl, die sich nicht zurücksetzen lässt. Zu viele ungültige Nonces können zu einer temporären Sperre führen. Teilen sich zwei Prozesse einen Kraken-Schlüssel, geraten ihre Nonces leicht durcheinander. Auch das spricht für einen Schlüssel je Prozess.

Keys sicher ablegen: nicht im Code, nicht im Repo, nicht im Prompt.

Ein typischer Weg, auf dem Schlüssel abfließen, ist banal: Sie liegen an der falschen Stelle. Im Quellcode, in einer Konfigurationsdatei im Git-Repository, in einem Screenshot fürs Forum oder in einem Chatverlauf mit einem KI-Assistenten.

Das Secrets Management Cheat Sheet von OWASP (eine gemeinnützige Initiative für Anwendungssicherheit) fasst die Regeln zusammen: Secrets nie im Code ablegen, zentral verwalten, nach minimalen Rechten vergeben, regelmäßig rotieren, Zugriffe protokollieren und Änderungen schon vor dem Hochladen automatisch nach Schlüsseln durchsuchen, etwa per Pre-Commit-Hook auf dem eigenen Rechner oder direkt in der Entwicklungsumgebung. Von Umgebungsvariablen rät OWASP eher ab, weil sie oft für andere Prozesse zugänglich sind und in Logs oder Speicherabbildern landen können; besser sind als Datei eingebundene Secrets.

Für einen privaten Bot auf einem einzelnen VPS ist ein vollwertiger Secrets-Manager oft überdimensioniert. Ein pragmatischer Mindeststandard:

• Schlüssel in einer eigenen Datei außerhalb des Projektordners, die nur der Systemdienst lesen kann, der den Bot startet.
• Der Bot läuft unter einem eigenen Linux-Benutzer ohne Administratorrechte.
• Die Schlüsseldatei landet in keiner Sicherung, die unverschlüsselt in eine Cloud wandert.
• Der Bot schreibt Schlüssel nie ins Log, auch nicht über Fehlermeldungen oder Debug-Ausgaben von Bibliotheken.
• Im Repository läuft ein Secret-Scanner als Pre-Commit-Hook, der Schlüssel erkennt, bevor sie in einem Commit landen.

# /etc/systemd/system/tradingbot.service (Auszug)
[Service]
User=tradingbot
EnvironmentFile=/etc/tradingbot/keys.env

# Schlüsseldatei nur für root lesbar:
# chown root:root /etc/tradingbot/keys.env
# chmod 600 /etc/tradingbot/keys.env

In diesem Beispiel liest systemd die Datei als root und übergibt die Werte als Umgebungsvariablen an den Bot-Prozess; der Benutzer „tradingbot“ selbst kann die Datei nicht öffnen. Das ist ein pragmatischer Kompromiss: Die Werte stehen danach in der Umgebung des Prozesses, deshalb darf der Bot sie nie in Logs oder Fehlermeldungen ausgeben. Wer der OWASP-Empfehlung enger folgen will, übergibt die Schlüssel stattdessen als Datei, unter systemd etwa über die Option LoadCredential. Unternehmen mit mehreren Systemen und Teams fahren mit einem zentralen Secrets-Manager besser, weil Zugriffe dort protokolliert und Rechte je Person vergeben werden.

Der dritte Ort, an dem Schlüssel nichts verloren haben, ist der Prompt. Wer einem KI-Assistenten eine Fehlermeldung samt Konfiguration einfügt oder einen Coding-Agenten im Projektordner mit echten Schlüsseln arbeiten lässt, gibt die Schlüssel an einen weiteren Dienst weiter. Was dabei schiefgehen kann, zeigt der Artikel über Coding-Agenten und den Grok-Build-Vorfall. Kurz: Entwicklung nur mit Testnet- oder Demo-Schlüsseln, Live-Schlüssel nur auf dem Produktionsserver.

LLM-Keys im Bot: Projekte, Service-Accounts, Ablaufdaten, Limits.

Viele Bots rufen inzwischen auch ein Sprachmodell auf, etwa um Nachrichten zu klassifizieren oder Tagesberichte zu schreiben. Ein solcher Schlüssel kann keine Order auslösen, aber Kosten verursachen und Daten preisgeben. Bei OpenAI bewährt sich Stand Oktober 2026 dieser Aufbau:

• Eigenes Projekt je Bot oder Umgebung: Projekte trennen Schlüssel, Nutzung und Limits. Rate Limits gelten laut OpenAI auf Organisations- und Projektebene.
• Service-Account statt persönlichem Schlüssel: Ein Service-Account-Schlüssel gehört zum Projekt und hängt nicht am Konto eines einzelnen Menschen.
• Rechte begrenzen: Ein Bot, der nur Texte auswertet, braucht keinen Vollzugriff auf alle Ressourcen des Projekts. Prüfen Sie beim Anlegen, welche Schlüsselrechte sich einschränken lassen.
• Ablaufdatum: Seit 10.09.2026 lassen sich Projektschlüssel mit Ablaufdatum anlegen; Admins können eine maximale Lebensdauer für Organisation oder Projekt erzwingen.
• Erstellung steuern: Seit 15.09.2026 können Admins nur Service-Account-Schlüssel erlauben, nur persönliche Projektschlüssel erlauben oder die Erstellung neuer Schlüssel ganz sperren. Die Einstellung steuert die Neuanlage; vorhandene Schlüssel prüfen Sie trotzdem separat.
• Harte Ausgabenlimits: Seit 22.07.2026 gibt es monatliche Obergrenzen für Organisationen und Projekte. Ist das Limit erreicht, enden betroffene Anfragen mit dem Fehler 429.

Unabhängig davon gilt ein Monatslimit je Nutzungsstufe. OpenAI nennt Stand 07.10.2026: Free 100 US-Dollar, Build 500, Launch 5.000 und Grow 200.000 US-Dollar pro Monat. Am 06.10.2026 hat OpenAI die bezahlten Stufen auf diese drei zusammengefasst. Für einen Bot ist das selbst gesetzte Projektlimit die wichtigere Zahl, weil es zu Ihrem tatsächlichen Bedarf passt.

Entscheidend ist, was der Bot tut, wenn das Sprachmodell nicht antwortet. Ein Fehler 429 wegen eines erreichten Limits, ein abgelaufener Schlüssel oder ein Ausfall des Anbieters darf nicht dazu führen, dass offene Positionen ohne Absicherung bleiben. Ein robustes Muster: Ohne Antwort des Modells keine neuen Positionen, und die Schutzorders für bestehende Positionen liegen ohnehin beim Broker. Ein Ablaufdatum ist nur dann ein Sicherheitsgewinn, wenn es im Kalender steht und der Bot rechtzeitig vorher warnt.

Rotation und Notfallplan bei einem Leak.

Rotation heißt: Schlüssel regelmäßig durch neue ersetzen, damit ein unbemerkt abgeflossener Schlüssel nur begrenzt nutzbar ist. Kraken und OpenAI bieten dafür Ablaufdaten an. In der Binance-Hilfe zur Schlüsselerstellung ist kein Ablaufdatum beschrieben, dort hilft eine feste Erinnerung. Der Wechsel ohne Unterbrechung: neuen Schlüssel mit identischen Rechten und IP-Sperre anlegen, auf dem Server hinterlegen, Bot neu starten, eine Leseabfrage prüfen und erst dann den alten Schlüssel löschen.

Der Notfallplan gehört auf eine Seite, bevor er gebraucht wird. Eine sinnvolle Reihenfolge, wenn ein Schlüssel in einem öffentlichen Repository, einem Chat oder auf einem fremden Rechner aufgetaucht ist:

1. Sperren: Schlüssel sofort in der Weboberfläche der Börse oder des Anbieters löschen. OWASP nennt den sofortigen Widerruf als ersten Schritt.
2. Lage prüfen: offene Orders, Positionen, Auszahlungshistorie und Kontoaktivität kontrollieren. Bei unbekannten Orders den Bot stoppen und offene Orders stornieren.
3. Ersetzen: neuen Schlüssel mit minimalen Rechten und IP-Sperre anlegen und nur auf dem Server hinterlegen.
4. Ursache finden: Repository, Backup, Log-Datei, KI-Werkzeug oder Laptop? Ohne Ursache wiederholt sich das Leak.
5. Aufräumen: Schlüssel aus Dateien, Logs und Git-Verlauf entfernen. Das ersetzt den Widerruf nicht, denn eine einmal veröffentlichte Kopie lässt sich nicht zurückholen.
6. Dokumentieren: Zeitpunkt, Umfang, Maßnahmen. In Unternehmen kann ein solcher Vorfall interne Meldewege oder weitere Pflichten berühren; das im Einzelfall mit Anwalt oder Datenschutzbeauftragten klären.

Bei Verdacht auf einen kompromittierten Server reicht ein neuer Schlüssel nicht. Sitzt der Angreifer auf dem VPS, befindet er sich hinter Ihrer IP-Sperre und kann auch den neuen Schlüssel lesen. Dann wird der Server neu aufgesetzt, bevor wieder ein Live-Schlüssel darauf landet.

Grenzen und Risiken: was die Checkliste nicht verhindert.

Die Maßnahmen oben senken das Risiko deutlich, beseitigen es aber nicht. Diese Grenzen sollten Sie kennen:

• Das Handelsrecht bleibt ein Risiko: Auch ohne Auszahlungsrecht kann ein Angreifer mit einem Handelsschlüssel Kapital vernichten, etwa durch absichtlich ungünstige Orders in illiquiden Märkten. Die IP-Sperre senkt dieses Risiko stark, schließt es aber nicht aus.
• Kompromittierter Server: Die IP-Sperre schützt gegen fremde Rechner, nicht gegen einen Angreifer auf Ihrem eigenen.
• Konto statt Schlüssel: Wer Ihr Börsenkonto per Phishing übernimmt, legt sich eigene Schlüssel an. Zwei-Faktor-Authentifizierung und eine eigene E-Mail-Adresse nur für das Börsenkonto gehören deshalb zur Absicherung.
• KI-Agenten mit Börsenzugang: Bekommt ein Agent selbst Zugriff auf die Börse, kommen Risiken wie Prompt Injection hinzu, also untergeschobene Anweisungen in Daten. Welche Rechte und Bestätigungen Börsen dafür vorsehen, beschreibt der Artikel Krypto-Börsen für KI-Agenten.
• Anbieter ändern Regeln: Rechte, Schlüsseltypen und Limits verschieben sich. Prüfen Sie Ihre Einstellungen nach Ankündigungen der Börse erneut.
• Kein Schutz vor Marktrisiken: Gute Schlüsselverwaltung verhindert Missbrauch, nicht Verluste durch die Strategie selbst, durch Hebel oder durch Marktbewegungen. Ein Totalverlust des eingesetzten Kapitals bleibt möglich.

Checkliste: was Sie jetzt konkret tun können.

Die meisten Punkte lassen sich für einen bestehenden Bot ohne Änderung am Handelscode erledigen. Arbeiten Sie die Liste der Reihe nach ab:

1. Alle aktiven API-Schlüssel bei Börsen, Brokern und KI-Anbietern auflisten; unbekannte oder ungenutzte löschen.
2. Bei jedem Bot-Schlüssel prüfen: Auszahlung aus, nur die tatsächlich gehandelten Märkte freigeschaltet.
3. IP-Sperre auf die feste Adresse des Servers setzen.
4. Für Reporting und Dashboards eigene Nur-Lesen-Schlüssel anlegen.
5. Bei Neuanlage Ed25519 wählen, wo die Börse es anbietet.
6. Schlüssel aus Code, Repository und Konfigurationsdateien im Projektordner entfernen; einen Secret-Scanner als Pre-Commit-Hook einrichten.
7. Für OpenAI: eigenes Projekt je Bot, Service-Account-Schlüssel mit so wenig Rechten wie möglich, Ablaufdatum und hartes Ausgabenlimit.
8. Rotationstermine in den Kalender eintragen und den Notfallplan einmal durchspielen, einschließlich Sperren und Ersetzen eines Schlüssels.

Wer ein bestehendes System prüfen oder einen Bot von Grund auf sauber aufsetzen lassen möchte, findet unter Trading-Automatisierung den Rahmen, in dem ich solche Systeme für private Trader und Unternehmen entwickle.

Häufige Fragen.

Braucht ein Trading-Bot Auszahlungsrechte auf seinem API-Key?

Nein. Ein Bot liest Kontostände und platziert Orders, Geld abheben muss er nicht. Das Auszahlungsrecht sollte auf einem Bot-Schlüssel deshalb immer deaktiviert sein. Kraken schreibt in seiner Dokumentation ausdrücklich, dass ein Schlüssel für Orders kein Auszahlungsrecht braucht. Binance verlangt für das Auszahlungsrecht zwingend eine IP-Beschränkung. Auszahlungen erledigen Sie besser manuell über die Weboberfläche mit Zwei-Faktor-Bestätigung.

Was tun, wenn mein API-Key auf GitHub gelandet ist?

Zuerst den Schlüssel bei der Börse oder dem Anbieter sofort löschen, erst danach aufräumen. Dann offene Orders, Positionen und Auszahlungshistorie prüfen, einen neuen Schlüssel mit minimalen Rechten und IP-Sperre anlegen und die Ursache klären. Das Entfernen aus dem Git-Verlauf ist sinnvoll, ersetzt aber das Sperren nicht, weil eine veröffentlichte Kopie bereits kopiert worden sein kann.

Kann ich die IP-Sperre auch mit einem normalen Internetanschluss nutzen?

Nur eingeschränkt. Viele private Anschlüsse bekommen regelmäßig eine neue öffentliche IP-Adresse, dann funktioniert der Schlüssel nach dem Wechsel nicht mehr, bis Sie die Freigabe anpassen. Für Bots mit Handelsrechten ist ein Server mit fester IP-Adresse, etwa ein VPS, die zuverlässigere Lösung. Bei Binance lassen sich von der Börse erzeugte Schlüssel ohne IP-Beschränkung ohnehin nur auf Lesen setzen.

Kann man für OpenAI-API-Keys ein Ablaufdatum setzen?

Ja. Seit 10.09.2026 können Sie beim Anlegen eines Projektschlüssels ein Ablaufdatum setzen. Admins können zusätzlich eine maximale Lebensdauer für Organisation oder Projekt vorgeben. Seit 15.09.2026 lässt sich außerdem festlegen, dass nur Service-Account-Schlüssel erstellt werden dürfen oder gar keine neuen Schlüssel. Planen Sie die Erneuerung ein, damit der Bot nicht unerwartet ohne Modellzugang dasteht.

Ist ein Ed25519-Schlüssel sicherer als ein HMAC-Schlüssel?

In einem wichtigen Punkt ja: Bei Ed25519 erzeugen Sie das Schlüsselpaar selbst und hinterlegen bei der Börse nur den öffentlichen Teil, der private Schlüssel verlässt Ihren Server nicht. Binance empfiehlt Ed25519 als leistungsfähigste und sicherste Variante. Liegt der private Schlüssel aber ungeschützt auf dem Server, ist er genauso gefährdet wie ein HMAC-Secret. Rechte und IP-Sperre bleiben deshalb entscheidend.

Quellen und Stand.

• How to Create API Keys on Binance — Binance
• Request security (Spot API) — Binance Developers
• API key permissions — Kraken
• How to create a spot API key — Kraken Support
• Spot REST Authentication — Kraken
• Secrets Management Cheat Sheet — OWASP
• API Changelog — OpenAI
• Rate limits — OpenAI
• Production best practices — OpenAI
• Manage service accounts with Terraform — OpenAI

Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen Ihren Trading-Bot mit klaren Rechten und sauberem Server-Setup betreiben? Unverbindlich anfragen — wir gehen Schlüsselrechte, Ablage auf dem Server und Ihren Notfallablauf gemeinsam durch. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.