Notes from Marco Cecchi on framework commonalities:

The four LHC experiments (and not only them) have independently either developed or integrated pilot frameworks basically with the following intents:

1) implement late binding, that in turn fixes these two issues:
1a) frustrating attempts to deal with black-hole worker nodes and the inefficiencies of the Information System, part of the standard grid middleware stack
1b) enable priority throttling
2) overcome the failures of the early versions of the middleware itself
3) manage 'high-level workflows' from their users and have direct control on how their are translated into grid jobs
4) implement a centralized workload management system to better optimize the traffic generated by 3)

In particular, support for late-binding is lacking in the present grid middleware (this does not mean it cannot be done) which is now implemented using the classic one-way, push-mode submission model the present grid middleware provides (either sending pilots directly to the CEs or through a grid submission layer that abstracts the CEs) and an extra encapsulation (the pilot itself). This is not problematic, can eventually be optimized by creating stream requests, but both sites and VOs are happy with this.
Now, there can be various interfaces between a site and the outside world (VOs, single users in the same domain, whatever). VO and site are well separated entities, and of course the grid is not the only customer a site can serve. These interfaces are checkpoints that can only be crossed by authenticating. Once the authentication has taken place, the middleware, and so the site, has no control over what the job does or does not. All that happens to site resources is up to the application. While the site admins have mechanisms to know if a given job is misbehaving with respect to resource utilization, for example, they have by no means the possibility to know if the pilot has switched user at the required time, after each new payload is pulled within the same slot, if it has been even done at all. Also the identity switch will be directly managed by the site with the tool it prefers and at certain specific times. In some cases the identity switch can even be done to a banned user or with not a valid credential.  So it's not like the VO goes "oh well I think I'll use glexec, I'll use sudo, I 'll not use anything".
The present security implications that pilot system are affected by all come down to this basic point. The identity of the job that authenticates, in fact, is not the identity of the job that runs. This both requires an identity switch (fair enough, but at the moment the site has no control over it) and the handling of the end user credentials.
So far, these security implications have been overlooked, and that happened basically because the advantages of late binding still exceed their disadvantages and no better solution has been proposed until now. Nonetheless, the evolution of this model cannot and must not ignore this point. The standardization of the pilot protocol will fix this in the first place, by giving the site the chance to enforce these kind of checks and the tool with which they are done. It will also be easier for new communities to implement pilots, as they would not have to bother with identity switching mechanisms.
Not only is this technically feasible, but none of the present functionality will be compromised nor reduced by this approach nor its flexibility will be. It will simply make life easier.
Furthermore, a standardized protocol for pilot would allow various middleware initiatives to open the doors to late binding to whoever needs it, without building more layers on top of that. EMI could allow late binding to a HPC system through its EMI Execution Services, just an example, and in the future that could be done without even outbound connectivity.