Clarify that cf-runagent --remote-bundles requires explicit bundle re…

…source_type access promises

Ticket: ENT-11987
Changelog: none

reference/components/cf-runagent.markdown

@@ -8,11 +8,16 @@ keywords: [runagent]
 
 `cf-runagent` connects to a list of running instances of
 `cf-serverd`. It allows foregoing the usual `cf-execd` schedule to activate `cf-agent`.
-Additionally, a user may send [classes][Classes and decisions] to be defined
+A user may send [classes][Classes and decisions] to be defined
 on the remote host. Two kinds of classes may be sent: classes to decide on
 which hosts `cf-agent` will be started, and classes that the user requests
 `cf-agent` should define on execution. The latter type is regulated by
 `cf-serverd`'s [role based access control][roles].
+Additionally a user may send a list of [bundles][Bundles] to activate on the remote host
+with the `--remote-bundles` argument.
+This argument takes one or more comma separated bundle names.
+Each of the bundles requested must be given explicit permission with an access promise
+matching the bundle names.
 
 **Notes:**
 

reference/promise-types/access.markdown

@@ -7,12 +7,12 @@ published: true
 Access promises are conditional promises made by resources living on the server.
 
 The promiser is the name of the resource affected and is interpreted to be a path, unless a
-different `resource_type` is specified. Access is then granted to hosts listed in `admit_ips`,
+different `resource_type` is specified. Access must then be granted to hosts listed in `admit_ips`,
 `admit_keys` and `admit_hostnames`, or denied using the counterparts `deny_ips`, `deny_keys`
 and `deny_hostnames`.
 
-You layer the access policy by denying all access and then allowing it
-only to selected clients, then denying to an even more restricted set.
+By default access is denied.
+As a policy writer you must specifically grant access.
 
 ```cf3
 bundle server my_access_rules()