Currently, the following versions are being supported with security updates.

If you discover a security vulnerability within this project, please send an e-mail to the maintainers at security@micro-state-space.example.com (placeholder for actual contact). We take all security vulnerabilities seriously and will respond to all reports within 48 hours.

Please include the following in your report:

• Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
• Full paths of file(s) where the vulnerability is located
• A proof of concept (PoC) or instructions to reproduce the issue
• Any potential impact or exploit scenarios

Do not open a public issue for a security vulnerability.

As a research-focused repository built on Streamlit that allows users to upload serialized agent files, Micro-State-Space carries specific security considerations that deployers and contributors must be aware of.

The environments support downloading and uploading AI agents in a ZIP format containing JSON state tables (agent1.json, agent2.json, config.json).

Threats:

• Zip Bombs (Decompression Bomb): Maliciously crafted ZIP files designed to exhaust disk space or memory during decompression.
  • Mitigation: The application currently relies on the standard zipfile module. Deployers in public environments should enforce file size limits via Streamlit configurations (server.maxUploadSize) and implement strict decompression limits to abort if the decompressed size exceeds a safe threshold (e.g., 50MB).
• Malicious JSON Injection / DoS: Extremely deeply nested JSON files could cause a stack overflow during parsing, or massive JSON files could lead to out-of-memory (OOM) errors.
  • Mitigation: State space limits restrict valid configurations. Parsers should limit recursion depth and enforce strict schema validation for loaded tables before applying them to agent instances.

The agents rely on Monte Carlo Tree Search (MCTS) and Negamax with Alpha-Beta pruning. The depth and simulation counts are user-configurable via the UI.

Threats:

• Computational Exhaustion: A user setting MCTS simulations to extremely high values (e.g., 1,000,000) or Minimax depths beyond reasonable limits (e.g., > 16) will block the Streamlit server thread and exhaust CPU resources, potentially crashing the instance.
  • Mitigation: The application imposes hard caps on sliders (e.g., maximum depth of 16, maximum simulations of 1000). Deployments should monitor CPU usage and consider running the application behind a rate-limiting reverse proxy.

The repository is built on Streamlit, which is inherently designed for rapid prototyping rather than hardened production deployment.

Threats:

• Concurrent State Modification: Streamlit's st.session_state is unique per user session, but heavy concurrent usage could expose thread-safety issues in underlying libraries if global states were inadvertently used.
• Open Ports and Unencrypted Traffic: By default, Streamlit runs on HTTP over port 8501.
  • Mitigation: In production, this application must be deployed behind a secure reverse proxy (like Nginx or Traefik) that terminates TLS (HTTPS) and implements appropriate firewall rules.

Threats:

• Remote Code Execution (RCE): The current implementation uses pure JSON for state serialization and avoids insecure deserialization mechanisms like Python's pickle.
  • Mitigation: Never switch agent serialization to pickle or eval(). Always use json.loads and strictly map loaded values to expected types.

This repository is primarily for academic and research purposes. If you plan to host these Streamlit apps publicly, it is your responsibility to secure the deployment environment (e.g., using Docker, setting resource limits, and using a reverse proxy).