GRANT EXECUTE ON SomeProc TO SomeRole AS dbo I have a role ExecSP which I use to manage who can execute stored procedures. EXECUTE permission is granted on all SPs to this role.

I also use SQL Server Data Tools (SSDT) to manage MS SQL Server database schema.
In the file where my SP is defined, I have this:

CREATE PROC SomeProc AS
.
.
.

GO

GRANT EXECUTE ON SomeProc TO ExecSP


However, when I apply the change to the target database, and do the schema comparison, it reports differences in SP permissions, where on the DB side I have this:

GRANT EXECUTE ON SomeProc TO ExecSP AS dbo


I've tried to understand what AS dbo part represents, but I couldn't. 

My questions:


Does it mean that the SP will be executed with dbo rights, regardless of who is executing it? (I guess/hope it doesn't.)
Why is this added automatically?
I want this SP to be executed with the rights the caller has - how do I achieve that?
From BOL:



  Use the AS principal clause to indicate that the principal recorded as
  the grantor of the permission should be a principal other than the
  person executing the statement. For example, presume that user Mary is
  principal_id 12 and user Raul is principal 15. Mary executes GRANT
  SELECT ON OBJECT::X TO Steven WITH GRANT OPTION AS Raul; Now the
  sys.database_permissions table will indicate that the
  grantor_prinicpal_id was 15 (Raul) even though the statement was
  actually executed by user 13 (Mary).


https://docs.microsoft.com/en-us/sql/t-sql/statements/grant-transact-sql

So in this case the engine is recording the grantor as dbo, rather than the account running the actual code. 


I'm unsure why this would be - perhaps due to some aspect of the schema compare, dbo is used to ensure there are no orphaned records in terms of the grantor? Perhaps someone else can shed some light.
It should do this anyway - do you mean in this case the caller is the ExecSP role or the user themselves? Either way this should already be happening, if you've assigned the role or not.