Why jGuard?
The Java Security Manager was deprecated in JDK 17 and removed in JDK 24. jGuard provides capability-based security for the modern JVM.
No Ambient Authority
Code cannot implicitly access sensitive resources. All operations require explicit capabilities—no hidden permissions, no surprises.
Modules as Principals
JPMS module identity serves as the root of trust. Packages provide fine-grained refinement for precise security boundaries.
Deny by Default
Operations fail unless capabilities are explicitly granted. Security is opt-in, not opt-out—the safest default posture.
Deterministic Policy
Security policies compile to auditable metadata suitable for human review. Know exactly what your code can and cannot do.
Multiple Execution Modes
Run in STRICT mode for production, PERMISSIVE for development, or AUDIT mode to log violations without blocking—fit your workflow.
Production Ready
Comprehensive enforcement, JPMS integration, CLI toolset with thejguardc compiler and jguard inspector.
Override Policies at Deployment
Restrict overly permissive libraries without rebuilding. Denials always win.
// Embedded in library JAR - overly permissive
security module com.vendor.library {
entitle module to network.outbound;
entitle module to native.load;
entitle module to fs.read(data, "**");
}
// External override - restrict at deployment
security module com.vendor.library {
deny module to network.outbound;
deny module to native.load;
// fs.read(data, "**") remains allowed
}
Protect Against Legacy Libraries
Apply least-privilege to third-party JARs that don't ship with jGuard policies.
// Secure legacy libraries without jGuard support
security module legacy.untrusted.library {
// Grant only what the library needs
entitle module to fs.read(config, "*.properties");
entitle module to system.property.read("java.version");
// Everything else denied by default:
// - No network access
// - No thread creation
// - No native code
}
Use Cases
jGuard is designed for JVM applications that need to execute untrusted code safely.