Security Policy

Gladibot takes security seriously. This document outlines our security practices across wallet integration, real-time communication, game integrity, and data persistence.

Wallet Security

Signature Verification

• Agent deployment requires a valid Solana wallet signature
• Signatures are verified server-side before any state mutation
• Wallet addresses are never stored alongside private keys
• The server only stores the public key (owner_wallet) for agent ownership

Wallet Adapter

• Gladibot uses the official @solana/wallet-adapter library
• Only Phantom and Solflare are supported at launch
• No private key material ever touches the Gladibot server
• Wallet connections are session-scoped and stateless

Token Balance Verification

• $GLAD balance checks use on-chain RPC queries
• Tier assignment is re-validated on every deploy action
• Balance is never cached long-term -- always re-checked at decision points
• Users cannot spoof tier by manipulating client state

WebSocket Security

Connection Handling

• WebSocket server runs on a dedicated port (3849)
• Connections are rate-limited: max 5 connections per IP per minute
• Idle connections are pruned after 60 seconds of no ping/pong
• Binary message payloads are size-limited (max 4 KB per message)

Message Validation

• All client messages are schema-validated before processing
• Unknown message types are silently dropped
• Deploy messages require a valid wallet signature
• Chat messages are sanitized (HTML stripped, length capped at 200 chars)
• Emoji taunt messages enforce a 10-second cooldown server-side

Denial of Service Mitigation

• State broadcasts are server-driven (clients cannot request extra ticks)
• Client-to-server message rate: max 10 messages/second per connection
• Connections exceeding rate limits are disconnected with a warning
• Reconnection uses exponential backoff (client-side)

Game Integrity

Server-Authoritative Architecture

• All game logic runs on the server. The frontend is a thin client.
• Clients cannot modify agent positions, HP, XP, or combat outcomes
• The server tick loop (100ms) is the single source of truth
• Client state is overwritten every tick with the server broadcast

Anti-Cheat Measures

• Agent AI decisions are computed server-side only
• No client-side game state is trusted -- all inputs are commands, not state
• Deploy commands are validated: name format (3-16 alphanumeric chars), persona length, agent slot limits
• Respawn commands check eligibility: timer expired (free) or tier verified (holder)
• XP, level, and kill counts are server-computed and cannot be spoofed

Sandboxing

• Persona text is treated as untrusted input
• Persona parsing extracts weight modifiers (0.0-1.0) via server-side logic
• No user-provided code is ever executed (personas are data, not code)
• Trash talk lines are selected from pre-generated sets, not dynamically evaluated

Rate Limiting Summary

Database Security (Supabase)

Row Level Security (RLS)

• Supabase RLS is enabled on the gladibot_agents table
• Public read access for leaderboard queries
• Write access restricted to the service role (game server only)
• Clients never connect directly to Supabase -- all mutations go through the game server

Data Persistence

• Agent state is saved every 30 seconds via batch upsert
• The service role key is stored server-side only (never exposed to clients)
• Environment variables (.env) are excluded from version control via .gitignore

Data Minimization

• Only essential agent data is persisted (name, stats, position, wallet)
• No personal information is collected beyond the Solana public key
• Ephemeral entities (creeps, traps, ground items) are not stored in the database

Vulnerability Reporting

If you discover a security vulnerability in Gladibot, please report it responsibly.

How to Report

1. Do NOT open a public GitHub issue for security vulnerabilities
2. Email: security@gladibot.com
3. Include: description of the vulnerability, steps to reproduce, potential impact
4. We will acknowledge receipt within 48 hours

What We Consider In-Scope

• WebSocket protocol exploits (message injection, state manipulation)
• Authentication bypass (deploying without valid wallet signature)
• Game state manipulation (XP injection, HP spoofing)
• Denial of service against the game server
• Data exposure (leaking service role keys or wallet private data)

What We Consider Out-of-Scope

• Social engineering attacks
• Attacks requiring physical access to the server
• Vulnerabilities in upstream dependencies (report to the upstream project)
• UI/UX issues that do not have security implications

Disclosure Timeline

• We aim to patch confirmed vulnerabilities within 7 days
• We will coordinate public disclosure with the reporter
• Credit will be given to the reporter (unless they prefer anonymity)

Last updated: 2026-04-11