With version 9, Java has been given the new module system Jigsaw. Major goals were to simplify maintainability of the JDK and improve its security by encapsulating modules’ internal types. While the module system successfully limits the visibility of internal types, it does not prevent sensitive data from escaping. Since the module system reasons about types only, objects are allowed to escape even if that module declares the type as internal. Finding such unintended escapes is important, as they may violate a module’s integrity and confidentiality, but is a complex task as it requires one to reason about pointers and type hierarchy. We thus present ModGuard, a novel static analysis based on Doop which complements the Java module system with an analysis to automatically identify instances that escape their declaring module. Along with ModGuard we contribute a complete formal definition of a module’s entrypoints, i.e., the method implementations that a module actually allows other modules to directly invoke. We further make available a novel micro-benchmark suite Mic9Bench to show the effectiveness but also current shortcomings of ModGuard, and to enable comparative studies in the future. Finally, we describe a case study that we conducted using Apache Tomcat, which shows that a migration of applications towards Jigsaw modules does not prevent sensitive instances from escaping, yet also shows that ModGuard is an effective aid in identifying integrity and confidentiality violations of sensitive instances.