Introduction
We live in an age where we need to consider different types of identity in the world from an information technology, and more importantly, a cybersecurity perspective. There are human identities such as those that work at an organization (the workforce) or patronize it (the customer). We know these identities well: they’re you and me.
The other type of identity is what we refer to as non-human identities. These identity objects are broadly categorized as service accounts and agentic identities. The most important distinction between them is in the scope of their access.
| Identity Type | Scope of Operation | Boundary | Primary Risk Profile |
|---|---|---|---|
| Service Accounts | Manage applications and background jobs | Stays within network perimeter | Overprivileged access on local network |
| Agentic Identities | Crosses boundaries to external APIs and users | Traverses the public internet | Data exfiltration, prompt injection, cascading API failure |
Service accounts manage applications and services within the organization’s network and might use machine learning or even AI as part of their tasks, but these objects do not leave the network perimeter.
Agents are designed to leave the network when necessary. When the resources they need aren’t on the local network, agents can work with assets over the internet, communicating with humans, external services, and other agents. This is the inherent risk when it comes to agentic identities and tools: when they’re not properly scoped and secured, incidents such as the July 2026 OpenAI/Hugging Face incident could occur.
Both human and non-human identities must be managed and protected under Zero Trust principles, with explicit authentication, least-privilege authorization, lifecycle governance, continuous evaluation, and auditable accountability. Although they share common IAM foundations, differences in autonomy, delegation, credential management, and execution context require distinct controls.
The human identity
As we discussed in the beginning of this article, we are all familiar with the broad outlines of human identity. All human identities are managed by the following process:
- Creating the identity
- Updating the identity (as needed)
- Removing the identity
Most readers will likely be familiar with these concepts. In addition to the general lifecycle of the identity, it’s important to consider that we must manage and govern the identity to make sure that the identity’s data and attributes are accurate and up to date. We also need to periodically review the entitlements (such as application access, physical access, and so on) given to the identity to ensure that the identity is not underprivileged or overprivileged.
The agentic identity
Much like the human identity, agentic identities follow a lifecycle that is more about how the agent is used by its users along with its creation and maintenance as a tool. The foundational difference of an agentic identity from a human one is in the basic attribute schema that is used to store the agentic identity.
The SCIM Agentic Identity Schema draft, section 3, specifically calls for the identity type of AgenticIdentity to differentiate between the human and agentic identities. Specific attributes in the schema, such as oAuthClientIdentifiers, audiences, and owners, speak to the fact that agentic identities should have specific requirements for authentication and scope, and for the relationship between an agentic identity and the humans managing or using the agent.
Next, we need to consider the relationship between a given agent, its owners, and its users. There are specific attributes that distinguish owners/managers of the agent and who is running the agent. Concepts such as the ownerId and sponsorID attributes determine those within the organization that are responsible for the agent’s operation. Then there are concepts such as onBehalfOf and scope that show who is using the agent, and what that agent is permitted to do. This implies that responsible creation and management of agents require that there be clean evidence of the person who owns/manages the agent, the abilities of the agent, and those who are using the agent. This information would be critical for understanding who needs to be part of troubleshooting in the event of agents not working as expected.
To enhance agentic execution security, organizations can apply fine-grained authorization policies to attributes such as actionID, executionMode, and tool_ID. These attributes describe what the agent is attempting to do, how it will execute the operation, and which tool it will use. Policies can also evaluate resourceType, dataClassification, and tokenExpiry to determine whether the requested action is appropriate, sufficiently constrained, and still authorized.
This approach adds a control layer beyond the LLM, prompts, and skills, providing policy decision, policy enforcement, identity, credential, tool, data loss prevention, monitoring, and approval controls. Instead of relying solely on how the agent was designed, organizations can govern the agent as an identity object with explicit, externally enforced permissions as policy decision points and policy enforcement points. The result is a policy decision based on the agent, the represented user, the requested action, the target resource, the execution context, and the authorization lifetime.
If there is an event where the agent is not working as expected, those responsible need to be brought in to understand how the agent is working, and we want to know who the user that invoked the agent is to understand how they were using the agent. For example, if the agent is doing more than what was expected, we need to know how it was designed and from the user end, what did they ask that caused the unexpected behavior.
One of the most far-reaching developments concerns the idea of a successionPlan attribute, a draft schema concept that I encountered when researching this article. This idea specifically calls for having a backup human identity to be referenced should the specified owner/manager not be available. This successionPlan attribute would certainly be a part of any “break glass” workflows if there was an issue with the management or behavior of an agentic identity. I would consider this to be a best practice at the moment for the schema of any agent. Fortunately, Ping Identity’s tools allow for schema modification in this respect.
Authorization management serves as another essential pillar: the privileges assigned to an agent ought to be scoped to the active end user during each individual interaction. By leveraging protocols such as token exchange, the system delegates specific entitlements to the agent instead of impersonating or inheriting the user’s complete access rights—a critical distinction that ensures precise audit records. Additionally, these temporary permissions should expire immediately after execution and must not carry over between distinct requests, even if subsequent users share identical access criteria.
This also means that there must be tools and processes in place to govern all agents and make sure that they’re compliant with lifecycle and privilege requirements. Ideally, this is through a central interface that is discovering and governing all agents in the enterprise.
Conclusion
All of these factors need to be considered when developing an approach to agentic identity management. In order to create a comprehensive, secure approach that embraces Zero Trust, the following tools/concepts should be in place.
- Agentic LCM: Ensure that all agents are created and managed according to a set process.
- Agentic privilege management: An agent’s access should be delegated from the human who is using it.
- Agentic governance: Agentic identities should be regularly reviewed to make sure that their lifecycle and privileges configurations are complete and correct.
Agentic identity management is more than an extension of traditional identity management or an agent attribute schema. It is a layered cybersecurity discipline that combines distinct agent identities, delegated and least-privilege access, runtime authorization, continuous monitoring, auditability, and human oversight. By enforcing these controls outside the AI model, organizations can preserve accountability while enabling agents to operate securely across users, tools, systems, and trust boundaries.
Further reading
Readers might want to explore the following links, which were referenced directly or indirectly in this entry:
- CNN on the July 2026 OpenAI/Hugging Face AI security incident
- Dark Reading: Blame rogue AI for security failures
- Ping Identity: Agentic AI identity fundamentals
- IETF agentproto working group (datatracker)
- IETF draft: SCIM Agentic Identity Schema (draft-wahl-scim-agent-schema-01)
- PingAuthorize product page
Join the discussion on the Ping Identity developer community.
