From Secrets to Service Accounts: SecOps Lessons in Non-Human Identity Hygiene

This is the first post in a multi-part series, Lessons from a SecOps Engineer, where I write up what running SecOps in the cloud actually teaches.

When we think of identities in IT, we instinctively picture users: engineers, admins, employees. But in modern cloud environments, human users are the minority. The vast majority of activity is performed by non-human identities: digital identities assigned to machines, workloads, and services.

These can take many forms: CI/CD build containers, microservices, internal applications, service accounts, API keys, tokens, and certificates. They’re necessary, essential even, for tasks like allowing a microservice to authenticate to a database, or a pipeline to push an image to a remote repository.

These identities are usually created ad hoc by developers or DevOps teams, often with overly permissive access, simply to get things working quickly. Once created, they’re rarely monitored and even more rarely revisited.

Nobody is being negligent. Non-human identities simply have no lifecycle: no onboarding or offboarding flow, no HR ticket when a service is deprecated. They persist in silence.

A Growing Storm

In traditional IT environments, you might have had a handful of service accounts. But with today’s rapid adoption of microservices, container orchestration, SaaS platforms, and API-driven architectures, non-human identities now outnumber humans many times over. CyberArk’s 2025 Identity Security Landscape reports machine identities outnumbering human ones by 82 to 1, up from the roughly 45 to 1 its 2022 edition put it at.

These identities span environments, from Kubernetes service accounts and GitHub Actions runners to API integrations and container orchestration layers. They are everywhere, and the count keeps climbing.

GenAI adds to it. Deloitte predicts that in 2025, 25% of companies using generative AI will launch agentic AI pilots or proofs of concept, growing to 50% by 2027. More agents means more machine roles, more keys, more service accounts.

Multi-cloud, hybrid setups, and third-party integrations have reintroduced a familiar problem: secret sprawl. GitHub reports that more than 39 million secrets were leaked across its platform in 2024 alone. The more sprawling and fragmented your non-human identities become, the harder they are to manage.

The March 2025 compromise of the tj-actions/changed-files GitHub Action (tracked as CVE-2025-30066), a widely used component in CI/CD pipelines, is a fresh reminder of how damaging it is when a privileged non-human identity falls into the wrong hands. The compromised action dumped secrets from CI runners into build logs, public for any public repository that used it.

Why This Is the Elephant in the Room

We built this problem ourselves.

We automated everything and scaled fast. In doing so we created thousands of invisible actors with real power and no expiry date, and they are hard to manage.

Let’s go over some of the reasons why non-human identities are so difficult to handle:

• They are hard to monitor. Many operate in the background, making them easy to overlook. No login events, no user behavior analytics, no alerts, unless you specifically build them.
• Nobody can see them. In many organizations there’s no central inventory of service accounts, roles, or tokens. No tagging, no tracking, no ownership.
• They are often over-permissioned. For the sake of speed, they are often given broad access, sometimes even full admin rights, just to make things work.
• They don’t stop at your perimeter. They extend into third-party services, SaaS applications, and external APIs, a web of dependencies that is hard to manage.

A SecOps Reflection

The teams that get ahead of this are the ones that decide a service account deserves the same scrutiny as an employee. The moment you start asking, “Why does this service account need write access to that database?”, “Who owns it?”, and “Is it still needed?”, you’re doing security before the incident instead of after it.

Where Do We Go From Here?

This stopped being a niche concern. Most of what happens in your cloud is done by machine identities. These identities are critical to productivity and scale, yet they’re often overlooked and not properly managed. We create them, assign them permissions, and move on, rarely reviewing, rarely decommissioning, and rarely questioning whether they still need the access they have.

But with every service account you create, and every access token left unchecked, you’re increasing your blast radius.

Understanding the scope of the problem is step one. If you’re responsible for cloud security or infrastructure, ask yourself:

• Do you know how many non-human identities exist in your environment right now?
• Can you trace what they do, what they access, and who owns them?
• If one of them was compromised, would anything tell you?

If the answer to any of these is “no,” then you are in the majority. That is fixable.

In the next parts I’ll get concrete on the questions above: inventory, ownership and decommissioning, with the configs I actually use.

The goal is not perfection. Be deliberate about what you allow, and keep it maintainable as the environment grows.

Part two: building the inventory.