[1]: https://docs.oracle.com/javase/8/docs/api/java/lang/Security...
[1]: https://docs.oracle.com/javase/8/docs/api/java/lang/Security...
In a system based on capabilities you would explicitly have to pass capabilities to any code which needs them (either as arguments to the call, or when loading the library – depending on what is natural). This means that priviledge is naturally minimised and transparent.
Compare that to SecurityManager where you have make a separate policy and checking process, separated from the actual calling of functions.
There was some work done to try to define a capability safe subset of Java (Joe-E was the name [0]). But it is sad that this is not the default security behaviour in Java, and thus no libraries use this.
Unfortunately, the Python VM is impossible to sandbox much further as it is. You have (internal) resource security, but can't limit access to the network, or say a specific file in the filesystem. Mutable globals everywhere.
The https://en.wikipedia.org/wiki/E_programming_language has capability security, but no resource exhaustion protection.
The only systems were both where integrated were a series of 1980s operating systems (GNOSIS, KEYKOS, https://en.wikipedia.org/wiki/KeyKOS) that were designed to allow secure and accountable multi-user timesharing on mainframes. They are predecessors of the formally verified sel4 operating system.
There has never been a similar system on an OS/Processor independent virtual machine level. For fun, I created this little VM: https://esolangs.org/wiki/RarVM