There’s no concept of a sandbox per se, however, an Auth0 tenant can be considered a sandbox. Using different tenants to represent different environments is also the current recommendation as mentioned at (https://auth0.com/docs/dev-lifecycle/setting-up-env) so if you have a development and staging environments you should use a different tenant other than the one used for production.
If your production tenant has a subscription that qualifies for it you can even have a tenant set as a child tenant (https://auth0.com/docs/dev-lifecycle/child-tenants#child-tenant-policy) which would allow you to use the same set of features as the production one as both could be seen as sharing the subscription.
Now the above is the general advice for how to go about setting up and using development and staging tenants. However, in your question there’s something a bit more specific than that as you’re looking to perform automated tests. With regards to that although I don’t believe you are in that situation it’s important to note that performance/load testing is only available for certain subscription and needs to be requested first (https://auth0.com/docs/policies/load-testing).
In your situation I believe you’re only looking at automating tests so the above load testing policy would not apply, but it’s still important to note that depending on the frequency those automated tests may be perceived as load tests and more importantly you will likely also want to consider NOT testing code that you are not responsible for in your automated tests.
In other words, in general, your automated tests should mock services and API’s for which you are not responsible. This would likely reduce the effort needed to write the tests and may also improve there performance.