Shadow Compute: Wenn Supportbots zu KI-Coding-Backends werden

Shadow Compute ist die Schattennutzung öffentlich erreichbarer KI-Infrastruktur als fremdes Rechen-Backend. Im März 2026 erschien auf GitHub ein Fork des populären Coding-Tools OpenCode: ChipotlAI Max. Das Default-Modell lautete pepper-1, der API-Key war burrito-2026, die Dokumentation versprach Kosten von exakt 0.00 Dollar. Die Rechenleistung kam aus dem Kundensupport-Bot des Fast-Food-Konzerns Chipotle.

Das ist kein Witz über einen Burrito-Chatbot. Es ist ein Musterbeispiel dafür, was passiert, wenn ein öffentlicher Corporate-Bot so gebaut wird, als wäre er nur eine Konversationsoberfläche, dabei aber als offener Compute-Layer funktioniert.

Shadow Compute beginnt als Protokollproblem

Die Geschichte von ChipotlAI Max beginnt nicht im März 2026, sondern sie beginnt 2023 mit einem Chevrolet-Händler-Chatbot in Watsonville, Kalifornien. Damals brachten Nutzer einen Verkaufs-Assistenten dazu, einen Chevrolet für einen Dollar zu "verkaufen" und Anweisungen zum Bau von Bomben zu geben. Das ist erste Stufe, Ein Chatbot lässt sich konversationell umfunktionieren, weil sein System-Prompt keine Sicherheitsgrenze ist.

Die zweite Stufe ist strukturell schwerwiegender: Maksim Soltan untersuchte das Backend von Chipotles Supportbot "Pepper" und entdeckte, dass der Bot über ein öffentliches WebSocket-Protokoll ansprechbar war, konkret über IPsofts Amelia-Plattform mit SockJS und STOMP. Er baute einen OpenAI-compatible Proxy namens chipotle-llm-provider, der lokal auf Port 3000 lief. Rob Dezendorf nahm diesen Proxy, setzte Pepper als Default-Modell in OpenCode und veröffentlichte ChipotlAI Max. Der Fork hatte innerhalb von Tagen 824 Sterne auf GitHub, er steht heute, Anfang Juli 2026 bei ca. 1300. Chipotle patchte Pepper kurz danach.

Der Unterschied zu 2023: In Stufe 1 wird ein Bot manipuliert. In Stufe 2 wird die Infrastruktur extrahiert. Die Protokoll-Extraktion macht aus einem öffentlichen Chatbot eine API.

Das Modell ist Amelia, und das ändert die Geschichte halb

An diesem Punkt ist eine Präzision wichtig, die in vielen Berichten fehlt. Pepper läuft auf IPsofts Amelia-Plattform, nicht auf Claude oder GPT-4o. Die Erzählung "kostenlose Frontier-Inferenz auf Unternehmensbudget" ist daher halb falsch.

Amelia ist ein spezialisierter konversationeller KI-Stack, der für Kundensupport-Anwendungsfälle optimiert ist, kein generalistisches Large Language Model der neuesten Generation. Wer Pepper als Coding-Backend nutzte, bekam keine Frontier-Qualität und das haben manche ChipotlAI-Max-Nutzer schnell gemerkt.

Trotzdem: Der strukturelle Befund bleibt stark. Der Exploit funktioniert unabhängig davon, ob dahinter Amelia, GPT, Claude oder ein anderes Modell steckt. Entscheidend ist die Architektur: Ein öffentlich erreichbares Protokoll, kein Rate-Limiting, keine Absichtserkennung, kein Token-Budget. Sobald ein Entwickler das Backend-Protokoll extrahiert und als OpenAI-compatible Proxy verpackt, ist der Bot eine offene Compute-Oberfläche. Welches Modell dahinter läuft, ist dann sekundär.

Und genau deshalb ist die Community-Liste am Ende der ChipotlAI-Max-Dokumentation interessant: Home Depot Magic Apron, Sephora, Nordstrom Rosie, Lowes Mylow, IKEA Billie, Expedia Virtual Agent. Nicht alle davon sind Amelia, einige dürften auf wesentlich teureren Modellen laufen.

Die ökonomische Dimension: 10x Tokenmultiplikator

Selbst bei einem Modell wie Amelia entsteht ein echtes Kostenproblem. Nik Kale von CoSAI, der Koalition für KI-Sicherheit, beschreibt es präzise: Eine normale Kundeninteraktion erzeugt 200 bis 300 Tokens. Wer einen Bot bittet, eine Python-Funktion zu erklären oder eine Linked List umzukehren, erzeugt mehr als 2000 Tokens. Das ist ein Kostenmultiplikator von ungefähr Faktor 10 pro Session.

Sanchit Vir Gogia von Greyhound Research benennt das dahinterliegende Architekturproblem: "These systems are architected as conversational interfaces, but economically they behave as open compute surfaces." Die Konsequenz: Schon ein kleiner Anteil von Freeloader-Traffic reisst ein materielles Loch in das KI-Budget eines Unternehmens. Gogia nennt dabei als Grössenordnung, dass bereits fünf Prozent Freeloader-Traffic spürbare Kosteneffekte erzeugen können.

Das Phänomen hat einen Namen: Denial-of-Wallet. Es ist verwandt mit klassischen Denial-of-Service-Angriffen, zielt aber auf die finanzielle Überlastung eines Pay-as-you-go-Services. Bei einem öffentlichen Chatbot braucht es dafür keine koordinierte Attacke: Es reicht, wenn genug Nutzer die Bot-Infrastruktur für eigene Zwecke nutzen.

