Mercurial service accounts had been at work—silent, persistent, moving code across repositories without human hands.
A Mercurial service account is a non-human user identity that can push, pull, and manage repos in automated workflows. These accounts are essential for CI/CD pipelines, deployment scripts, and integrations with other systems. They hold permissions, credentials, and sometimes SSH keys, making them trusted operators in the architecture. When you run automated builds or sync branches between environments, the service account is the agent that executes those commands.
Security is the first concern. A Mercurial service account should have only the minimum permissions required for its tasks. Store its credentials in a secure secrets manager, not in plaintext scripts. Rotate keys regularly and monitor its activity with logs. Treat every service account as you would a production system, because a compromised account is a compromised workflow.
Version control hygiene matters. Naming conventions like svc-build or ci-runner make it clear which accounts are automated. Granular repository access prevents the account from touching code it shouldn’t. Network restrictions can block the account from operating outside of known environments. Audit trails ensure you can track which commits or merges came from the service account, and when.