It's interesting that you mentioned security because in order to use openrowset you're using a configured SQL Server that is likely less secure than it ought to be. Ad hoc distributed queries using this manner was turned off by default starting with SQL Server 2000 SP3 (see details here: http://msdn.microsoft.com/en-us/library/ms187569.aspx).

Credentials do allow the process to run as the domain account, but for the process executing under SQL Server Agent. However, the problem is that the openrowset connection is coming from SQL Server. So you execute the job as the credential and the connection to SQL Server is as the credentialed user. But because you're going through SQL Server it flips to SQL Server's authentication. If you were connecting directly to the Access DB, say to copy it, from the SQL Agent job step, you would see it as the credential.

There may be a way to do what you're trying to do using a linked server and having Kerberos delegation set up. But that would require the domain credentials to be used to connect and the linked server would have to be configured to pass the credentials through. In general, SQL Server logins are considered less secure than Windows logins. Is there a reason you want to use a SQL login?