http://www.sqlservercentral.com/articles/Stairway+Series/72461/
SQL Server Agent and proxy accounts.
Conspicuous by its absence is the Transact-SQL script (T-SQL) subsystem. T-SQL jobsteps always run in the security context of the job owner, and there’s no override in SSMS to change that. You can manually configure the job step, using the sp_add_jobstep system stored procedure, passing the database_user_name parameter to impersonate a database user for a jobstep, but of course you’ll need security rights to impersonate a database user to do so.
In order for a proxy account to work correctly, the account must have the “Log on as a batch job” (seBatchLogonRight) assigned to it by a Windows administrator (for example, in the Local Security Policy MMC snap-in, under Local Policies -> User Rights Assignment). Without that privilege the SQL Server Agent service will not be able to impersonate the account to run the job step. Also it is important to note that proxy accounts do not automatically have access to your SQL Server. If, for example, you want to use a CmdExec or PowerShell job step to log back in to SQL Server, the proxy account must explicitly be granted a login back to your SQL Server (or otherwise inherit access from a Windows group, etc.).
