That's fair. If we're wanting to restrict this particular thread to only the administrative aspects of xp_cmdshell then consider the DBA who is in the sysadmin Role but who does not otherwise have file system access to the host OS and does not have the SQL Server service account password. For fun let's say that the SQL Agent service is disabled and the hole allowing cmd-line access by tickling the registry and using another unmentioned T-SQL feature, the hack Jeff mentioned, has been closed in 2008+. In environments setup this way with DBAs working this way, and there are many DBAs setup this way in many environments including the one I am in right now, sanctioning the use of xp_cmdshell amounts to the sanctioning of permission elevation and identity obfuscation. In this scenario it becomes extremely difficult, if not effectively impossible, to audit the actions occurring in the context of the SQL Server service account. How to account for which cmd-shells were part of an automated process or an ad hoc attempt to access data that would otherwise be unreachable to the DBA? This may or may not be an issue in many environments, but environments are also not static. If you have a ton of DBA processes built up around the use of xp_cmdshell and a DBA is added, or a server is one day reclassified differently and is subject to compliance regulations, then how do you back down access to resources accessible to xp_cmdshell so this DBA can do their job? I am back to thinking that using xp_cmdshell paints us into a corner because there are no options to maintain the security context of the caller all the way through the stack. In some environments, maybe even most or the majority, it doesn't really make a difference one way or the other. I am just saying that the advice to leave it disabled has merit and should be the default response when discussing xp_cmdshell. Any advice that says to use it freely, especially on a public forum where little to no knowledge of the source environment is available, seems irresponsible to me.