Hello everyone!
Today we would like to announce a preview release of “Script Capabilities,” a new feature designed to give you finer control over actions that scripts can perform in your experience.
What Are Script Capabilities?
The system works by transforming an instance and its children inside the Data Model into a sandboxed container. With this new container you can:
- limit access to instances outside the container,
- configure access to Luau and engine APIs,
- limit in what context the scripts are allowed to run.
This unlocks some cool functionality, including:
- Improve Security of Untrusted Code: You can now limit what models taken from the toolbox can do. More broadly, you can limit the capabilities of any user-generated content inside your experiences, even those that do contain scripts.
- Reduce Attack Vectors with In-Experience Scripting: Ensure better security for experiences that allow players to write and/or run their own code, which are often executed in a restricted environment, adding additional guardrails. For example, if your experience is a Luau teaching app that allows players to input scripts in experience, then you can add an extra layer of security when executing that code within that same experience.
- Build More Secure Libraries: Share libraries which restrict what they can do themselves. For example, a library providing more math methods can be restricted to the smallest set of capabilities it needs so that other developers using that library don’t have to validate the whole source code to make sure it doesn’t include additional actions beyond those.
Ready to Try Script Capabilities?
Enable the Beta Feature
In order to be able to configure instance properties associated with this feature, a Workspace setting has to be switched from Default to Experimental.
This setting exists to ensure that the feature is not used by accident while it is still in the Client Beta stage.
Once the Beta stage is completed and the details of the feature have been finalized, this step will no longer be required.
Note that with this beta release it is possible to use the Sandboxed instances in a published experience today! However, we might still make changes to the implementation which might not be backwards-compatible. We will announce those changes as updates in this topic.
Enable Any Container
Once the Workspace property is enabled, you will see new options on Folder, Model, Script instances and any classes derived from those:
Any of those classes can become what we call a sandboxed container.
Enabling the checkbox limits the actions that the scripts inside that container can perform and what instances they are allowed to access based on the set of values inside the Capabilities list.
Customize the Capabilities of Instances in the Container
Finally you can select the capabilities you wish to be available inside the container.
By default, scripts inside will not be allowed to run and you have to enable RunClientScript or RunServerScript capabilities.
Additionally, access to any instance outside the container will be prevented. Unless otherwise required, we recommend keeping this default isolation mode and building packages that communicate through bindable events and functions. Access to all instances can be restored by selecting AccessOutsideWrite capability, but this weakens the isolation guarantees.
Finally, capabilities for Luau and Engine APIs can be selected. If the script attempts to access something for which it doesn’t have a capability, an error message will be reported, including the information on missing capability name.
Not everything is available though! Some APIs have not been assigned a capability yet and some of the higher risk ones are not planned to be made available in a sandboxed environment (especially access to properties affecting the whole experience). For these APIs, you will see an error message mentioning an Unassigned capability. You will not find this capability in the list, but we know that a few popular APIs are still missing, so please leave a message here if you want to use the system but cannot access something specific.
As an example, you can insert a Model into an experience and only provide access to limited capabilities:
Even if the script does something malicious like fetching more scripts by asset id, it will error on an attempt to execute that:
It doesn’t matter how obfuscated the script is, even if it doesn’t look like there’s a require, DataStore access or something else in there, it will be prohibited. 
For the full description of the features along with the details on each capability and system restrictions, visit our documentation page: Script Capabilities | Documentation - Roblox Creator Hub
API Dump Changes
For those of you who’ve built tooling around or simply watch our API Dump, you can see these changes in JSON related to capabilities. More than one capability might be required to access an API.
Details
APIv1
"Members": [
{
"Capabilities": {
"Read": [
"Animation"
]
},
"Security": {
"Read": "None",
"Write": "None"
},
APIv2
"members": [
{
"name": "AccessoryType",
"readSecurity": "None",
"writeSecurity": "None",
"threadSafety": "ReadSafe",
"capabilities": [
"Avatar"
]
Important Notes
- This is a beta feature, so some adjustments may occur based on your feedback.
- We’ll be actively monitoring the use of Script Capabilities and making improvements as needed.
- Please report any issues you find or suggestions you have as comments to this post!
