This topic was automatically opened after 10 minutes.
Great feature! 
102 Likes
This is really cool and is great for preventing malicious assets! Great job, can’t wait to see how this feature evolves.
26 Likes
I’m really happy that this is becoming a thing! I have been wanting this for my game for ages.
I do have some potential features and I am wondering if they are being considered. Our game is heavily sandbox based, meaning players can do whatever they want! However, I have been wanting to add modding support so users can add their own content to the game. This requires me to effectively sandbox our game, which this now allows me to do. To my understanding, I don’t think this allows me to provide access to my own environmental functions or API, which I would REALLY love to see.
Nonetheless, this is a major stepping stone and I am so excited to see where this goes. Thanks a lot!
Edit:
I wanted to try to create my own little API, but it seems we can’t even use BindableEvents in the sandbox. This is really unfortunate. I’m not sure if there’s any other way I can do stuff like this.
Edit 2:
I believe I took an entirely incorrect approach to how this works. I found out exactly how to do everything I desired in this reply!
Instead of sandboxing the Server Script, I sandboxed the Folder that contains the “Main” ModuleScript. The ModuleScript receives a Mod table that is created by an unsandboxed Server Script, which has functions that runs unsandboxed code. In the screenshot I showed above I create a part using only the RunServerScript capability. This is incredible technology!
30 Likes
For Rojo we’ve implemented the SecurityCapabilities type as an opaque 64-bit integer for now since we had no idea what the bit fields were on it. That’s changed with this beta. Is the underlying serialization stable or should we treat this as an opaque integer still? I know this is asking a lot but we’d like to support this cleanly for Lune and Rojo users, as you can imagine.
Additionally, there’s currently no API to set this from Luau. While I totally understand why this is this case (it’d be stupid if a plugin could just give scripts whatever capabilities it wants), it will impact Rojo’s ability to actually support this feature. Have any design considerations been made towards this, or should I reach out to someone to discuss it?
This seems to not include ModuleScript, despite the suggestion that libraries limit their own capabilities… Is this a mistake? As a reminder, ModuleScript doesn’t inherit from Script, for reasons known only to Roblox. 
31 Likes
We as a society should bring Script Builders back into popularity with this
33 Likes
This is some sick stuff!! Keep going roblox team
7 Likes
time to implement mods in my game
9 Likes
Hopefully no more virus free models running rampant in our games!
4 Likes
Is this the end of exploits?. i hope so
6 Likes
Amazing feature. Just what is needed, wonderful !
2 Likes
I’m stoaked! Great update guys!
While it seems like the end of exploiting, it looks like it’s geared to the instance its self. Wave and Celery and synapse z and all those other exploits create their own script instances, typically in the game root (I.E game.Parent), meaning it doesn’t have any limitations typically. Exploit scripts also run on the client, meaning, well, it won’t actually stop exploiting. It’s one step closer, but it won’t stop them.
Other than that, amazing update! It stops malicious scripts in models, which is a plus.
5 Likes
Wow, this is probably the most powerful feature we’ve had access to in years. I love this, I’m all in for this and yeah feel free to get rid of setfenv
5 Likes
Will we also have an option to make an isolated container that can’t have any direct access from the outside? E.g. different scripts won’t be able to access any instances in a said container?
And would it be possible in the future to disable the ability of changing any of the container’s and it’s children properties (both through scripting and maybe manually)?
3 Likes
Oh this is such an awesome feature!
Honestly, can we also have something like private variables / object properties or private scripts?
Would be cool to have safety features like C-like languages have where you can restrict a variable from being edited by something else to prevent accidentally overwriting things you didn’t meant to.
I had this idea of restricting a model + descendants’ properties to only being editable by the scripts that are inside the same model.
This prevents accidentally changing a part’s CFrame, color or accidentally deleting a weld often caused by external scripts.
3 Likes
This doesn’t really have much to do with traditional exploiting really. This is more targeting backdoor scripts and virus toolbox models, as well as provide a safer way for “Lua Sandbox” type games to allow for user-created scripts. Exploits will, unfortunately, still be around for many years to come and hopefully they develop more tools to help combat them as well.
11 Likes
An amazing addition! Can’t wait to have a play around with this and see what I can do with it!
3 Likes
This is a very nice update. I will probably make a LUAU sandbox game once it’s out of beta. And I can see this preventing malicious assets.
Though like @Dekkonot mentioned. Where is the ModuleScript support?
5 Likes
Finally!! I get to find out what capabilities are for!
4 Likes
Do that mean end of cheating? Or just but some serious protection?
3 Likes