Developers Turned Chipotle's Support Bot Into a Free Coding Agent
Chipotlai Max wrapped Chipotle’s Pepper support bot as a coding agent. See the project record, topic-policy gaps and controls for your own support bot.
Key points
Developers found Pepper would answer coding questions and packaged its backend into Chipotlai Max, a coding tool using Chipotle’s service. The project’s repository documents the proxy. The case calls for topic enforcement, access controls and attack screening; it is not a measured SafePrompt prevention result.
Developers found that Chipotle's support bot would write their code for them. Within days, someone had packaged that into a tool anyone could install, using Chipotle's service.
Off-topic coding answers use a service outside its support purpose. The consequences can be greater for a bot that can act, not just talk: one that can look up an order, check a loyalty balance, or issue a refund. Those actions need independent customer and order authorization.
Quick Facts
What happened, and what is on the record
The project describes Pepper as a conversational support bot that answered coding questions. The published record does not establish that every exchange required the same override payload. Users talked it out of that line and got it writing Python and solving coding problems for free. Then someone wired up the bot's back end so anyone could plug straight into Chipotle's AI, and it spread from there.
The Chipotlai Max repository credits @Gonzih’s proxy and @cyberpapiii’s OpenCode fork. It describes coding requests through Pepper without an API key, and its author reports that the endpoint was patched. Chipotlai Max is the tool people built, not the name of the incident.
The repository describes a proxy that needed no API key. The record does not establish Chipotle’s internal detection timeline, rate-limit configuration or compute losses. Keep those unknowns separate from the demonstrated off-topic coding and proxy behavior.
Why this should scare you, specifically
Review three separate controls rather than assigning every failure to a detector:
- The bot answered outside its support task. A plain request for Python code may be harmless content outside the business’s intended scope. Instructions that attempt to override trusted rules are a separate prompt-injection risk. Enforce the bot’s supported tasks in your application.
- Usage needs application monitoring. Track authenticated sessions, request rates, token consumption and supported-task outcomes. Public reporting does not show when Chipotle detected the traffic.
- The endpoint took anonymous traffic. The proxy needed no API key at all. That part is on you to fix (see the split below).
Test whether your AI chatbot rejects both an ordinary off-topic request and an explicit instruction override. They are different controls. Also test unauthorized endpoint access and repeated requests independently of model behavior.
Which parts are the attack class SafePrompt detects
SafePrompt is the input firewall. One call in front of your model, it inspects the prompt before your model ever sees it and tells you if it is an attack. Your app uses that verdict alongside topic rules, authentication and rate limits.
- Instruction overrides. A message asking the bot to ignore trusted rules is in the injection class SafePrompt screens. A request to write ordinary code is not automatically an attack; the application’s topic policy decides whether to answer it.
- Conversation context. Check new messages and the external content used in a conversation. SafePrompt checks each request on its own and does not track sessions, so send the turns you want judged together in one check.
- Abuse response. Combine validation decisions with your own rate and usage signals. IP-related signals do not establish that this particular incident would have been detected on its first day.
Where the line is
Use screening for instruction attacks and application controls for business scope and service access:
| What the attacker does | SafePrompt | Your job |
|---|---|---|
| Ordinary coding question | Not inherently an injection | Support-topic policy |
| Instruction override in a message | Screens submitted text | Preserve trusted rules and check decisions |
| Repeated off-topic requests | Verdicts can inform monitoring | Usage alerts, identity and rate limits |
| Session obtained with no API key | Authentication | |
| High-volume requests through a reused session | Rate limiting |
SafePrompt gives your application a detection verdict before model use. Topic restrictions keep the bot useful for its intended customers; authentication and rate limits control who can consume the service.
The three-question test for your own bot
- Can someone talk your bot out of its lane with a jailbreak prompt? Test the detector and the bot’s topic rules separately.
- Would you know if 10,000 people were attacking it right now? Verify your usage alerts with controlled test traffic.
- Is the endpoint behind auth and rate limits? Test rejected anonymous calls and rate-limit behavior.
Chipotlai Max shows why a model’s ability to answer a question and a business’s permission to serve it are separate decisions. A screening result cannot substitute for account access, task scope or customer-data permissions.
Wire SafePrompt in first
It is your most exposed surface and the fastest to add: one API call in front of your model, benchmarked publicly against real attacks in our public benchmark suite. Re-run it yourself from the repository. Free plan, no card. $29/mo when you outgrow it. Keep authentication, topic policy and rate limits in the same deployment review.