I have heard it claimed (by a researcher working on a competing microkernel technique) that very little is known about how to evaluate security of systems that are extensible through managed code.
The problem is that the kinds of bugs that might cause a security hole are very different than security researchers are used to. In a traditional microkernel all the drivers and other subparts of the kernel are isolated from one another by running them in different address spaces. In a microkernel where the isolation is implemented through type checking managed code you avoid the enormous overheads of switching address spaces every time you need to use a sub-service, but the tradeoff is that now evaluating the isolation mechanism is more difficult.
Any particular part of the kernel (say a device driver) written in the managed language is safe if and only if the type checker says the driver is safe and the type checker has no bugs. So the type checker is part of the kernel core. In practice it seems that type checkers are considerably larger and more complicated than are traditional microkernel cores. That means that the attack surface is potentially larger.
I don't know whether traditional micro-kernel isolation techniques or managed-code based isolation techniques are really more or less reliable. There's a bootstrapping problem here: until managed-code isolation techniques are widely used, we're not going to know how often they are insecure. But without knowing how insecure they are, it is difficult to deploy them in situations that are security critical.