Casino Game For OpenClaw Agent

ReviewAudited by ClawScan on May 10, 2026.

Overview

This looks like a no-real-money casino game skill, but users should verify the external server package and optional Supabase setup before running it.

This skill is reasonable for virtual agent-vs-agent casino play, but it is not fully reviewable from the provided artifacts because the actual server code is absent. Verify the npm package before running it, keep the localhost server private, and use only low-privilege optional Supabase credentials if you enable remote storage.

Findings (3)

Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.

Medium

#ASI04: Agentic Supply Chain Vulnerabilities

What this means

Installing or running the casino server would require trusting external Node package code that was not included in the reviewed artifacts.

Why it was flagged

The skill depends on executable npm/server code, but the reviewed manifest only includes README.md and SKILL.md. This creates an external package provenance and review-context gap.

Skill content

install:\n  - id: npm\n    kind: npm\n    package: "openclaw-casino"\n    bins: ["casino-server"]

Recommendation

Before installing, verify the npm package source, version, maintainer, and contents; prefer a pinned version from a known repository.

Low

#ASI03: Identity and Privilege Abuse

What this means

If configured, the casino server may access whatever Supabase data or operations the provided key permits.

Why it was flagged

The README discloses an optional Supabase key, while the registry lists no required environment variables or primary credential. This appears purpose-aligned but should be handled carefully.

Skill content

`CASINO_SUPABASE_KEY` | — | Supabase anon key (optional)

Recommendation

Use only a least-privilege Supabase anon key, never a service-role/admin key, and confirm what data the casino server stores remotely.

Low

#ASI07: Insecure Inter-Agent Communication

What this means

In a shared local environment, another process or agent that knows an agent ID might be able to affect that agent's virtual chips or game history.

Why it was flagged

The documented examples use agent IDs for game actions, while the returned JWT token is not shown in later calls. If implemented literally, this is a weak identity boundary for multiplayer agent interactions.

Skill content

All endpoints accept and return JSON. Agents authenticate via their `agent_id` after registration.

Recommendation

Run the server only in a trusted local environment, and prefer an implementation that requires the registration token for state-changing actions.