...
A managed resource could be said to be protected by the AM (in that a 401 with AM info is now in place no matter what), and it is prepared to be selectively sharable, governed by which policy ultimately gets attached to it.
The public-private continuum: There are useful things an AM can offer in managing a resource, ranging from the "public" end – access tokens could be issued to all comers, but the user could track, monitor, audit, and observe analytics of access in various ways (see, e.g., the null scenario) – to the "hidden" end – either the user might not have mapped a policy to particular resource at all, so that access tokens are always denied to all comers, or the user might have mapped a very draconian policy to the resource so that it turns out no one is worthy of getting an access token.
It should be noted that AMs could offer user preference settings that allow for policies to be mapped to registered resources in some default pattern so that there are no resources that remain unmapped. Also, to the extent that a host does not need to resort to outsourcing token validation at the AM, and to the extent that an access token is long-lived, the AM is not exposed to every single successful access of a managed resource and so its analytics and audit logs might be more coarse-grained; perhaps this is amenable to an AM user preference setting too.