no, if you grant xp_cmdshell permissions, you cannot restrict the commands that they might use when they construct the strings.

typically what you want to do instead is

1. Remove access to xp_cmdshell.

2. determine what it is they wanted to do via xp_xmdshell, and create CLR methods or restricted procedures which call xp_cmdshell on their behalf.

so if they did 4 certain things via xp_cmdshell, create four alternatives for them to use instead.

in that way, you can remove permissions to xp_cmdshell to everyone, except say a superuser that noone has the password for, with a disabled login.

then you can use WITH EXECUTE AS to give elevated permissions to just the code within a proc.

--first we need a sysadmin role with no login, which will be used

--for execution context in the DDL triggers or special elevated permissions functions.

IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = N'superman' AND type = 'S') --'S' = SQL login

BEGIN

--create our super user

CREATE LOGIN [superman]

WITH PASSWORD=N'NotTheRealPassword',

DEFAULT_DATABASE=[master],

CHECK_EXPIRATION=ON,

CHECK_POLICY=ON

--make our special user a sysadmin

EXEC master..sp_addsrvrolemember @loginame = N'superman', @rolename = N'sysadmin'

--noone will ever login with this, it's used for EXECUTE AS, so disable the login.

ALTER LOGIN [superman] DISABLE

END

GO

USE [SandBox];

GO

CREATE USER [superman] FOR LOGIN [superman];

GO

USE [SandBox];

GO

--the EXECUTE AS must be a user in the database...not a login

CREATE procedure pr_CallBoostedSecurityProcess

WITH EXECUTE AS 'superman'

AS

BEGIN

--do elevated stiff like xp_cmdshell

dbcc freeproccache

END