Currently embargoes are implemented by applying XACML policies to objects restricting access to all but administrators and the object's owner. The permission "can embargo any object" provided by the module has the description "User can add or remove embargo on any object in repository", but this is not the case since any role granted this permission is unable to access the object due to the user-centric XACML policy.
FSU has several staff at the graduate school who need to be able to manage embargoes independently on ETDs. We created a low-power "embargo_admin" role with just these permissions, but even with the proper permissions assigned they were still unable to access items with an object-level embargo.
I have submitted a pull request with the code we added to the module at FLVC. It does a check for all all roles with the "can embargo any object" permission and adds that role to the XACML policy. This does not work retroactively though, so objects embargoed under the old code will need to have the embargo lifted and reapplied for the roles to get access.