Ask a CISO how many service accounts are in their environment. Most will give you a number. Ask them how many of those accounts are still active, what they have access to, and who’s responsible for them — and the conversation gets uncomfortable fast.
Service account hygiene isn’t a glamorous problem. It doesn’t have a dedicated conference track or a vendor category named after it. But it sits at the center of some of the most damaging breaches of the last decade. The Marriott Starwood breach — 383 million guests, one of the largest ever recorded — had a compromised service account at its core. In 2024, ReliaQuest found compromised service accounts involved in 85% of the breaches they responded to.
And if your organization is deploying agentic AI, it just became significantly more urgent.
The Account Nobody Owns
Service accounts are created to solve an immediate problem. An application needs to talk to a database. A script needs to run on a schedule. An integration needs API access. The account gets created, permissions get set — usually broadly, to avoid having to revisit them — and the ticket gets closed.
What doesn’t happen: documentation of what the account actually does, assignment of a human owner, definition of an expiry date, or any plan for what happens when the application it was created for gets decommissioned.
The result is an environment where service accounts accumulate like technical debt. They’re overprivileged by default, unmonitored by design, and forgotten by necessity. Research by identity security firm Anetac found that 75% of organizations misuse service accounts — and 76% of security professionals acknowledged their service accounts have direct access to their most sensitive systems.
That’s not a configuration problem. That’s a governance problem.
Why Service Accounts are Different
Human accounts have natural hygiene cycles. People leave the organization. Passwords expire. MFA prompts attention. Anomalous login behavior at 3am from an unfamiliar location triggers an alert.
Service accounts have none of that. They don’t leave. They don’t get MFA prompts. They authenticate constantly, at all hours, from automated processes — which means anomalous behavior looks exactly like normal behavior. A service account querying a database at 3am isn’t suspicious. That might be exactly what it’s supposed to do.
This is what makes them attractive targets. An attacker with access to a service account credential doesn’t have to be subtle. The account is already doing things that look legitimate. The access is already there. The permissions are already broad. All they have to do is use what’s been left unlocked.
The AI Agent Problem
If your organization is deploying agentic AI pipelines — and statistically, you either are or you’re about to be — this problem just got a new dimension.
AI agents need identities to operate. They authenticate, they access resources, they make decisions and take actions autonomously. The path of least resistance when standing up an agent is to give it a service account, assign broad permissions so it doesn’t keep failing on missing access, and move on.
Sound familiar?
That’s the part that doesn’t show up in your threat model. No attacker. No malicious intent. Just an agent executing a legitimate task with more access than it should have, at machine speed, with no human in the loop to notice it went somewhere it shouldn’t.
We wrote about this dynamic in the context of broken access control — the danger isn’t always a compromised agent. Sometimes the call is coming from inside the house, and the only reason it got in is because the door was already open. Service accounts are that door.
What Service Account Hygiene Actually Has
“Hygiene” sounds like a checklist. In practice it’s a continuous discipline with four components that most organizations haven’t fully implemented even once.
Inventory. You cannot manage what you cannot see. A complete, current inventory of every service account in your environment — what it does, what it has access to, when it was last used, and who owns it — is the baseline. Most organizations don’t have one.
Least privilege. Service accounts should have exactly the access required for their specific function, nothing more. Not “probably enough.” Not “broad enough that we don’t have to revisit it.” Exactly what the task requires. This is harder than it sounds and requires actually understanding what each account does — which is why it doesn’t happen.
Ownership and accountability. Every service account needs a human owner. Not a team. A person. Someone whose name is attached to it and who is responsible for reviewing it, renewing it if necessary, and decommissioning it when the function it serves no longer exists.
Monitoring and detection. Service account behavior should have a defined baseline. Deviations from that baseline — new resources accessed, unusual volumes, unexpected timing — should trigger alerts. If your SIEM isn’t watching service accounts with the same attention it gives human accounts, you have a visibility gap the size of your blast radius.
The Urgency Isn’t New – the Stakes Are
Security teams have known service account hygiene was a problem for years. The reason it stays on the backlog isn’t ignorance — it’s that the work is tedious, the payoff is invisible, and nothing bad has happened yet.
AI agents change that calculus. Every agent you deploy that inherits a poorly scoped, unmonitored service account multiplies the risk surface at machine speed. The hygiene problem that was chronic becomes acute the moment an autonomous process starts operating on top of it.
The good news is that the fix isn’t new technology. It’s the foundational identity work your zero trust strategy was always supposed to include. Enforce least privilege at the network layer so overprivileged accounts can’t reach what they shouldn’t, regardless of what’s configured at the application layer. Issue scoped, time-bound credentials for non-human identities. Monitor behavior, not just authentication.
None of that requires a new vendor. It requires treating service accounts like the identities they are — not the infrastructure nobody thinks about until something goes wrong.