At first I put this method in myself, but then I decided against it.  An `ApiUser` is a wrapper of an application "user" and a human user, where the human user may not be set in the case of app-to-app communication.  In this latter case, an `ApiUser` isn't really "known" (signed in) or anonymous, but rather just unspecified.  This line of thought led me to write an `UnspecifiedUser` that was a peer to `AnonymousUser`, but that didn't end up being that useful.

In the end, I just decided to have two methods in `ApiUser`: `is_human?` and `is_application?`.  These tell us if the underlying user is a human or an application.  Once we know an `ApiUser` is a human, we can ask the question `is_anonymous?` (a.k.a. `is_not_signed_in?`).  

This branching based on `is_human?` is reflected in the newer `AccessPolicy` stuff that I'm about to PR.

You added this `is_anonymous?` method here to handle `CredentialsController#me`'s authorization check.  If we keep this controller around, we can replace that call with

    AccessPolicy.require_action_allowed!(:me, current_user, current_user)

The first `current_user` is the requestor of the action, the second is the resource to which access is being requested.  Just funny in this case because this is the "me" method.