Für Betreiber ist dieser Punkt unangenehm, weil die üblichen Kennzahlen täuschen können. Ein Supportbot kann erreichbar bleiben, kurze Latenzen zeigen und trotzdem wirtschaftlich missbraucht werden. Die Kostenkurve kippt leise: längere Antworten, mehr Kontextfenster, mehr Wiederholungen, mehr Off-Scope-Fragen. In klassischen Websystemen wäre eine ungewöhnliche Lastspitze sichtbar. Bei KI-Bots wirkt derselbe Effekt oft wie engagierte Nutzung, bis die Rechnung oder das interne Cost-Dashboard auffällt.

Shadow Compute verschiebt damit die Sicherheitsfrage von "Kann jemand den Bot austricksen?" zu "Welche Ressourcen gibt der Bot aus, wenn jemand ihn zweckentfremdet?" Diese Frage gehört in das Betriebsdesign. Ohne Kostenlimits pro Session, Zweckprüfung vor dem Modellaufruf und klare Trennung zwischen öffentlicher Oberfläche und Backend-Protokoll bleibt jeder Kundensupport-Bot ein kleiner, öffentlich erreichbarer Inferenz-Endpunkt.

Warum System-Prompts keine Sicherheitsgrenze sind

Das ist der Punkt, der von 2023 bis 2026 konstant geblieben ist: Die Annahme, dass ein System-Prompt einen Chatbot auf seinen vorgesehenen Zweck beschränkt, ist falsch. Das ist kein theoretischer Randfall. Es ist ein empirisch gut dokumentierter Befund.

Simon Willison, der wohl meistzitierte Beobachter von Prompt-Injection-Angriffen, fasst es so zusammen: "6,000 failed attempts provides no guarantees that someone with a more sophisticated approach couldn't get through." OWASP listet Prompt Injection als LLM01:2025, die wichtigste Sicherheitsbedrohung für LLM-Applikationen überhaupt. Die Forschungsliteratur zeigt denselben Zug: Das arXiv-Paper "Design Patterns for Securing LLM Agents against Prompt Injections" ordnet Prompt-Injection-Abwehr als Architekturaufgabe ein. Privilege Separation, Capability Control, getrennte Daten- und Befehlskanäle sowie deterministische Policy-Schichten leisten mehr als ein weiterer Warnsatz im System-Prompt.

Kale bringt es auf den Punkt: "These chatbots have a system prompt that says something like 'You are a helpful customer service agent.' That's a suggestion, not an enforcement mechanism. It's the AI equivalent of a velvet rope."

Das Bild vom roten Samtband ist gut gewählt. Es trennt, wer dazugehört, von dem, der zufällig vorbeiläuft. Wer aber entschlossen ist, geht einfach drunter durch. Ein System-Prompt hat keine Enforcement-Semantik, sondern beschreibt einen Wunschzustand, er erzwingt ihn nicht. Wer das als Sicherheitsarchitektur betrachtet, hat die Grenze zwischen Konfiguration und Kontrolle verwischt.

Wer tiefer in die Mechanik von Prompt Injection einsteigen will: der Artikel LLM-Guardrails sind kein Schutzwall zeigt, wie Fuzzing-Tests aufdecken, wo probabilistische Filter versagen. Und LLM-Jailbreaking: Von DAN bis Claude Fable 5 dokumentiert, wie die Geschichte der Bot-Manipulation von einfachen Rollenspielen bis zu ausgefeilten strukturellen Angriffen verlief.

Was Betreiber konkret prüfen müssen

Der Chipotle-Fall gibt drei konkrete Angriffsvektoren, die jeder Betreiber eines öffentlichen KI-Bots testen sollte.

Symptom 1: Absichtsdrift. Der Bot beantwortet Fragen, die ausserhalb seines vorgesehenen Zwecks liegen. Symptom: Nutzer stellen technische Fragen, der Bot antwortet ausführlich. Test: Gezielte Out-of-Scope-Queries mit automatischem Monitoring der Antwortlänge. Entscheidung: Purpose-Gating implementieren, das thematisch weit ausserhalb liegende Anfragen ablehnt, bevor sie in den Inferenz-Stack gelangen.

Symptom 2: Protokollexposition. Das Backend-Protokoll ist öffentlich erreichbar und ohne Authentifizierung aufrufbar. Symptom: Direkte WebSocket- oder HTTP-Verbindungen von ausserhalb des vorgesehenen Client-Kontexts. Test: Port-Scan und Protokoll-Audit des Chatbot-Backends. Entscheidung: Backend-Protokolle nie öffentlich exponieren; API-Gateway mit Rate-Limiting und Authentifizierung vorschalten.

Symptom 3 - Keine Token-Budgetierung. Lange Sessions laufen unbegrenzt. Symptom: Durchschnittliche Session-Tokenzahl deutlich über 500. Entscheidung: Harte Token-Limits pro Session und pro Nutzerkategorie einziehen; anomale Sessions automatisch abbrechen und flaggen.

Zusätzlich braucht jeder öffentliche Bot eine Betriebsfrage, die selten im Produktbriefing steht: Welche Anfrage darf gar nicht erst bis zum Modell gelangen? Genau dort entscheidet sich, ob Purpose-Gating eine echte Kontrollschicht ist oder nur ein höflicher Hinweis im Prompt.

Die schlechteste Reaktion auf den Chipotle-Vorfall wäre, ihn als kuriosen Einzelfall abzutun. Gogia ist explizit: "The problem will not disappear as models improve. It will intensify." Je mehr Unternehmen ihre Kundenkommunikation auf KI-Bots verlagern, desto grösser wird die aggregierte Compute-Oberfläche, die öffentlich erreichbar ist.