When a new kind of actor shows up in the enterprise, security teams reach for the closest existing category. For AI agents, that category has been the non-human identity (NHI). Agents aren't people, they authenticate with credentials, and they call APIs. So they get a service account, an API key, or a workload identity, and they're added to the NHI inventory next to the CI pipeline and the nightly backup job.
It's an understandable move, and it's the wrong one. NHIs were built for software that does the same thing every time. Agents don't. Treating them as NHIs creates identities that are over-permissioned, hard to audit, and disconnected from the humans who are actually accountable for what the agent does. And it adds them to an NHI inventory that most security teams struggle to see and own.
What NHIs were designed for
The NHI model assumes a workload with a fixed purpose. A payment reconciliation service reads from one database and writes to another. A deployment pipeline pushes artifacts to a known set of environments. Because the behavior is predictable, you can scope permissions once, rotate the credential on a schedule, and trust that the access you granted matches the access the workload uses.
This model works because intent is encoded in code. The code decides what the service does, and it doesn't change unless someone ships a new version. The identity only has to answer one question: is this the workload we expect?
Agents break every one of those assumptions
An AI agent's behavior is decided at runtime, not at deploy time. The same agent might summarize a contract in the morning, update a CRM record at noon, and draft an email to a customer in the afternoon. Its actions are shaped by the prompt it receives, the data it reads, and the reasoning it performs along the way. Its intent is not in its code. Its intent comes from whoever asked it to do something, and from whatever it encounters while doing it.
That difference has concrete consequences for identity.
Security teams already lack visibility into which NHIs exist and who owns them. This adds more identities with more access to the pile they can't see. Most security teams already struggle to answer basic questions about their non-human identities: what exists, who owns it, and what it can reach. Agents make that worse.
Static permissions don't fit dynamic tasks. To give an agent a single NHI that covers everything it might do, you have to grant the union of every possible task. The result is a standing credential with broad access that is only ever partly needed. That is exactly the over-privileged, long-lived identity that NHI security programs spend their time trying to eliminate.
The human disappears from the chain. Most agents act on behalf of a person. When a user asks an agent to pull last quarter's pipeline numbers, the question that matters is whether that user is allowed to see those numbers. A service account can't answer it. The agent authenticates as itself, the downstream system sees a trusted NHI, and the user's own entitlements never enter the decision. The agent becomes a privilege escalation path for anyone who can talk to it.
Audit trails lose their meaning. When something goes wrong, an NHI log tells you that svc-agent-prod read a sensitive file. It doesn't tell you which user prompted the action, what task the agent was pursuing, or whether a malicious instruction in a document redirected it. For a deterministic workload, the service identity is the whole story. For an agent, it's barely the first line.
Delegation is recursive. Agents increasingly call other agents and tools, which call further tools. Each hop needs to carry forward who the original requester was and what they authorized. NHIs have no native concept of a delegation chain. Every hop authenticates as its own isolated identity, and the context of the original request is lost.
Lifecycles don't match. NHIs are provisioned for long-running services. Agents are often spun up for a single session or task and discarded. Managing them with the same provisioning and rotation processes either creates identity sprawl or pushes teams to reuse one shared credential across many agents, which makes attribution impossible.
Sharing an agent silently shares its credentials. Agent configurations bundle tools, data connections, and credentials, and many platforms let builders share them organization-wide unless an admin has restricted it. When an agent runs on an embedded NHI, everyone it's shared with inherits that NHI's access without requesting or being approved for it. Because this happens outside the identity system, security has no record of who can use the credential.
Prompt injection makes it worse
The NHI model assumes that an authenticated workload is behaving as intended. With agents, authentication tells you almost nothing about intent. An agent with a perfectly valid credential can be steered by instructions hidden in an email, a web page, or a support ticket. If that agent holds a broad, standing NHI, the attacker inherits all of it. Critically, the risk is greatest with autonomous agents. They run unattended, are often triggered by the very content an attacker controls, and have no human in the loop to notice when they've been redirected.
This is why the blast radius of an agent identity matters more than that of any traditional workload. The question isn't just whether the credential is protected. It's how much damage the agent can do when its reasoning is compromised, even with a legitimate credential in hand.
What agent identity should look like instead
Agents need to be treated as their own identity class, with properties that neither human identities nor NHIs fully provide.
An agent identity should be bound to a human sponsor or requester. Every action should trace back to a person who is accountable for it, and the agent's effective permissions should never exceed that person's.
Access should be delegated, not owned. Instead of holding standing permissions, the agent should receive scoped, short-lived tokens that represent a specific user's authority for a specific task. Standards work around on-behalf-of flows and token exchange points in this direction.
Permissions should be granted just in time and scoped to the task. An agent working on a contract review doesn't need write access to the finance system, even if it needed that access yesterday.
High-risk actions should require human confirmation. Sending money, deleting data, or changing access policy are points where the agent should pause and ask, regardless of what its credentials technically allow.
Audit logs should capture the full delegation chain to make incidents investigable, audit logs should capture the full delegation chain: the human who initiated the request, the agent that acted, any sub-agents or tools involved, and the task context.
And regarding sub-agents specifically, agents should only be able to spawn subagents up to a fixed depth. A good analogy comes from cell biology: healthy cells have a built-in limit on how many times they can divide, and when that limit fails, growth becomes uncontrolled. Agent recursion needs the same kind of hard stop.
Finally, agents need their own lifecycle management: registration, ownership, review, and decommissioning that match how agents are actually built and retired, rather than inheriting the processes built for long-lived services.
How NewCore approaches agent identity
NewCore was built on the premise this post argues for: agents need their own identity model, not a slot in the NHI inventory. In NewCore, AI agents are first-class identities with their own lifecycles, trust scores and revocation paths, rather than standard service accounts. That directly answers the lifecycle mismatch described above. An agent that exists for one task can be registered, governed and retired on its own terms, instead of inheriting processes designed for long-running services.
It also closes the gap between agents and the people behind them. NewCore discovers, secures and governs human and agentic identities in a single architecture, so an agent's access is managed in the same place as the access of the humans who sponsor it and ask it to act. Accountability stays connected instead of splitting across two disconnected systems.
Sprawl and shared credentials, two of the most common side effects of the NHI approach, are addressed through continuous discovery of shadow accounts, orphaned credentials and unmanaged agents. For the agents developers already use every day, NewCore integrates with coding assistants like Claude Code, Codex and Cursor so they reach enterprise systems as managed identities rather than through manually shared credentials. Every action is attributable to a specific agent, not to a key passed around a team.
And because a compromised agent holding a valid credential is the scenario that matters most, the underlying infrastructure is built to limit damage. NewCore's split-key architecture divides identity credentials between the customer and the platform, so no single party holds a complete credential.
Identity platforms can only take accountability so far on their own. When an agent reaches a downstream system that recognizes only two kinds of users, humans and service accounts, it gets flattened into one of them, and the record of who it is and who it acts for is lost at the point where the action actually happens. We're calling on identity and service providers to support agents as a distinct user type in their systems: provisioned as agents, authorized under policies written for agents, and logged with both the agent and its human sponsor attached to every action. Without that, accountability ends at the edge of the identity platform. With it, an organization can trace any agent action back to a specific agent and a specific person, no matter which system it touched.
Agents combine the autonomy of a human user with the scale and speed of software. Putting them behind service accounts treats them as neither. NewCore treats them as what they are: a new kind of workforce that needs identity, governance and accountability built for it from the start, everywhere they operate.