ApplicationUser check works in AbstractWebCondition, fails in HttpServlet. Why?

I have been struggling with this one for a few hours now and can’t see any reason for this to be the case.

In my add-on I have a simple class extending AbstractWebCondition, with a shouldDisplay method that looks like this:

public boolean shouldDisplay(ApplicationUser applicationUser, JiraHelper jiraHelper)  {
  return applicationUser != null && ComponentAccessor.getUserUtil().getJiraAdministrators().contains(applicationUser);
}

It appears to work properly, hiding and showing add-on menu items based on the user being a Jira Administrator.

But then in the servlets that these links point do, I have a similar check in the doGet method:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
  ApplicationUser loggedInUser = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser();
  if (loggedInUser == null) {
    // Redirect to login
  } else if (!ComponentAccessor.getUserUtil().getJiraAdministrators().contains(loggedInUser)) {
    // Show permission denied
  }
  // Render servlet velocity template
}

And for some reason this is executing the "Show permission denied" block, even though it appears to be doing the exact same check as the AbstractWebCondition. I’ve added debug code and the ApplicationUser object appears to be the same in both classes. I’m at a loss. Why would this be happening? The only thing I can think of is that ApplicationUser in AbstractWebCondition has some subtle difference from the return value of ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser() in HttpServlet, though I have been unable to determine what that might be. Jira Server 7.8.1 and 7.10.0 are both doing it, and it is not happening for all users in the group. Basically the AbstractWebCondition check always works as expected, but the HttpServlet check only works properly for most users.