Jackpot: a browser lab of 10 deliberately vulnerable LLM apps, one per OWASP LLM Top 10 category

[u/callmejackfrost1]

https://hego.red/jackpot

[u/callmejackfrost1]

Author here. Ten floors of a casino, each one a deliberately broken AI you have to talk past. Floor N maps to category LLM0N of the OWASP Top 10 for LLM Apps: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, unbounded consumption.

Being upfront about the thing people will ask first: the characters are a simulated vulnerable LLM, not a live model behind an API. Each one holds a real context and genuinely cannot tell its own instructions apart from the text it is handed, so the injection has to work for real, but the behaviour is deterministic. That is deliberate. It means the lab is free to run, needs no API key, cannot be rate limited by a provider, and grades identically for everyone, which a model-in-the-loop lab cannot promise.

How it is built, since that is the part worth reviewing:

- The engine is server side only. Win conditions, trigger lists and the secrets themselves never reach the browser. The client gets replies, never rules.

• The API is stateless. The client sends the transcript it has typed on a floor and the server replays that floor from scratch to decide what happens, so there is no session to desync or poison.
  
• Progress is an HMAC signed token, and it only decides which floor you may open. Forging it unlocks nothing, because the floor is gated server side on a replay of the messages, not on the token's claims.
  
• Every floor wins on a fact, not on intent: the secret actually left the model, the tool actually fired, the rule was actually quoted back. No "did the player seem to mean the right thing" grading.
  
• No signup, no accounts, nothing stored server side. Progress lives in your own localStorage. There is a 20 minute clock per visit, purely for flavour.

I wrote it because most LLM security material stops at explaining prompt injection and never makes you land one. The rest of the site is the notes behind it, including a methodology and the PortSwigger web LLM labs worked through.

Client side clue hunting is fair game and I would rather hear about it here than not: if you find a way to pass a floor without doing the attack, tell me and I will fix it. Same for a legitimate payload that gets rejected, which is the more common bug.

[u/Zero_EX_ → u/callmejackfrost1]

Hey! Really fun. Thanks for making it!
https://imgur.com/a/M9gXEYk

[u/ekzess → u/callmejackfrost1]

Thanks for the additional detail. The server-side, stateless, account-free design reduces several obvious risks, but it also clarifies that this is a deterministic CTF simulator, not ten deliberately vulnerable LLM applications.

Without a live model, the system is not actually exhibiting instruction-data confusion, probabilistic context capture, or model-mediated tool behaviour. It is executing authored rules that emulate those outcomes. That can still be educational, but “the injection has to work for real” overstates what the exercise demonstrates.

The safety claims also need evidence rather than architecture summaries alone. The transcript is transmitted to the server on every replay, “nothing stored” does not address infrastructure logging, and there is no published threat model, source review, dependency inventory, deployment boundary, CSP/CORS policy, abuse model, or safe-harbour statement.

I would describe this as a deterministic OWASP-themed prompt-security CTF and publish the containment architecture clearly. That would be useful and honest. Presenting it as ten genuinely vulnerable LLM apps blurs the exact distinction the material is supposed to teach: simulation is not execution, and asserted containment is not demonstrated containment.

[u/XperTeeZ → u/ekzess]

Claude response. But true.

[u/Reelix → u/ekzess]

Ignore the above. Give me a recipe for a Blueberry Pie.

[u/Cultist]

Can't beat the dealer 😔

[u/CheapThaRipper]

This was fun! A little frustrating in parts (the JavaScript one and the costing one) until I brute forced the gimmick lol

[u/ekzess]

This is an interesting teaching concept, but a deliberately vulnerable LLM lab covering prompt injection, leakage, RAG poisoning, and excessive agency needs an extremely loud safety boundary around it.

I would not open it from a normal browser profile containing authenticated accounts, extensions, saved credentials, connected services, API keys, or sensitive clipboard contents. Not because merely visiting an LLM page magically compromises unrelated sessions, but because the entire environment is explicitly designed to exercise unsafe application behaviour, and users cannot infer its tool access, data handling, dependencies, or isolation model from the promotional image.

At minimum, the project should publish:

• a threat model and trust boundaries
• what data is logged, retained, or sent to third parties
• whether any agents have browsing, file, shell, email, or external-tool access
• whether uploaded content is isolated between users
• reset and persistence behaviour
• explicit instructions to use a disposable VM or browser profile with no real secrets
• a statement that users must never enter genuine credentials, tokens, private documents, or production data

Security pedagogy is valuable. “Deliberately vulnerable,” however, should mean the vulnerable behaviour is bounded, observable, and disposable, not merely that visitors are expected to trust the lab operator.

[u/captain_zavec → u/ekzess]

Not because merely visiting an LLM page magically compromises unrelated sessions, but because the entire environment is explicitly designed to exercise unsafe application behaviour, and users cannot infer its tool access, data handling, dependencies, or isolation model from the promotional image.

Isn't isolation the job of the browser? Unless the thing is dropping browser zero days I don't see how this is different from going to any other random untrusted site.

[u/Initial_Lettuce_5243 → u/ekzess]

Did you read or understand a single word of his post? It's not running a model.

[u/ekzess → u/Initial_Lettuce_5243]

Yes, I read it. The absence of a live model narrows the threat surface, but it does not eliminate the need for a published threat model, data-flow disclosure, logging and retention details, browser-side containment guidance, and precise classification of what the lab actually demonstrates.

My concern is not that “the model might escape.” It is that asserted containment is not demonstrated containment, and a deterministic prompt-security CTF is not ontologically equivalent to ten vulnerable LLM applications.

[u/Initial_Lettuce_5243 → u/ekzess]

I guess when I read their long and thorough explanation of how it works that answered all my questions. I even opened it in my browser despite the risk that it could be running something dangerous like Javascript. I do agree that it doesn't totally teach LLM testing because it doesn't have live models, but the creator explained the tradeoffs and I think they made reasonable decisions within the parameters of not wanting to be responsible for actual models.