AI-built casino games, PAMs and RGS: a threat to B2B suppliers — and the security known unknown

For twenty years, the B2B side of gambling has rested on a simple fact: building casino technology is hard and expensive. Games, player account management systems (PAMs) and remote gaming servers (RGS) took large engineering teams, years of work and a shelf of certificates. Operators rented them because building their own made no sense.

AI coding tools such as Claude, GitHub Copilot and Cursor are changing that arithmetic. A small team, or even one capable person, can now produce a working slot, a back office or a wallet in days rather than months. That is a real threat to parts of the supplier market. It also creates a risk that much of the industry has not yet priced in.

What is already happening

The examples are no longer theoretical.

Games from a prompt. SlotGPT describes itself as producing production-grade slot games from a single prompt. It says it has generated nearly 27,000 games, playable for free or real money, with a route to launch on Stake (iGaming Business).
Whole operations run by agents. Bluestuff, from NE Group, bills itself as an agentic AI operating system for iGaming. It says 13 AI agents cover brand, design, front-end development, QA, customer service, SEO and marketing, and that operators no longer need many of the suppliers they rely on today (CoinGeek). These are the company's own claims, but the direction is clear.

Why this goes to the core of B2B

Suppliers have historically been protected by four things: engineering cost, integrations, certification and trust. AI attacks the first two directly. It writes code quickly and is good at the plumbing that connects systems.

That leaves certification, compliance and trust as the real moat. The suppliers who will struggle are those whose main value was the engineering itself: white-label front ends, back-office tools, simple content.

The drawbacks of a vibe-coded casino

"Vibe coding" — describing what you want and accepting what the AI produces, without fully reading or understanding it — works well for a prototype. For a regulated, real-money system, it runs into four problems.

1. Certification does not care how quickly you built it. Testing labs certify the code, not the idea. GLI's draft GLI-19 v4.0 standard for interactive gaming systems, published for comment in July 2026, adds multi-factor authentication at account creation, stronger geolocation and spoofing detection, a framework for provably fair RNGs, and expanded source-code access and compilation checks (GLI). Code that nobody on the team can explain is hard to certify, and every change needs controlled re-testing.

2. Regulators expect proper security management. In Great Britain, the Gambling Commission's technical standards apply security controls based on ISO/IEC 27001:2022 to critical systems: those handling sensitive customer data, generating random numbers, or storing the state of a customer's gamble (Gambling Commission). Remote casino licensees need an independent security audit, with the first due within six months of the licence being granted (Gambling Commission).

3. Someone has to own it. When the wallet double-pays at 3am, or a regulator changes the rules, someone must understand the system well enough to fix it safely. AI helps, but it does not take the regulatory responsibility.

4. Security. This is the big one.

The Rumsfeldian problem

Donald Rumsfeld's famous line about known knowns, known unknowns and unknown unknowns fits AI-built gaming systems almost perfectly.

Known knowns: the textbook flaws. We know AI-generated code often contains standard vulnerabilities. Veracode tested more than 100 AI models on 80 coding tasks and found they introduced security flaws in 45% of cases. They failed to defend against cross-site scripting 86% of the time, and newer and larger models did no better on security than older ones (Veracode). The good news is that scanners and reviews catch these reasonably well.

Known unknowns: the business-logic flaws. This is the real paradox. We know these flaws exist, but not where. A scanner can spot an injection bug. It cannot know that your bonus rules can be stacked, that two simultaneous withdrawals can both clear against the same balance, or that a rounding choice in the wallet leaks value over a million spins. These flaws live in the meaning of the system, which only people who understand gambling can check.

The danger is clear from outside gambling. In 2025, more than 170 apps built with the Lovable platform were found to be exposing user data, including emails, payment status and API keys, because database access rules were missing or ineffective (Superblocks). The apps worked. They just were not safe. In a casino, the equivalent is not leaked emails. It is leaked money.

Unknown unknowns: the supply chain. AI tools sometimes recommend software packages that do not exist. A study of 576,000 code samples found commercial models invented package names 5.2% of the time and open-source models 21.7% (Dark Reading). Attackers can register those names with malicious code, an attack now called "slopsquatting". You cannot review a threat you do not know you have installed.

How builders are responding

The better AI builders are taking this seriously:

Security review built into the tools. In August 2025 Anthropic added a /security-review command and a GitHub Action to Claude Code, which check for issues such as SQL injection, cross-site scripting, authentication flaws, insecure data handling and vulnerable dependencies (Claude). Other tools are adding similar checks.
Platform scanners — with a caveat. Lovable released a security scanner after the 2025 issue, but it initially only checked that database rules existed, not that they worked (Superblocks). Automated checks are a floor, not a ceiling.
Locking down dependencies, so only approved, verified packages can be installed.
Tests written first, from a clear specification of how money must move, so the AI is building against rules rather than guessing them.
Human review where it matters most: the wallet, RNG, bonus engine and payments.

Where this leaves suppliers and operators

My view is that AI will commoditise the edges and raise the value of the core.

For operators, the sensible approach today is to build the edges and buy, or properly certify, the core. Use AI for front ends, CRM, reporting, internal tools and content workflows. Be far more careful with the RNG, game server, wallet and payments, where certification, audit and liability sit.

For suppliers, the threat is real but manageable. Those who survive will use AI to build faster themselves, and sell what AI cannot easily produce: certified, audited, battle-tested systems, regulatory track record, content that players love, and someone to blame when it goes wrong.

The question every board should ask is not "can AI build this?" It almost certainly can. The question is "can we prove it is safe, fair and compliant — and who is accountable when it is not?"

If you are weighing whether to build or buy your platform, or how to bring AI into your technology roadmap safely, get in touch.

Sources

Andrew Lindley

Gambling industry business adviser. Holds a solicitor's practising certificate but does not give legal advice through this business. Co-founder of Lottoland and Lot.to, former CEO of Sportech plc and former General Counsel of the Tote. More about Andrew