The right place to start is definitely a deep study of the Java SecurityManager because it came the closest to what seems to be needed here, and yet failed. One

The right place to start is definitely a deep study of the Java SecurityManager because it came the closest to what seems to be needed here, and yet failed. One reason it was hard to use is that many permissions transitively implied others without that being obvious. For example, you said you want an annotation that lets you drop filesystem access or sockets. But that's not enough, is it? - Loading native code = granting all permissions - Access to the unsafe package = granting all permissions - Many syscalls that write data to user buffers = granting all permissions - Being able to run a sub-process = granting all permissions So you need at minimum to exclude all of those too. But then you also have: - Tampering with global state of any kind e.g. the default HTTP server can be mutated by anything in Go (I think?). If you can modify the logging system to write to a new location you might be able to use that to escape the sandbox. - Deserialization of objects can be a sandbox escape. And then what about the threat model? If you can cause every process including your library to segfault simultaneously, then that's a DoS attack on a company that can be profitably used for extortion. Are DoS-driven extortions in-scope or out? This is why System.exit is a permission in the SecurityManager. And so on. The large number of ways you can accidentally configure an exploitable set of permissions is huge, and because nobody seems to care much, there was no tooling to help avoid such misconfigurations.