Service information—such as information about dependencies and which service account you're using—resides in the registry. SQL Server doesn't have an intrinsic function that tells you what service account you're currently using, but by using some undocumented extended stored procedures to read the registry, you can easily obtain the information you want. Listing 1 shows a stored procedure that will tell you which account your SQL Server is using. (As with any undocumented procedure, be aware that this code uses extended stored procedure calls that Microsoft might change or remove from the system without notice.)
A good security practice is to run the SQL Server service account and related accounts, such as SQL Server Agent, with low-level privileges. This practice reduces the risk of system exposure. Although running SQL Server or SQL Server Agent under the local account, which provides full administrative access to the local machine, is convenient (you don't have to manage passwords or set ACLs on files or the registry), it typically isn't a good idea. If your system is ever exposed, the highly privileged local account provides an easy jumping-off place to the rest of your environment.
For more information about how to secure your SQL Server, see J.D. Meier, et al, Improving Web Application Security: Threats and Countermeasures (Microsoft, 2003), chapter 18, "Securing Your Database Server." You can also learn about security best practices at the TechNet SQL Server Security Center, and the MSDN SQL Server Developer Center.
Also, be aware that when you don't use Enterprise Manager to change your SQL Server or SQL Server Agent service account, you might run into problems because ACLs on the file system and registry won't be set correctly. (These problems appear only when you're changing accounts, not when you update a password for a service account.) To learn how to avoid complications, see the Microsoft article "How to change the SQL Server or SQL Server Agent Service account without using SQL Enterprise Manager in SQL Server 2000."