Thank you for all the responses and feedback. Sandboxing does indeed seem like a major project, but there’s also a lot to gain.
To clarify our use case: We are developing a platform based on Apache Camel. It's basically a UI where people can build integrations themselves. Camel provides many components and patterns as standard, but there will always be cases that aren't covered. To address this, we traditionally provide support for JavaScript and Groovy (originally Java 8), using the SecurityManager for sandboxing. At a certain point, the JavaScript engine Rhino was deprecated/removed from Java, and we advised all our users to use Groovy instead. The original intention was that users would develop a few Groovy scripts, but many people found it useful, especially developers who would rather write code than routes. So instead of the expected few dozen Groovy scripts, there are now thousands (around 30,000 different scripts). When we moved to JDK21, we encountered the issue that the Java Security Manager had been deprecated and would be fully removed in JDK24. Meanwhile, Camel started supporting JavaScript again through GraalJS, so we may offer it again. However, almost all users now use Groovy, are happy with it, and want to stick with it. This is even more the case because, with the advent of AI, more and more scripts are being generated by users and agents. With all this, sandboxing has become increasingly important. We checked and saw that the Jenkins team had previously encountered similar issues and created a library for them. However, as their GitHub page says, that library is deprecated, so we are currently using the following fork: https://github.com/craftercms/groovy-sandbox This library however isn't really a sandbox, but works more with intecepton, than really with isolation. Though you can use blacklisting/whitelisting approaches, but those are not long term solutions. I think better solutions have already been proposed here. To add to this information, Gilles Duboscq, researcher at Oracle writese: "For JVM languages there is Espresso <https://www.graalvm.org/latest/reference-manual/espresso/> which is a Truffle implementation of the JVM. Sandboxing it presents some challenges though, especially around native code: by default espresso uses the standard java and native code of OpenJDK for its standard library. To truly sandbox espresso, this native should either itself be sandboxed or not used as all and Truffle APIs used instead. We did some experiments in that direction already though, with a "no-native" mode that can already run some simple workloads. Combining this with Polyglot Isolates could be a path forward for using this sandboxing with JVM languages." All of our Groovy are dynamically run, so we use JIT, but native is also something to consider. Raymond On Mon, Aug 3, 2026 at 8:22 AM Paolo Di Tommaso <[email protected]> wrote: > Jochen point made me think it could be possible (at least in principle) to > run Groovy on Truffle, and therefore Graal + Sandboxing via Espresso > (Java-on-Truffle) > <https://www.graalvm.org/latest/reference-manual/espresso>. > > Espresso is a full JVM implemented as a Truffle language, so it runs > arbitrary JVM bytecode as guest code — which means the Truffle sandbox > policies apply to it. Since Groovy compiles to bytecode, you can compile > the script on the host and then load and run that bytecode inside an > Espresso Context, configured with HostAccess.NONE, IOAccess.NONE, no > threads, etc. That gives you the file/socket/env restrictions you're after. > > Two caveats worth knowing: > > - The strong guarantees (isolated heap, CPU/memory limits, the > ISOLATED/UNTRUSTED sandbox policies) require Oracle GraalVM and the > truffle-enterprise artifact — they're not in Community Edition, which only > gives you host-access control. > - Espresso is still officially experimental (~2–3× slower than > HotSpot), and Groovy leans heavily on invokedynamic, reflection, and > runtime class generation, so expect some compatibility rough edges. > > > > Paolo > > On Mon, Aug 3, 2026 at 2:51 AM Jochen Theodorou <[email protected]> wrote: > >> Hi >> >> just to be clear... we are not talking about AI creating scripts to help >> the AI analyze your code. We are talking about AI generated script for >> specific tasks, that are then executed through some script engine? >> >> I think for the first case we could find a solution that works, for the >> second it is more difficult actually. And that is where Pauls Email >> comes into play. >> >> Did I think about making a Truffle Version of Groovy before? Sure. Never >> saw how though. It would be similar to Graal executing Java code. >> >> Did I ever think of a GVM, yes, that too... but never in combination >> with security. I mean such a GVM would be a modified JVM, because why >> reinvent the wheel, even if the bytecode would be different, the JVM >> base would probably be the same. And then the question is why we can >> that way implement security, that is not wanted in that way for the JVM? >> Which I think is kind of deciding of if it is worth to start such a >> project even. And I currently have no answer to that. >> >> So Graal or GVM would maybe work for this. I personally never had the >> time to properly explore the idea. And never thought about it with that >> motivation as focus >> >> bye Jochen >> >> On 8/1/26 23:34, ski n wrote: >> > Groovy has always been a powerful scripting language. Now with agents >> > (for example created with Spring AI or Langchain4j) it's becoming >> > more common to run Groovy scripts from for example Java or Kotlin. >> > >> > The question is when third-party generated scripts from agents (or just >> > a script written by other developers) >> > run these scripts, how to run it safely and securely? For example by >> not >> > giving it access to the file system, socket or environment. >> > >> > I recently read the documentation of GraalVM on sandboxing: >> > >> > https://www.graalvm.org/latest/security-guide/sandboxing/ <https:// >> > www.graalvm.org/latest/security-guide/sandboxing/> >> > >> > There you can have guest code (JavaScript, Python, Wasm etc) that is a >> > sandbox when started from the JVM/GraalVM. This works because guest >> > languages >> > run in a separate VM, truffle VM, where these restriction policies can >> > be applied. >> > >> > Groovy as being a JVM language itself, runs natively on the JVM, and is >> > very much integrated with other JVM languages such as Java. >> Historically >> > there have been several approaches to run Groovy restrictly such as: >> > >> > SecureASTCustomizer >> > custom classloaders >> > SecurityManager (now removed from Java) >> > bytecode rewriting >> > custom compilation restrictions >> > >> > Unfortunately, after the removal of the Java Security Manager, there is >> > no robust, built-in JVM mechanism for securely sandboxing arbitrary >> > Groovy code. >> > >> > Are there any plans to allow strong sandboxing for Groovy embedded in >> > another JVM Language? >> > >> > Raymond >> >>
