When attackers compromise an environment, gaining the initial foothold is often only the beginning. Once inside, one of their next objectives is to understand the identities available to them: what accounts exist, what credentials can be obtained, what privileges those identities possess, and what additional systems and data can be reached through them.
The recently disclosed security incident at cloud application platform Zeabur provides a useful real-world example. The attack began with a vulnerability in a public-facing service, but it didn’t end there. As the attacker moved through the environment, they obtained credentials, assumed privileged identities, elevated a service account, and ultimately reached Zeabur’s production environment.
The incident demonstrates an important identity security principle: service accounts are identities, and identities need governance.
What Happened at Zeabur?
On August 27, 2026, an attacker gained unauthorized access to Zeabur’s systems. According to Zeabur’s September 7 incident report, the initial entry point was a vulnerability in a publicly accessible service running on one of its shared clusters.
After gaining code execution, the attacker began moving through the environment. Legacy API keys were obtained from an internal routing cache and tested to identify credentials with higher permissions. One belonged to a team administrator and was subsequently used to enumerate internal projects and access environment variables from an internal management service.
Those environment variables contained AWS credentials, including a highly privileged AWS root key. The attacker then authenticated to AWS and began enumerating cloud resources.
At that point, the incident had moved far beyond exploitation of the original vulnerable application. The attacker was now operating through legitimate identities and credentials already present within the environment.
When a Service Account Becomes Part of the Attack
Zeabur’s investigation uncovered another significant event. At 07:26 UTC on August 27, a service account in the Tokyo shared cluster was granted cluster-administrator permissions, giving the attacker the highest level of control over that cluster.
An existing scheduled maintenance job created an additional path toward Zeabur’s production systems. The maintenance job had legitimate private-network connectivity to core production resources and possessed database credentials. Critically, Zeabur determined that those database credentials had access to more data than the maintenance function actually required.
Once the attacker controlled the cluster, those existing privileges became extremely valuable. Zeabur determined that the attacker ultimately assumed this service identity and used it to read project environment variables from the production database. Those environment variables contained sensitive information including API keys, cloud credentials, database passwords, application signing keys, and other service credentials.
The service account wasn’t the initial vulnerability. But machine identities, credentials, and excessive privileges helped an attacker turn an initial compromise into a much broader security incident.
This distinction matters. Protecting an organization from every initial compromise is extraordinarily difficult. Organizations also have to limit what an attacker can do after gaining that initial foothold. Identity governance is an important part of creating that containment.
The NHI Problem Is Already Here
Most organizations have spent years building governance processes around human identities. An employee joins the organization, receives access based on their job responsibilities, and ideally has that access periodically reviewed. When the employee changes roles or leaves the organization, those permissions should change accordingly.
But enterprise environments contain another enormous population of identities that may not receive the same scrutiny:
- Service accounts
- Automation accounts
- Applications
- Workload identities
- API credentials
- Bots
- And increasingly, AI agents
These Non-Human Identities, or NHIs, can have extremely powerful access to enterprise systems and data. In many organizations, however, they don’t have anything comparable to the governance processes applied to human users.
That creates a fundamental visibility and accountability problem. An organization may know exactly how many employees it has while struggling to answer how many service accounts exist across Active Directory, Entra ID, cloud environments, applications, databases, and infrastructure.
Even identifying the accounts is only the beginning. Security teams also need to understand why each service account exists, who is responsible for it, what resources it can access, what privileges it possesses, whether those privileges are still necessary, and when that access was last reviewed.
The Zeabur incident highlights why these aren’t merely compliance questions. An attacker who gains access to an environment is interested in many of the same things. They want to understand which identities exist and which ones provide a path to more valuable resources.
Every Service Account Needs a Human Heartbeat
At YouAttest, we believe every service account should ultimately have a human heartbeat. Someone needs to be accountable for the identity and periodically verify that it still exists for a legitimate reason and still has appropriate access.
This is especially important because service accounts don’t naturally participate in the governance lifecycle that surrounds employees. A service account doesn’t tell security that the application it supported was retired six months ago. It doesn’t report that the engineer who created it left the company. It doesn’t notice that it accumulated additional permissions over several years, and it doesn’t question whether it still needs access to a production database.
A human owner can provide that accountability. Periodically, that person should be required to review the service account and confirm that they recognize it, understand its purpose, accept responsibility for it, and have reviewed the access associated with it.
That is the heartbeat.
Without it, organizations can accumulate orphaned or poorly understood machine identities whose original purpose, ownership, and privileges have become increasingly disconnected over time.
Service Accounts Need Access Reviews Too
The Zeabur incident also highlights the importance of least privilege. Zeabur acknowledged that the database credential associated with its scheduled maintenance job could read more information than the job actually required.
This is exactly the type of problem User Access Reviews are intended to uncover for human identities. The same principle should apply to service accounts.
Least privilege cannot simply be established when an account is created and then assumed to remain correct forever. Applications change, infrastructure changes, responsibilities change, and permissions accumulate. A service account that had appropriate access two years ago may be significantly overprivileged today.
That is why access needs to be periodically reviewed. Someone should be able to look at the service account, understand what it does, examine its current access, and determine whether those privileges are still justified.
For a human identity, that reviewer might be the employee’s manager. For a service account, the reviewer should be the accountable human owner—the person providing that identity’s heartbeat.
AI Makes an Existing Identity Problem Bigger
The cybersecurity industry is understandably focused on governing AI agents. Organizations are trying to understand how to discover agents, control what they can access, and determine whether they should be trusted.
Those are important questions, but AI agents are entering enterprise environments that are already filled with NHIs. Service accounts, workload identities, applications, bots, automation accounts, and API credentials have existed for years. AI is adding another rapidly growing category of machine identity to an identity governance problem that already exists.
Before organizations can effectively govern the next generation of AI agents, they need visibility and governance around the non-human identities already operating throughout their environments.
That starts with a surprisingly basic question: Do you actually know what service accounts you have?
The next questions follow naturally. Who owns them? What can they access? When were they last reviewed? Have their privileges changed? And which accounts represent the greatest risk?
How YouAttest Helps
The lesson from incidents such as Zeabur isn’t simply that organizations need to protect service-account passwords more carefully. Credentials absolutely need to be protected, but identity governance addresses a different part of the problem: understanding and governing the identity behind those credentials.
YouAttest helps organizations review their accounts—including service accounts—rather than limiting identity governance to traditional human users. Organizations can establish accountable ownership for service accounts and create a recurring human heartbeat in which that owner periodically reviews and attests to the identity and its access.
YouAttest also helps organizations identify which accounts are service accounts and determine which service accounts may represent greater risk, allowing security and governance teams to focus attention on the identities that matter most.
Ultimately, organizations should be able to answer four questions about every service account: What is it? Who owns it? What can it access? And has that access actually been reviewed?
The goal isn’t simply to discover more accounts. It is to create accountability around the identities that already have access to the enterprise.
Find It. Own It. Review It. Govern It.
The Zeabur incident provides a timely reminder that attackers don’t stop after gaining their initial foothold. They search for identities, credentials, privileges, and paths to more valuable systems.
Security teams should be doing the same analysis before the attacker arrives.
Organizations need to know which service accounts exist, understand what they can access, assign accountable human owners, periodically review those privileges, and identify the service accounts representing the greatest risk.
Because a service account isn’t just a technical artifact running quietly in the background.
It’s an identity with access. And that identity needs to be governed.
Join Us: The Shadow NHI Problem
We’ll take this discussion further on September 15 during our next #AuditTuesday: “The Shadow NHI Problem: What’s Hiding in Your Identity Environment?”
I’ll be joined by Dave Ackley, Founder & CEO of Goliath Cyber Security Group, and Andrew Berkuta, COO and Zero Trust Expert at Goliath Cyber Security Group, for a practical discussion about discovering, assessing, and governing Non-Human Identities.
We’ll look at how organizations can determine which NHIs exist, establish ownership, understand their privileges and access, determine when they were last used and reviewed, and identify which identities represent the greatest risk. Contact us to solve your service account governance challenges.
You can’t govern an identity you don’t know exists.
Find it. Own it. Review it. Govern it.
- AI Agents Are Privileged Identities. Their Access Needs to Be Reviewed. - October 3, 2026
- AI Is the Unrealized Insider Threat: Why Enterprise AI Security Starts With Existing User Access - September 20, 2026
- The Service Account Wasn’t the Initial Breach. It Became Part of the Attack. - September 13, 2026
