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 (5)
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.
Thanks Kane, you nailed it. The inversion of the security model is key, and that's from the base Aussom-Lang interpreter which is a dependency in AussomCraft. It's a maven artifact which out of the box has very little in the way of standard library. You provide the connectivity it needs and it's stronger than it sounds. Code from within Aussom can't directly call Java functions. Not only is there a whitelist to limit which objects are reachable but the functions also have to match a specific function signature, so you can't call arbitrary Java code, it must be wrapped first.
In AussomCraft, there currently isn't support directly for handling CPU heavy loops or excessive allocations, but those tools already exist in Aussom (the maven artifact), so it's just a matter of adding the mechanisms in AussomCraft to use what already exists.
I recently published an article on Foojay on this exact topic: Scripting in small apps: you don’t need a container for a macro. Thanks for your interest!
I would like to get to know you better. Would you please contact me? t_g_@coolsoftDev
I’m happy to chat. Please message me on Bluesky, the link is at the bottom of the page at aussom-lang.com. Thanks!
I just wanna contact with you via TG.
Would you please contact me? t_g_@CRDT_CTO