Service accounts and dynamic agent identities both live under the NHI umbrella. One of them is a solved problem. Here's how to tell the difference in a buyer conversation.
When a buyer mentions "non-human identity" in a discovery call, they're usually conflating two distinct problems that require different conversations. The first is service account management — a decades-old discipline with mature tooling, established governance patterns, and no shortage of vendors who've been solving it since before most of their developers were in college. The second is something genuinely new: identities that are spawned programmatically at the start of an agent run, potentially carry scope delegated from a real human, and cease to exist when the task finishes. Knowing which problem the buyer is actually describing, and being able to name the distinction precisely, is what separates an AE who earns credibility from one who loses it by overclaiming a category.
Static Service Account
What it is: A credential-bearing identity assigned to an application or process, provisioned manually, with a lifespan measured in months or years.
What it does: Authenticates one system to another without human involvement at runtime. A batch job that pulls records from a database at 2 a.m., an application that calls an API to push telemetry, a CI/CD pipeline that deploys to a cloud environment — all of these authenticate using a service account. The account exists before the job runs and continues to exist after it finishes. It is, by design, persistent.
Who's behind it / where it comes from: A human admin provisioned it, usually a developer or an ops engineer, often at the moment the application was first deployed. It lives in a directory, a secrets vault, or — in the scenario that makes security teams reach for antacids — a config file in a repository. In federal environments, service accounts typically fall within a system's authorization boundary and are inventoried as part of the ATO package, though the quality of that inventory varies considerably in practice. Ownership tends to drift: the person who created the account may have left the organization, the application it was created for may have been deprecated, and the account itself may still be authenticating to something.
What makes it distinct: It doesn't change unless someone makes it change. The same credential, the same permissions, the same account, authenticating the same application to the same system, until a human manually rotates it, scopes it down, or decommissions it. The identity is static by design, and that design is the source of both its utility and its risk profile. You know exactly what it is. You may not know where it is.
Okta Concept Mapping: PAM and the Service Account Problem
Privileged Access Management maps cleanly here. PAM was built to govern exactly this: long-lived, high-privilege credentials that authenticate without human presence at runtime. The vault-and-rotate pattern, the just-in-time provisioning model, the session recording — all of it assumes a persistent identity that you can track across its lifecycle. Where the analogy holds: service account governance in an Okta context is a PAM conversation. Where it breaks: PAM assumes the identity exists long enough to be vaulted, rotated, and audited. An identity that lives for 90 seconds never enters the vault. In a buyer conversation, this is the line worth drawing: "PAM solves the service account problem. It doesn't solve the agent run problem."
Dynamic Agent Identity
What it is: A short-lived identity created at the start of an agent run, scoped to that run, and expired when the run ends.
What it does: Authenticates an AI agent to the systems it needs to access while completing a task. The agent might be reading from a knowledge base, writing to a ticketing system, querying an API, or coordinating with other agents in a multi-agent pipeline. Each of those interactions requires the agent to present credentials that establish who — or what — is making the request. The dynamic agent identity is what the agent presents. It did not exist before the orchestration layer spawned it, and it should not exist after the task completes.
Who's behind it / where it comes from: Not a human admin. The identity is created programmatically by an orchestration layer — the agent framework, the platform, the runtime environment — at the moment a task is initiated. In many current implementations, this means the orchestration layer is also the governance layer, which is a problem worth naming. The identity may carry scope delegated from the human who initiated the task, which introduces a relationship to human identity that service accounts don't have. A service account authenticates as itself. An agent identity may authenticate as itself while acting on behalf of someone else.
What makes it distinct: The lifespan. A service account's credential rotation is measured in days or months; an agent identity's entire existence may be measured in seconds. There's no lifecycle to manage in the traditional sense. The identity spawns, operates, and expires within a window that most identity governance tooling was never designed to observe, let alone control. That's the genuinely new problem: an identity that dies before your audit log has finished writing the first entry.
Okta Concept Mapping: OAuth Delegation and the On-Behalf-Of Pattern
OAuth's on-behalf-of flow is the closest IDAM analog to what dynamic agent identities are trying to accomplish: a service acting with scope derived from a user's authorization, not its own standing permissions. Where the analogy holds: the conceptual structure is right. The agent is not the user; it's acting with scope the user granted. Where it breaks: OAuth OBO assumes a human authenticated recently enough that their token is still valid, and the delegation chain is explicit and auditable. Dynamic agent identities in current frameworks often don't have a clean delegation chain — the "on behalf of" relationship may exist in the application logic without being expressed in the identity layer. In a buyer conversation: "The pattern exists in OIDC. The question is whether the agent framework is actually using it."
Comparison: Trait-Led Analysis
Structure note: This section uses trait-led analysis — running both identity types through the same set of dimensions in sequence. The alternative structures (clustering, scenario mapping) would risk drifting into authentication flows or permission scoping, which belong in 3.2 and 3.3 respectively. Trait-led keeps the comparison at the identity layer.
Lifespan. A service account's credential may be valid for 90 days, 180 days, or — in environments where rotation discipline has slipped — years. The account itself may outlive the application it was created for. A dynamic agent identity is designed to expire. The lifespan is measured in the duration of a single task. The gap between 90 days and 90 seconds is categorical. What "identity lifecycle" means is genuinely different for each.
Provisioning mechanism. Service accounts are provisioned by humans, usually through a ticketing workflow or a manual directory operation. Dynamic agent identities are provisioned by machines, at runtime, without human approval in the loop. The governance question moves upstream: instead of "who approved this account?" the relevant question is "what policy governed the system that created this account?" Most enterprise identity programs are not currently equipped to answer it.
Relationship to human identity. A service account authenticates as itself. It has no inherent relationship to any human user. A dynamic agent identity may carry scope delegated from the human who initiated the task. This is not a minor distinction. Compromising the agent identity is closer to compromising the human's access than compromising a service account — which means the blast radius calculation is different in ways that security architects will notice.
Governance model. Service account governance is mature. Inventory the accounts, vault the credentials, rotate on schedule, decommission when the application retires. The tooling exists. The processes exist. The audit frameworks exist. Dynamic agent identity governance is not mature. The identity may not be visible to the organization's identity infrastructure at all — it may exist only within the agent framework's internal state. "Governance" in this context often means "the orchestration layer has a policy, and we trust the orchestration layer."
What compromise looks like. A compromised service account credential gives an attacker persistent access to whatever the account was authorized to reach, for as long as the credential is valid. The blast radius is bounded by the account's permissions and extended by the credential's lifespan. A compromised dynamic agent identity gives an attacker access to whatever the agent was doing during that run — but the identity expires. The risk profile is different: lower persistence, but potentially higher immediate impact if the agent was operating with delegated human scope.
What existing tooling covers. Service accounts: PAM, secrets management, IGA, directory services. The coverage is not perfect — orphaned accounts, credential sprawl, and rotation gaps are real problems — but the tooling category exists and is well understood. Dynamic agent identities: the tooling category is still forming. Some PAM vendors are extending their platforms toward agent identity. Some identity governance vendors are building agent-specific modules. As of mid-2026, there is no settled answer for how to bring dynamic agent identities under the same governance envelope as service accounts, and anyone who tells a buyer otherwise is selling a roadmap, not a product.
The honest line on NHI. The "non-human identity" category, as it's being marketed right now, contains two things. The first is service accounts, bots, RPA processes, and other long-lived, statically provisioned identities. Security teams have been managing this for decades. The tooling is mature. The frameworks exist. Calling it "NHI" and attaching it to the AI narrative is a rebranding exercise, and buyers with any security depth will recognize it as such. The second is dynamic agent identities — short-lived, programmatically spawned, potentially carrying delegated human scope, invisible to most existing governance tooling. The concept of a non-human identity predates the AI narrative by decades. What makes dynamic agent identities a new problem is the combination of ephemeral lifespan, machine-driven provisioning, and human scope delegation. Existing tooling wasn't designed to close that gap. An AE who can draw this line in a conversation earns credibility. An AE who treats the entire NHI category as a novel AI-driven breakthrough loses it to the first security architect in the room.
Okta Concept Mapping: SCIM and the Lifecycle Expectation
SCIM was designed to automate identity lifecycle across systems — provisioning, updating, deprovisioning. It assumes identities have a lifecycle worth synchronizing. Where the analogy holds: for service accounts, SCIM-adjacent thinking applies. You can inventory them, track their state, and trigger deprovisioning when the application they serve is retired. Where it breaks: SCIM operates on a timescale of minutes to hours. A dynamic agent identity that expires in 90 seconds will never appear in a SCIM sync. The lifecycle is over before the protocol has time to observe it. In a buyer conversation: "SCIM solves the service account inventory problem. It has nothing to say about identities that don't survive long enough to be provisioned in the traditional sense."
How to Say This in the Field
| Don't say | Do say | Why it matters |
|---|---|---|
| "NHI is a new category that AI has created" | "Service accounts aren't new. What's new is identities that spawn and expire within a single agent run." | Buyers with security depth will push back on the first framing; the second earns trust. |
| "Agents have identities just like users do" | "Agents can carry scope delegated from a user — that's different from acting as that user, and it's different from a service account acting as itself." | Conflating agent identity with user identity creates liability questions buyers will catch. |
| "NHI means you need to rethink your entire identity program" | "Your service account governance is probably fine. The gap is in identities your current tooling can't observe because they don't live long enough." | Scoping the real problem is more credible than inflating it. |
| "We solve NHI" | "We've managed service account lifecycle for years. The open question is dynamic agent identities, and here's where the market is on that." | Honest capability framing beats overclaiming every time in a federal account. |
| "Non-human identities outnumber human identities 10 to 50 times" | "Non-human identities outnumber human identities significantly in most enterprise environments — that ratio is well-documented. The new pressure is that agent frameworks are adding to that count dynamically, at runtime, outside your current inventory." | The ratio is real; the framing that matters is what's driving the growth. |
| "Agent identities are just service accounts with a different name" | "Static service accounts and dynamic agent identities are both non-human identities. They have different lifecycles, different provisioning models, and different governance requirements." | Dismissing the distinction loses the conversation to vendors who can articulate it. |
| "Your PAM solution covers this" | "PAM covers your service accounts. It doesn't cover identities that expire before the vault has time to rotate them." | PAM vendors are extending toward agent identity; don't close the door on a real gap. |
| "The identity governance problem is the same as it's always been" | "The inventory and lifecycle problems are familiar. What's new is that the provisioning is happening inside the agent framework, not inside your identity infrastructure." | Acknowledges continuity while naming the actual new constraint. |
| "AI agents are the real NHI threat" | "The governance gap is specifically in short-lived, dynamically spawned identities — not in AI agents as a category." | Precision here prevents the conversation from becoming a fear pitch. |
| "We're still figuring this out" | "The tooling for dynamic agent identity governance is still forming. Here's what's available now and where the gaps are." | Honest uncertainty with structure is more useful than either false confidence or vague hedging. |
The buyer who brings up NHI in a discovery call is usually somewhere on a spectrum: they've read a vendor brief, they've had a conversation with their security team, or they've been asked by leadership to figure out what AI agents mean for their identity posture. In most cases, they're not wrong that something has changed — they're just not sure what. The AE who can walk them from "NHI is a big new problem" to "here's the part that's actually new, here's the part you already have tooling for, and here's where the gap is" has done something more valuable than a product pitch. They've made the problem legible. That's the conversation that gets you the next meeting.