This is so important that I've devoted an entire section to it. In short your pages generated by page_manager will be available to all comers, so this screen is a set of restriction rules that define who can get to these pages and who can not. From an administrative stand point it is especially important to pay attention to these settings as all the core context_admin plugins have been stripped of their various extra checks to provide administrators the greatest leverage possible. This is not an issue within Drupal core since we know for sure that every menu item is protected by some sort of permission or access callback, however within the confines of context_admin we must be diligent and set these access controls for ourself.

The most obvious solution is to choose the same permission that this form would correspond to within core. This has its uses, but is ultimately rather limiting in that the user has access to those items anyway, so all we've really done is relocate administration for that user. That's a big win all around, but we can do much more. For example, we might not want a user to have the ability to "administer taxonomy" but we would like for them to be able to manage the "Products and Services" vocabulary. Drupal core doesn't really have a way of segregating these vocabularies, but with context_admin we can build an administration for the "Products and Services" vocabulary, and then give a particular role, or even a single uid access to those menu items via page_manager's access handlers.

As a practical example, when we create new modules for use on our customer's system, we often times simply give the "webmaster" role access to the various administrative menu tabs we utilize. This allows us to lock the client out of the "administrative" sections of drupal entirely, and locate all the administrative tasks in easy to find sections, with only the various capabilities we want them to have. This cuts down on customer confusion and results in the best administrative experience for both the customer (webmaster) and the site admin (user 1).