Re: Groovy sandboxing

Hi

just to be clear... we are not talking about AI creating scripts to help=
=20
the AI analyze your code. We are talking about AI generated script for=20
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=20
second it is more difficult actually. And that is where Pauls Email=20
comes into play.

Did I think about making a Truffle Version of Groovy before? Sure. Never=
=20
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=20
with security. I mean such a GVM would be a modified JVM, because why=20
reinvent the wheel, even if the bytecode would be different, the JVM=20
base would probably be the same. And then the question is why we can=20
that way implement security, that is not wanted in that way for the JVM?=
=20
Which I think is kind of deciding of if it is worth to start such a=20
project even. And I currently have no answer to that.

So Graal or GVM would maybe work for this. I personally never had the=20
time to properly explore the idea. And never thought about it with that=20
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=20
> (for example created with Spring AI or Langchain4j) it's becoming
> more common to run Groovy scripts from for example Java or Kotlin.
>=20
> The question is when third-party generated scripts from agents (or just=
=20
> a script written by other developers)
> run these scripts, how to run it safely and securely? For example by not=
=20
> giving it access to the file system, socket or environment.
>=20
> I recently read the documentation of GraalVM on sandboxing:
>=20
> https://www.graalvm.org/latest/security-guide/sandboxing/ <https://=20
> www.graalvm.org/latest/security-guide/sandboxing/>
>=20
> There you can have guest code (JavaScript, Python, Wasm etc) that is a=
=20
> sandbox when started from the JVM/GraalVM. This works because guest=20
> languages
> run in a separate VM, truffle VM, where these restriction policies can=
=20
> be applied.
>=20
> Groovy as being a JVM language itself, runs natively on the JVM, and is=
=20
> very much integrated with other JVM languages such as Java. Historically=
=20
> there have been several approaches to run Groovy restrictly such as:
>=20
> SecureASTCustomizer
> custom classloaders
> SecurityManager (now removed from Java)
> bytecode rewriting
> custom compilation restrictions
>=20
> Unfortunately, after the removal of the Java Security Manager, there is=
=20
> no robust, built-in JVM mechanism for securely sandboxing arbitrary=20
> Groovy code.
>=20
> Are there any plans to allow strong sandboxing for Groovy embedded in=20
> another JVM Language?
>=20
> Raymond