The Secret Lives of Service Accounts: Why Your Bots Need Better Boundaries
21 October, 2025, by Natasha Free
Welcome to the Jungle
In the dense undergrowth of your infrastructure, a quiet entity is thriving and constantly multiplying - the non-human identity. Unseen, often unmanaged, and sometimes dangerously overpowered.
Non-human identities (NHIs) are service accounts, machine identities, secrets, tokens and a plethora of automation tools that make up the modern IT infrastructure.
The NHI is set to eclipse user identities by at least 50-fold (by thousands in cloud native environments). They usually sit in that “everything else” bucket because they are less noisy and needy than their human counterparts and they never leave. This is probably why they are often overlooked when it comes to strategy or lifecycle management. Often service accounts, bots, and system identities are enabled, given free rein and then not given a second thought.
You wouldn’t give an intern the master keys to your data centre, so why do it with your bots?
Common Pitfalls in Secrets Management for NHIs
NHIs are everywhere not only the CI/CD pipeline but monitoring and logging agents, cloud resource provisioning and robotic process automation (RPA), and require access to sensitive systems and data - which means they need secrets (credentials, tokens, certificates) to authenticate.
Most NHIs are born out of necessity - during a sprint to deploy a new service, automate a task, or integrate two systems. They are routinely provisioned manually via a developer or sysadmin creating a service account in Active Directory, AWS IAM, or a local system. Some platforms auto-generate service accounts with default permissions or commonly used tools like Terraform and Ansible may provision machine identities as part of deployment pipelines. Unfortunately, these NHIs frequently share the risky characteristics of broad permissions (“just to get it working”) with no clear owner or documentation. They are often static (e.g., API keys, passwords, tokens) with no expiration or rotation policy applied. And usually, they are forgotten about after their useful lifetime.
Management (or Lack Thereof): The Wild West of Secrets
Outside of a formal secrets management tool, secrets are often handled in risky ways. They can sometimes be found hardcoded in source code or scripts or even stored in plaintext config files or environment variables. They are almost always shared across multiple services or teams. (A colleague once visited a customer site to find the root password for the recently configured access solution written on the team whiteboard. This was some time ago but…)
All too quickly your infrastructure is littered with unaudited secrets that you have no visibility of. The fact that these identities are often over-permissioned adds another layer of risk.
Forgotten but Still Dangerous
Over time, NHIs often outlive their original purpose:
- The service is deprecated, but the account remains active.
- The developer leaves, and no one knows what the account does.
- Secrets are never rotated, and credentials become stale - or worse, compromised.
Without lifecycle management, these identities become ghosts in the machine - invisible, unmanaged, and potentially exploitable.
Signs Your Bots Are Out of Control
- No owner listed
- Credentials never rotated
- Active after service deprecation
Take service account creation for example. Accounts are often created hastily, with broad permissions, usually during an important change window, then once the requirement is fulfilled these identities are forgotten. This results in your infrastructure being littered with orphaned accounts, stale credentials and the high potential for shadow access.
NHIs have enabled the significant advances made in the last decade or so in automation, integration and orchestration. They keep your CI/CD pipeline working smoothly. But without proper oversight, they can become security liabilities.
So What?
What happens when you don’t have a full handle on your service account identities or where they are? Secrets “sprawl” has come back to bite many organisations in recent years. Google Cloud Security docs and cloud provider SOCs regularly call out the nefarious use of leaked service account keys posted accidentally to public GitHub (or other public locations) to authenticate to cloud APIs and access resources. This enables rapid, automated access to cloud resources and can lead to crypto-mining, data theft, or further lateral movement. Short-lived credentials and automated secret scanning won’t help once your service key is out in the wild.
In 2023 attackers accessed Cloudflare’s internal Confluence/Jira/Bitbucket after using a stolen integration token and service account credentials that were leaked during an earlier breach incident. Unfortunately, one service token and some service accounts were not fully inventoried or rotated during a remediation, leaving lingering access which was later exploited. Internal documentation, tickets and code metadata were exposed.
Matthew Prince
In this instance, Cloudflare had rotated thousands of credentials but demonstrated that you can still lose the castle if a few forgotten service accounts remain - non-human identities are often the blind spot.
A Reliaquest incident response dataset from 2024 showed a sharp rise in breaches where compromised service accounts or non-human identities were used to escalate or move laterally. In fact, most compromises they encountered were caused by the abuse of service accounts. The upward trend shows this is not a niche failure; it’s systemic - across cloud, SaaS, and on-premises AD environments. Non-human identities are now frontline attack vectors - organisational processes must adapt accordingly.
How Secrets Management Tools Can Help
Clearly all organisations would benefit from expanding the principle of least privilege to NHIs and ensuring that NHIs are included in the wider security strategy and identity lifecycle management process. Thankfully, modern secrets managers can take some of pain away by providing:
- Automated credential rotation.
- Audit trails for NHIs
- Enforcement access policies according to identity type
- Integration with modern IGA tools
Taming The Bots
These simple steps can take you a long way to taking back control:
- Inventory all non-human identities and map their privileges.
- Require short-lived credentials and dynamic secrets where possible.
- Block secrets in source control (pre-commit + periodic scanning).
- Assign ownership and accountability.
- Enforce automated key/token rotation and expiry.
- Monitor and alert on unusual machine-to-machine behaviour and OIDC/token reuse and audit access continuously
- Include service accounts in incident tabletop exercises and change control.
It’s clear that not having a handle on non-human identities can have profound consequences for the business and leave a trail of chaos that will burn time, resources and reputation.
Non-human identities might be able to work autonomously but they should never be left to their own devices.
If you'd like to know how we can help you with your secrets management, please get in touch.