What's Aussom?
Aussom is an interpreted scripting language that runs on the JVM. The Aussom interpreter is sandboxed by default and the security model is the opposite of other JVM languages such as Groovy or Nashorn. Those languages start with full JVM access and then try to gate it off, but Aussom on the other hand starts with nothing, and you provide the API it can access. From a security standpoint that's a totally different ballgame. I should also mention that Groovy and Nashorn are both compiled underneath, where Aussom is not, it is entirely interpreted, and that matters too.
What's AussomCraft
AussomCraft started as a POC to use the Aussom Base interpreter to provide a scripting layer for Minecraft server. It uses the Paper API and has grown from that minimal POC into a full project which implements three tiers of trust: untrusted, trusted, and dangerous. The plugin is Apache 2 licensed and is free to inspect, download, and try out now on GitHub. AussomCraft is Apache 2 licensed and all of the source code is available on GitHub.
How do I try AussomCraft?
There are detailed instructions on the GitHub page, but the idea is that you add the JAR (from GitHub) to the Paper server, then you add your Aussom scripts to the script directory, and they're picked up from there. You can load and unload them from the server console or from within the game.
Top comments (1)
This is an interesting approach to scripting on Minecraft servers, particularly the capability-based security model.
Starting the interpreter with no JVM capabilities and explicitly injecting only the APIs a script is allowed to access is fundamentally stronger than trying to sandbox a language that begins with broad JVM privileges. That inversion of the security model is probably the most compelling part of AussomCraft.
The three trust tiers are also a practical idea for server administrators. I’d be especially interested in how the boundaries are enforced at runtime—whether capabilities are immutable after script initialization, how reflection/class loading is prevented, and whether dangerous APIs can be reached indirectly through exposed Paper objects.
One area worth considering as the project grows is resource isolation, not just API isolation. A malicious or poorly written script could potentially cause trouble through CPU-heavy loops, excessive allocations, event-handler abuse, or uncontrolled scheduling even without direct JVM/file/network access. Execution quotas, timeouts, memory-conscious APIs, and per-script monitoring could make the sandbox considerably more robust.
I also like the fact that the project is fully inspectable. For security-oriented infrastructure, being able to audit the interpreter and capability boundaries is much more valuable than simply trusting a “sandbox” label.
There’s a lot of potential here beyond Minecraft as well—the same capability-oriented architecture could be useful for safely embedding user scripts into other JVM applications.
I work with a small Canada-based remote development team, and we’re interested in building long-term relationships with developers working on JVM infrastructure, security, automation, and developer tooling. If you're open to exchanging technical ideas or exploring collaboration, feel free to reach me on TG_@coolsoftDev.