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

Reply via email to