NHI governance for service accounts, API keys, and AI agents

At a glance

What this is: This is an independent analysis of why traditional IGA does not cover non-human identities and what NHI governance must add.

Why it matters: It matters because the same governance model that works for employees fails for machine identities, AI agents, and service credentials that authenticate outside HR-driven lifecycle controls.

👉 Read Zluri's analysis of NHI governance for service accounts, API keys, and AI agents

Context

Most identity programmes still treat access as a human lifecycle problem, but service accounts, API keys, OAuth tokens, certificates, and AI agent credentials live outside that model. They are created by engineers or systems, not HR, which means standard joiner-mover-leaver workflows do not see them, review them, or retire them on time.

That gap matters because non-human identities often carry production access, long-lived credentials, and broad privileges with no reliable owner signal. For IAM, IGA, PAM, and secrets teams, the practical question is no longer whether these identities exist, but whether they are governed with the same discipline as employee access.

Key questions

Q: How should security teams govern service accounts and API keys in an IGA program?

A: Treat them as identities, not just technical artifacts. Put every service account, API key, OAuth application, and certificate into discovery, assign a human owner, review access on a fixed cadence, and revoke credentials when the business purpose ends. If the identity cannot be inventoried and attested, it is outside governance.

Q: Why do non-human identities create more risk than many teams expect?

A: They are often long-lived, widely privileged, and created outside HR processes, so they escape normal onboarding and offboarding controls. A single forgotten credential can persist for years and provide access to multiple systems without the visibility or behavioural signals that human identities usually generate.

Q: What breaks when access reviews do not include machine identities?

A: Ownership and accountability break first, because no one is formally asked to confirm that the account still has a valid purpose. Then privilege creep persists, dormant accounts survive, and auditors cannot trace why access exists. The result is a governed employee estate beside an ungoverned machine estate.

Q: Who is accountable when a service account or AI agent is over-privileged?

A: The accountable human owner and the identity governance process are both in scope. Teams need a named owner, a clear purpose, and a review trail that shows when access was approved, certified, or revoked. Without that, responsibility becomes diffuse and remediation slows down.

Technical breakdown

Why IGA misses non-human identities

Traditional IGA assumes an identity begins with an HR event and moves through an employee lifecycle. That model breaks for service accounts, API keys, and AI agent credentials because they are created by application teams, infrastructure workflows, or software itself. They often have no employee record, no formal approver, and no natural offboarding trigger. As a result, discovery, certification, and deprovisioning controls all lose their anchor. In practice, that leaves a parallel identity estate running beside the governed one, with privileges that are technically valid but operationally invisible.

Practical implication: extend identity discovery beyond HR-connected systems into cloud, SaaS, code, and secrets inventories.

How non-human credentials expand the attack surface

Non-human identities create risk because they are machine-speed credentials that can be copied, reused, embedded, and forgotten. Unlike human users, they authenticate without MFA and can run at high volume without triggering obvious anomalies. A single API key or service principal may unlock multiple downstream systems, especially where integrations chain across cloud and SaaS platforms. When these credentials are over-privileged or never rotated, they become durable access paths rather than temporary enablers. That is why NHI governance has to combine visibility, privilege scope, and lifecycle control instead of treating secrets management as a complete answer.

Practical implication: map each credential to the systems it can actually reach, then reduce privilege before rotation becomes your only defence.

What AI agents change in the identity model

AI agents introduce a new governance problem because they can hold credentials, call tools, and act across systems without a person approving each step. Even when they are not fully autonomous, they still behave like non-human identities that can expand their effective reach through delegation and tool use. That means identity governance must account for the agent, the tools it can invoke, and the access boundary around its session or workflow. The important change is not just scale. It is that machine identities are beginning to select actions inside business processes that were formerly limited to human decision chains.

Practical implication: classify AI agents as governed identities, not just application features, and review their access as part of the identity estate.

Threat narrative

Attacker objective: The attacker’s objective is to convert one forgotten or over-privileged machine identity into durable access across business systems.

1. Entry occurs when an attacker obtains a long-lived non-human credential such as a service account password, API key, OAuth token, or cloud service principal.
2. Escalation follows when that credential has broad downstream reach, allowing the attacker to pivot into production systems, SaaS integrations, or administrative interfaces.
3. Impact occurs when the compromised NHI is used for persistence, data access, or internal movement that blends into legitimate machine traffic.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI governance is now an identity control-plane problem, not a credential hygiene problem. The article shows that service accounts, API keys, OAuth tokens, and AI agent credentials sit outside HR-led identity governance, which means the core IGA assumption has already failed. The discipline now has to govern discovery, ownership, lifecycle, review, and audit evidence across machine identities that are created and retired by software teams. The practitioner conclusion is straightforward: if the identity estate is incomplete, the governance programme is incomplete.

