Excellent question Dave.
I don’t have an effective answer, but i have some ideas.
We have an unusual situation with securing Powershell.
We need to execute Powershell scripts for genuine SysAdmin tasks and we need to ban execution of non-approved REPL, byte-Encoded, or any other form of scripts. This doesnt fall into a Application WhiteList, GP, EMET, Anti-Virus,Anti-Rootkit security model we have today.
Also large scale PKI deployments are not easy to manage without dedicated teams.
My suggestion:
a) On production desktops and servers, ban Powershell REPL and Powershell_ISE via Group Policy. ISE doesnt need to be there on Servers OR desktops. (Would you put Visual Studio on a production server ?)
ISE and REPL can be made available in a separate DEV domain for script development, isolated by separate VLAN’s, separate domain.
No constrained endpoints here – just ban.
b) How do I launch powershell scripts on a target machine for genuine SysAd tasks ?
Implement a custom Powershell host, which acts as constrained End-Point by default. Powershell execution is exposed via a service, which responds on a port.
For every Powershell script launched from the Custom Host, it calls a web-service.
The host sends a check-sum + Machine’s GUID to the service.
The web-service, does a check-sum of the script from the signed script in your SourceControl repo and responds OK/Not-OK to the custom host, after authenticating the machine with AD. (If you pawn the source control repo and modify the signed scripts, the checksum fails, and the script fails to execute)
The host logs all before, during and after calls to an external logCollector (Syslog on port 514 UDP).
The host should also provide some cross-cutting tools, like Error Logging, Job-Scheduling, Job-triggers, ETW traces, and other ENV: data + date/time.
How do you launch modules, custom functions you have authored ?
Modules live in a SourceControl \module trunk.
Invoke modules and custom-functions using something like Invoke-CommandAST here.
https://gist.github.com/sunnyc7/8694149
Other things to consider:
a) What is the Skill-Level of the team.
b) How paranoid are the SysAdmins
c) How high-risk is the environment.
You need to develop a tool for authoring custom-host and the web-service ONCE, and release it.
People can customize, add more layers, two-factor it for interactive session etc. and extend.
I am sure I will have some pull-requests for such a project. 
I know this sounds overtly complicated for a small environment.
Let me know what you think.
Other non-solutions considered:
a) Any user auth / RBAC / delegation based mechanism.
> Doesn’t cut it in a Mimikatz world.
b) Any logging, evented (Action->Response) based options.
> The first event, may defeat your protection mechanisms.
c) Plain constrained end-point without external web-service Auth.
> Someone will figure out a way to by-pass this, sooner or later.
d) Any machine specific security model, without external verification.
> How do you know you are not compromised, if someone else didnt tell you – you are not.