I Made AI Build a Cybersecurity Mod in Minecraft

Overview / Core idea

• The creator wants to embed cybersecurity open-directory research into Minecraft as an interactive “fishbowl/game” for exploration and visualization.
• Instead of manually browsing results, they plan for a Minecraft mod where open directory entries from Hunt.io are represented in-game (e.g., files as mobs/creatures, navigation through “dimensions/worlds,” with name tags and in-world exploration).
• They tested feasibility live while an “AI” (referred to as Codex) helps build and iterate on the mod and development environment.

Key product/technology direction

Data source

• Hunt.io dashboard/API to enumerate publicly exposed open directories.
• Security-relevant hints surfaced from those directories, such as:
  • potential Cobalt Strike indicators
  • malware exposure
  • risky files (e.g., bash history/rc)

Minecraft mod metaphor

• Open directories → new dimensions/worlds
• Files → mobs/objects
• Weapons/tools → interactive game mechanics

Scope and prototype goal

• The mod’s initial goal is not full exploitation—more like a sanitized visualization prototype, focusing on:
  • “command + entities only”
  • outputs limited to sanitized summaries and chat logs

Modding/build process (major implementation details)

Minecraft mod toolchain

• They scaffolded a Minecraft modding environment using Fabric:
  • Fabric Loader
  • Fabric API
  • Fabric Loom
  • Gradle

Version alignment

• They updated versions to match current Minecraft/official metadata:
  • Upgraded to Minecraft Java 26.2
  • Updated Fabric Loader / related tooling
  • Confirmed mod builds and loads successfully in a dev client

Observability / logging

They wanted an AI-driven ability to observe:

• running processes
• logs
• world load success/failure
• safe snapshotting (referred to as “Codex observe”)

Sandbox world tooling

• They created a super flat “infinite-ish” creative sandbox for rapid experimentation.
• They hit world creation issues:
  • world save naming mismatch
  • Y-level/spawn height mismatch
• They patched sandbox logic to:
  • recognize the save/world name more flexibly
  • adjust Y-level behavior so it spawns on the expected flat surface height

Operator/permissions issue

• In-game commands initially weren’t visible/usable because allow/OP permissions weren’t effectively enabled for the player.
• They patched/adjusted operator permissions so commands and help pages worked.

Feasibility for Hunt.io integration

First-stage interaction concept

• A Minecraft command triggers a Hunt.io call and spawns in-world markers/entities (e.g., armor stands / markers were mentioned).
• A “safety scan” suggested they weren’t leaking real credentials during initial tests.

Why the full prototype stalled

A full working prototype was blocked by:

• API key orchestration
• streaming safety constraints

Key constraints discussed:

• They attempted to ensure no API keys/credentials are exposed on-stream.
• The Hunt.io API key needed to be available to the mod runtime, but it lived on a remote research host (“Omen”).
• They discussed options like:
  • SSH’ing into Omen
  • using a password manager to retrieve the Hunt.io key

Outcome:

• They achieved partial/limited functionality (“talks to Huntio a little”) rather than full behavior.

Networking architecture discussion (bungee vs velocity)

Proxy/realm model

They discussed how to handle “multiple realms/worlds”:

• BungeeCord: a proxy in front of multiple backend Minecraft servers; players move between servers as one experience.
• Recommendation: avoid early complexity and prefer Velocity (a modern proxy layer with similar goals, less legacy).

Preferred direction for the mod experience

They leaned toward:

• a home/lobby instance (e.g., local 127.0.0.1)
• separate backend worlds per open-directory dataset (potentially each driven by Hunt.io results)
• proxy-based switching to change contexts without constantly restarting the client

What the creator actually achieved in this episode

• ✅ Built and updated a working Fabric 26.2 modding environment
• ✅ Created a functioning super flat creative sandbox
• ✅ Added/validated an observability layer via logs/snapshots (“Codex observe”)
• ✅ Implemented early “command → Hunt.io fetch → spawn entities/markers” concept
• ❌ Full Hunt.io-backed open directory exploration wasn’t completed due to:
  • API key missing at runtime on the mod host
  • the need for secure cross-machine orchestration without exposing secrets live

Main speakers / sources

• John (the creator / narrator)
  • Explains the goal and constraints (e.g., “no secrets/API keys on stream”)
  • Repeatedly says “Hear me out”
• Codex (the AI/dev agent)
  • Assists with Minecraft mod setup, patches, and commands
  • Provides environment verification, log/observability actions, and planning
• Chat participants
  • Offered suggestions like:
    • Minecraft version updates
    • super flat world generation tips
    • permission troubleshooting