The non-human identity blind spot is the breach path, not a secondary risk factor. The source examples make the pattern plain: attackers are not bypassing identity controls, they are using the identities controls never covered. That shifts NHI governance from a niche hardening exercise to the front line of exposure reduction. The practitioner conclusion is that blind-spot reduction should be measured like any other control objective: inventory completeness, owner coverage, and review coverage.

Privilege without lifecycle offboarding is the named failure mode this article exposes. Machine identities are often created for a project, pipeline, or integration, then left active after the business purpose has ended. That is a governance failure, not merely a secret management issue, because access outlives accountability. The practitioner conclusion is that offboarding for service accounts and tokens must be treated as a first-class identity control.

AI agents turn NHI governance into a delegated-action problem. Once an identity can call tools and act across systems, the control question is no longer only who owns the credential, but what the credential is permitted to initiate during execution. That creates a governance boundary that conventional IGA does not model well. The practitioner conclusion is that agent access should be governed as a dynamic identity relationship, not a static application entitlement.

OWASP NHI Top 10 thinking should sit alongside IAM governance, not inside secrets management alone. Rotation, vaulting, and monitoring matter, but they do not answer whether the identity should exist, who owns it, or whether its access still matches its purpose. The implication for the field is that identity teams need a unified model that spans NHI discovery, privilege review, and lifecycle enforcement. The practitioner conclusion is to treat governance and secrets as complementary controls, not substitutes.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the State of Non-Human Identity Security.
• That same research found that 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
• For the governance side of the problem, read the Ultimate Guide to NHIs for a deeper view of discovery, lifecycle, and access review controls.

What this signals

NHI accountability debt: when machine identities outlive the teams and projects that created them, governance debt accumulates faster than most IGA programmes can detect. The practical response is to treat owner assignment, review cadence, and decommission triggers as operational controls, not documentation tasks.

The market signal is clear: identity teams need a unified inventory that spans human, non-human, and agentic access, because review processes cannot certify what discovery never found. That is why a platform view across cloud, SaaS, and secrets layers is becoming a baseline expectation rather than an optimisation.

As non-human identities expand, the governance question shifts from whether secrets are rotated to whether access relationships are still valid. Teams that can prove ownership coverage and certification completeness will be better positioned to absorb AI agent growth without losing control of the identity estate.

For practitioners

• Inventory non-human identities across all control planes Build a single inventory that spans cloud IAM, SaaS connections, code repositories, CI/CD systems, and vaults. Include service accounts, API keys, OAuth apps, certificates, and AI agent credentials, then tag each item with owner, purpose, privilege scope, and last activity.
• Assign a human owner to every machine identity Require owner assignment at creation and use metadata inference only when explicit ownership is missing. Reassign ownership when teams change, contractors leave, or an integration is retired so accountability never disappears behind the credential.
• Certify long-lived access on a fixed review cadence Include service accounts, tokens, and connected applications in quarterly or semi-annual access reviews. Present usage data, privilege level, and purpose to the owner so the review can confirm whether the identity still has a valid business need.
• Trigger decommissioning when the business purpose ends Connect application retirement, project closure, and integration shutdown to automated revocation workflows. Do not let credentials survive because no one remembered to close them, and verify that the account is disabled after the system is no longer needed.
• Separate secret protection from identity governance Keep vaulting and rotation under secrets management, but do not treat them as a substitute for ownership, attestation, and lifecycle control. A rotated credential is still a governance problem if the identity behind it is unowned or over-privileged.

Key takeaways

• Service accounts, API keys, OAuth tokens, and AI agent credentials sit outside the HR-based model that most IGA programmes still rely on.
• The article’s examples show that a single unowned or unrotated machine credential can create broad access paths and prolonged exposure.
• Practitioners need discovery, ownership, review, and decommissioning controls for NHIs, while keeping secrets management as a complementary discipline.

Key terms

• Non-Human Identity: A non-human identity is a credential used by software, systems, or automated processes to authenticate and act without a person logging in. It includes service accounts, API keys, tokens, certificates, workload identities, and AI agent credentials that can access enterprise systems.
• NHI Governance: NHI governance is the practice of applying identity governance controls to machine identities across their full lifecycle. It covers discovery, ownership, privilege review, certification, rotation, and offboarding so that non-human access is visible, accountable, and removable when no longer needed.
• Service Account: A service account is a named non-human identity used by an application or automated process to access systems and data. In mature governance, it should have an owner, a defined purpose, limited privileges, and a retirement path tied to the business service it supports.
• Access Certification: Access certification is the periodic confirmation that an identity still needs the access it has been granted. For non-human identities, the review must include purpose, ownership, usage, and privilege scope, because machine accounts often persist long after the project that created them has ended.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance NHI Governance, focusing on service accounts, API keys, and AI agents in IGA programs. Read the original.