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