@Sigerson,

My apologies for the long overdue response. I lost track of this thread.

The type of "proxy" that I was talking about isn't like the fact that multiple people login to an application and the application talks to the database with its own login (although I do have an appreciation for Developers that actually pass user information through the app especially when the app writes to the database). The type of proxy I'm talking about is where an individual user is granted privs to run xp_CmdShell directly even though that user does not have "SA" privs.

The reason why such a proxy is a terrible mistake is because the user isn't using xp_CmdShell within the confines of their own login privs. Rather, xp_CmdShell will operate as the login for the SQL Service itself, which frequently has extraordinary privs across the domain (another mistake... the SQL Server Service login should also be limited). That means that the unprivileged user can use xp_CmdShell to (for example) see files and other databases that they're not supposed to. It also means that they can modify or even delete data/files and the only trace that may (provided there is any auditing) be left behind is that the SQL Server Service login did it.

My take on the use of xp_CmdShell is that only those people with "SA" privs should be allowed to use it directly and only DBAs should have "SA" privs and then only the most trusted ones. NO application should ever have "SA" or even "DBO" privs. Everyone else (including apps) should only be allowed to do what a stored procedure will allow them to do (which can include xp_CmdShell functionality if done properly). I also believe that well protected processes that do things like calling BCP using CmdExec tasks in jobs or using xp_CmdShell in properly protected stored procedures is just fine.