Shadow Compute is the shadow use of publicly accessible AI infrastructure as a third-party computing backend. In March 2026, a fork of the popular coding tool OpenCode: ChipotlAI Max appeared on GitHub. The default model was pepper-1, the API key was burrito-2026, and the documentation promised costs of exactly $0.00. The computing power came from the fast food company Chipotle’s customer support bot.
This is not a joke about a burrito chatbot. It’s a prime example of what happens when a public corporate bot is built as if it were just a conversational interface, but functions as an open compute layer.
Shadow Compute starts as a protocol issue
The story of ChipotlAI Max doesn’t begin in March 2026, but rather it begins in 2023 with a Chevrolet dealer chatbot in Watsonville, California. Back then, users got a sales assistant to “sell” a Chevrolet for a dollar and give instructions on how to build bombs. This is the first stage, a chatbot can be converted to conversational because its system prompt is not a security limit.
The second stage is structurally more serious: Maksim Soltan examined the backend of Chipotle’s support bot “Pepper” and discovered that the bot was accessible via a public WebSocket protocol, specifically IPsoft’s Amelia platform with SockJS and STOMP. He built an OpenAI-compatible proxy called chipotle-llm-provider that ran locally on port 3000. Rob Dezendorf took this proxy, set Pepper as the default model in OpenCode and published ChipotlAI Max. The fork had 824 stars on GitHub within days, it stands at around 1300 today, at the beginning of July 2026. Chipotle patched Pepper shortly afterwards.
The difference to 2023: In stage 1, a bot is manipulated. In stage 2, the infrastructure is extracted. Protocol extraction turns a public chatbot into an API.
The model is Amelia, and that changes half the story
At this point, a precision that is missing in many reports is important. Pepper runs on IPsoft’s Amelia platform, not Claude or GPT-4o. The “free frontier inference on corporate budget” narrative is therefore half false.
Amelia is a specialized conversational AI stack optimized for customer support use cases, not a generalist, state-of-the-art Large Language Model. Anyone who used Pepper as a coding backend didn’t get Frontier quality and some ChipotlAI Max users quickly noticed that.
Nevertheless: the structural findings remain strong. The exploit works regardless of whether it is Amelia, GPT, Claude or another model. The architecture is crucial: a publicly accessible protocol, no rate limiting, no intent detection, no token budget. Once a developer extracts the backend protocol and packages it as an OpenAI-compatible proxy, the bot is an open compute surface. Which model is behind it is secondary.
And that’s exactly why the community list at the end of the ChipotlAI Max documentation is interesting: Home Depot Magic Apron, Sephora, Nordstrom Rosie, Lowes Mylow, IKEA Billie, Expedia Virtual Agent. Not all of them are Amelia, some may run on much more expensive models.
The economic dimension: 10x token multiplier
Even with a model like Amelia there is a real cost problem. Nik Kale from CoSAI, the Coalition for AI Security, describes it precisely: A normal customer interaction generates 200 to 300 tokens. Asking a bot to explain a Python function or reverse a linked list generates more than 2,000 tokens. This is a cost multiplier of approximately 10 times per session.
Sanchit Vir Gogia from Greyhound Research names the underlying architectural problem: “These systems are architected as conversational interfaces, but economically they behave as open compute surfaces.” The consequence: Even a small proportion of freeloader traffic tears a material hole in a company’s AI budget. Gogia states that as little as five percent of freeloader traffic can generate noticeable cost effects.
The phenomenon has a name: denial of wallet. It is related to classic denial-of-service attacks, but aims to financially overload a pay-as-you-go service. With a public chatbot, there is no need for a coordinated attack: it is enough if enough users use the bot infrastructure for their own purposes.
This point is unpleasant for operators because the usual key figures can be misleading. A support bot can remain accessible, show short latencies and still be misused economically. The cost curve is tipping quietly: longer answers, more context windows, more repetitions, more off-scope questions. An unusual load peak would be visible in classic web systems. With AI bots, the same effect often works as dedicated usage until the invoice or internal cost dashboard is noticed.
Shadow Compute shifts the security question from “Can someone trick the bot?” to “What resources does the bot spend if someone misuses it?” This question belongs in the operational design. With no cost limits per session, purpose checking before model invocation, and clear separation between public interface and backend protocol, every customer support bot remains a small, publicly accessible inference endpoint.
Subscribe to signal of the week
A message. An analysis. Every Friday in the newsletter.
Free as a member. Subscribe for free
Why system prompts are not a security boundary
This is the point that has remained constant from 2023 to 2026: the assumption that a system prompt limits a chatbot to its intended purpose is wrong. This is not a theoretical edge case. It is an empirically well-documented finding.
Simon Willison, probably the most quoted observer of prompt injection attacks, sums it up this way: “6,000 failed attempts provides no guarantees that someone with a more sophisticated approach couldn’t get through.” OWASP lists Prompt Injection as LLM01:2025, the most important security threat to LLM applications. The research literature shows the same trait: the arXiv paper “Design Patterns for Securing LLM Agents against Prompt Injections” classifies prompt injection defense as an architectural task. Privilege separation, capability control, separate data and command channels, and deterministic policy layers do more than just another warning sentence in the system prompt.
Kale sums it up: “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.”
The picture of the red velvet ribbon is well chosen. It separates those who belong from those who happen to walk by. But if you’re determined, you just go through it. A system prompt has no enforcement semantics, but describes a desired state, it does not force it. Anyone who sees this as security architecture has blurred the line between configuration and control.
If you want to go deeper into the mechanics of prompt injection: this article LLM guardrails are not a protective wall shows how fuzzing tests reveal where probabilistic filters fail. And LLM Jailbreaking: From DAN to Claude Fable 5 documents how the history of bot manipulation progressed from simple role-playing games to sophisticated structural attacks.
What operators need to check specifically
The Chipotle case provides three specific attack vectors that every operator of a public AI bot should test.
Symptom 1: Intention Drift. The bot answers questions that are outside of its intended purpose. Symptom: Users ask technical questions, the bot answers in detail. Test: Targeted out-of-scope queries with automatic monitoring of response length. Decision: Implement purpose gating, which rejects requests that are far off topic before they get into the inference stack.
Symptom 2: Protocol exposure. The backend protocol is publicly accessible and can be accessed without authentication. Symptom: Direct WebSocket or HTTP connections from outside the intended client context. Test: Port scan and protocol audit of the chatbot backend. Decision: Never publicly expose backend logs; Upstream API gateway with rate limiting and authentication.
Symptom 3 – No token budgeting. Long sessions run indefinitely. Symptom: Average session token number well over 500. Decision: Set hard token limits per session and per user category; Automatically cancel and flag abnormal sessions.
In addition, every public bot needs an operational question that is rarely included in the product briefing: Which request should not even reach the model? This is exactly where it is decided whether purpose gating is a real control layer or just a polite hint in the prompt.
The worst response to the Chipotle incident would be to dismiss it as a curious isolated incident. Gogia is explicit: “The problem will not disappear as models improve. It will intensify.” The more companies shift their customer communication to AI bots, the larger the aggregated compute surface that is publicly accessible becomes.
My opinion
The funny thing about ChipotlAI Max was the packaging. The serious thing is that the community list at the end of the documentation shows how quickly an isolated case becomes a practice. When protocol extraction and OpenAI-compatible proxy construction become a community craft, every poorly secured corporate chatbot is a potential third-party backend.
❓
Frequently asked questions
Is it illegal to use a corporate chatbot as a free AI backend?
According to current assessments, the CFAA (Computer Fraud and Abuse Act) risk is low because there is no hacking or password bypassing and the endpoint was publicly accessible. However, a violation of the respective provider’s terms of use is likely. No conclusive legal judgment is possible here, and the legal situation varies depending on the jurisdiction.
What is denial of wallet and how is it different from denial of service?
In a classic DoS attack, the goal is to cause a system to fail. Denial-of-Wallet targets financial overload: Attackers or unintentional freeloaders generate excessive or particularly long requests to a pay-as-you-go AI service. The system continues to run, but costs are skyrocketing. With corporate chatbots, even a small proportion of off-scope traffic is enough to noticeably put a strain on the AI budget.
Do better LLMs automatically provide better protection against prompt injection?
Newer Frontier models are more resistant to simple injection attacks. But there are no absolute guarantees, and the Chipotle case shows that the real problem often lies at the infrastructure level: exposed protocols, lack of budgeting and weak purpose testing. Model improvements do not solve architectural problems.
