Du betreibst einen Champagnerbrunnen im Garten. Jeder Gast darf sich einmal bedienen. Ein Dieb schließt heimlich einen Schlauch an und zapft den ganzen Tag Liter ab, um den Champagner weiterzuverkaufen. Deine Rechnung am Monatsende? Zehntausende Euro. Genau das passiert mit KI-Endpunkten, die für die Öffentlichkeit oder Kunden freigeschaltet sind. Nur kommt der Champagner hier aus den teuren Berechnungen großer Sprachmodelle. Der Dieb heißt Inference Theft – der unbefugte Diebstahl von KI-Inferenz, zur eigenen Nutzung oder zum gewinnbringenden Weiterverkauf.
Der Begriff klingt technisch, ist aber ein wirtschaftliches Problem. Eine HTTP-Anfrage kostet Bruchteile eines Cents – Vercel gibt einen Richtwert von etwa zwei Dollar pro Million Anfragen an. Ein einziger Prompt an ein modernes KI-Modell wie Claude oder GPT kann locker zwei Dollar verschlingen. Das ist eine Million Mal teurer. Genau deshalb ist Inference Theft ein profitables Geschäftsfeld für Angreifer. Sie zahlen nichts für die Rechenleistung, sondern klauen sie und verkaufen sie zu einem Spottpreis weiter.
Wie Inference Theft funktioniert
Der Angriff ist einfach und raffiniert. Du stellst einen KI-Chatbot oder eine API bereit, die einem Benutzer die Kontrolle über ein großes Sprachmodell gibt. Das kann ein öffentliches Playground sein, ein Support-Bot oder ein Dokumentationsassistent. Der Angreifer nimmt deine API und verpackt sie in einen Adapter. Das ist ein kleines Stück Software, das deine API-Schnittstelle in das Format eines großen Anbieters wie OpenAI oder Anthropic übersetzt. Sobald der Adapter läuft, kann jeder Coding-Agent oder SDK, der für die Schnittstelle von OpenAI geschrieben wurde, deine teure Inferenz nutzen – ohne dass du etwas merkst.
Der Angreifer ruft deine API nicht direkt von seiner IP auf. Er mietet tausende Residential-Proxy-IPs, also IP-Adressen von echten Privatgeräten, über die er die Anfragen streut. Deine IP-basierten Ratenbegrenzungen greifen dann nicht, weil jede Anfrage aus einer anderen Ecke der Welt kommt. Wenn du eine Authentifizierung verlangst, legt der Angreifer tausende Wegwerf-Konten an. Der Aufwand lohnt sich, weil der Gewinn pro gestohlener Anfrage enorm ist.
Selbst wenn du denkst, dein System sei sicher, weil die System-Prompts serverseitig festgelegt sind – Angreifer haben gelernt, Modelle mit geringem Aufwand um feste Anweisungen herumzumanövrieren. Das senkt die Qualität der gestohlenen Antworten kaum, und der Weiterverkauf bleibt profitabel. Besonders gefährlich sind offene KI-Playgrounds, bei denen der Aufrufer maximale Kontrolle über Prompt, Modell und Parameter hat. Aber auch Support-Bots sind nicht immun.
Warum klassische Websicherheit nicht hilft
Du denkst vielleicht: „Ich habe doch Rate Limits und einen Log-in. Reicht das nicht?“ Leider nein. Diese Mechanismen wurden für Angriffe mit niedrigeren Kosten pro Aufruf entwickelt. Damals, als Diebstahl von Rechenleistung kaum profitabel war, haben Angreifer nicht Unmengen in Residential-Proxys und Fake-Konten investiert. Heute ist der Hebel riesig: Ein Angreifer kann dir mit einem einzigen Adapter und ein paar Dollar Infrastruktur Kosten von mehreren Zehntausend Dollar pro Tag verursachen. Die Anschaffung von tausend IPs ist billig.
Das Problem liegt in der Architektur: Die meisten Sicherheitsgates prüfen die Identität eines Nutzers nur beim Einloggen oder zu Beginn einer Sitzung. Einmal eingeloggt, wird jede weitere Anfrage dieser Sitzung vertraut. Genau das nutzen Angreifer. Sie umgehen das Session-Gate einmal – durch ein gestohlenes Token oder ein Fake-Konto – und können dann tausende Anfragen durchschleusen, ohne erneut geprüft zu werden. Die Kosten für die Umgehung amortisieren sich über die vielen gestohlenen Aufrufe. Du brauchst eine Verteidigung, die jeden einzelnen API-Aufruf überprüft, nicht nur den Start der Sitzung.
Der Trick: Du musst die Überprüfung so günstig machen, dass sie für dich kaum ins Gewicht fällt, aber für den Angreifer so teuer, dass sich das Umgehen nicht lohnt. Teure Inferenz (dein Champagner) steht gegen billige Verifikation (deine Wache). Wenn die Wache jeden Schluck prüft, wird der Dieb müde.
Ein realer Angriff auf Vercel
Ein gutes Beispiel liefert Vercel selbst. Im April 2026 beobachteten die Ingenieure einen plötzlichen Traffic-Anstieg auf ihrem KI-Dokumentations-Chatbot. Die Anfragen auf das Modell Claude Haiku 4.5 stiegen auf etwa das Zehnfache des Normalvolumens – bis zu 1.300 Anfragen pro Minute. Das hätte, wäre der Angriff nicht gestoppt worden, zu Inferenzkosten von über zehntausend Dollar pro Tag geführt. Die Angreifer nutzten Residential-Proxys, sodass IP-basierte Rate Limits nichts ausrichten konnten. Über zwei Tage hinweg schickten sie Hunderttausende von Bot-Anfragen.
Vercel setzte daraufhin eine tiefgehende Analyse namens BotID ein, die innerhalb des Routen-Handlers vor jeder KI-Anfrage läuft. Innerhalb von Minuten wurden mehr als zehntausend Bot-Anfragen erkannt und blockiert. Nach 24 Stunden war der Traffic wieder normal. Der Schlüssel: Die Verifikation geschah für jeden einzelnen Request, nicht nur zu Sitzungsbeginn.
So implementierst du Request-Verifikation mit BotID
Was genau ist BotID? Es ist eine unsichtbare CAPTCHA-Technologie, die auf clientseitigem maschinellem Lernen basiert. Der Benutzer muss kein Bildrätsel lösen – das Verfahren läuft im Hintergrund und unterscheidet Menschen von Bots, ohne die User Experience zu beeinträchtigen. Dadurch kann es auf jedem Request ausgeführt werden, ohne zu nerven.
Die Implementierung erledigst du mit wenigen Zeilen Code. Zuerst deklarierst du auf der Client-Seite, welcher Endpunkt geschützt werden soll:
// instrumentation.client.ts
import { initBotId } from 'botid/client/core';
initBotId({
protect: [{ path: '/api/ai-chat', method: 'POST' }],
});
Auf der Server-Seite rufst du dann in deinem Routen-Handler checkBotId() auf. Ist das Ergebnis ein Bot, lehnst du die Anfrage mit einem 403-Status ab:
// app/api/ai-chat/route.ts
import { checkBotId } from 'botid/server';
import { NextRequest, NextResponse } from 'next/server';
export async function POST(request: NextRequest) {
const verification = await checkBotId();
if (verification.isBot) {
return NextResponse.json({ error: 'Zugriff verweigert' }, { status: 403 });
}
// Dein bestehender KI-Aufruf
}
Wichtig: Der Client muss die Pfade korrekt deklarieren, sonst fehlen die Challenge-Header, und checkBotId() schlägt fehl. Die vollständige Einrichtung mit dem next.config.ts-Wrapper findest du in der BotID-Dokumentation.
Warum jeder Request einzeln geschützt werden muss
Der entscheidende Punkt ist die Kostenasymmetrie. Ein Angreifer hat einmalige Kosten für den Bau des Adapters und die Beschaffung der Proxys. Danach ist jeder gestohlene API-Aufruf für ihn praktisch kostenlos. Wenn du nur das Session-Gate prüfst, bezahlt er die Umgehung einmal und erntet tausende Aufrufe. Wenn du aber bei jedem Aufruf eine günstige Prüfung durchführst, muss er für jeden Diebstahl erneut eine Hürde nehmen. Die günstige Prüfung (z. B. BotID) kostet dich weniger als ein Zehntausendstel eines Cents – verglichen mit den zwei Dollar für die Inferenz ein Schnäppchen. Selbst wenn der Bypass für einen Angreifer fünf Cent kostet, lohnt sich das nicht mehr, wenn er pro Aufruf nur zwei Dollar spart, aber fünf Cent zahlen muss – bei tausend Aufrufen wären das fünfzig Euro, die er vorstrecken müsste. Und wenn die Erfolgsquote nicht 100 % ist, erst recht nicht.
Was das für deine KI-Endpunkte bedeutet
Inference wird auf absehbare Zeit um Größenordnungen teurer sein als die Anfragen, die sie transportieren. Das Geschäftsmodell der Angreifer bleibt profitabel, solange es ungeschützte oder schlecht geschützte Endpunkte gibt. Du solltest sofort prüfen, welche deiner KI-APIs im Internet erreichbar sind. Priorisiere nach Angriffswahrscheinlichkeit: Je mehr Kontrolle der Aufrufer über den Prompt hat, desto leichter ist das Ziel. Ein öffentlicher Playground ist akut gefährdet; ein Support-Bot mit festem System-Prompt ist weniger exponiert, aber nicht immun.
Der zweite Schritt: Implementiere eine Verifikation, die auf jedem Request läuft. Rate Limits allein reichen nicht, Authentifizierung allein auch nicht. Eine Kombination aus unsichtbarem CAPTCHA (wie BotID) und serverseitiger Prüfung stellt sicher, dass nur echte Menschen deine teuren Ressourcen verbrauchen. Der Aufwand ist gering, der Schutz massiv.
Und zu guter Letzt: Vergiss nicht, dass auch Systeme, die hinter einem Login stehen, verwundbar sind – wenn der Login einmal umgangen wurde, fließt der Champagner ungehindert. Mach das Tor nicht nur am Eingang zu, sondern prüfe jeden Schluck.
Quelle: vercel.com
