See WFLY-8377 and JBEAP-9597 for details about WildFly integration test failures (linked).
I've looked into this issue and found that Envers uses reflection at run time to obtain constructors, getters, and setters. The helper that is used to obtain these is org.hibernate.internal.util.ReflectHelper which is loaded in the Hibernate ClassLoader. By debugging, I can see that the security check fails because the ReflectHelper ClassLoader is not the TCCL.
Most, if not all, of these constructors, getters, and setters are already stashed in Hibernate tuplizers at deployment time. We can avoid most, hopefully all, of the security exceptions by changing Envers to use the Hibernate tuplizers instead of reflection at run time.
If there are any security exceptions that are left after making these changes, we will look into adding privileged blocks.