Artificial intelligence (AI) is no longer used only to generate text. AI agents can change code, update databases, create accounts, call external services, and manage cloud infrastructure.
Organizations already manage human identities, such as employee and contractor accounts. They also manage non-human identities for applications, services, machines, and automated processes. These identities help systems understand who or what is requesting access and what actions are allowed.
AI agents are a new type of non-human identity. But they are different from many traditional applications. An AI agent can choose its next step, use different tools, act for a person, or work with its own access rights.
This creates a new security problem. An AI agent may use a shared service account or a person’s credentials. In this case, the audit log may show the account but not the AI agent that used it.
A separate identity for each AI agent can make its actions easier to track. It can connect the agent to the person or system that gave it the task, the credentials and permissions it used, the systems it accessed, and the actions it performed.
AI Agents Have Already Caused Real Incidents
Recent incidents show how an agent’s mistake can become destructive when it has broad access.
PocketOS: A Database Deleted in Nine Seconds
In April 2026, an AI coding agent deleted the production database of PocketOS in nine seconds. Recovery took about 60 hours, during which customers could not use important parts of the service.
PocketOS explained in its account of the incident that the agent had permissions it should not have had. The system did not require additional confirmation before the destructive operation. Recovery was also delayed because the company’s regular backup process had stopped working several months earlier.
PocketOS later added human confirmation for destructive actions and changed its backup and recovery procedures.
DataTalks.Club: A Terraform Command Reached Production
Claude Code was involved in a similar incident at DataTalks.Club. A Terraform command removed production infrastructure, including a database with two and a half years of course submissions. Automated snapshots were deleted as well.
The operator said that the incident was his fault. He had allowed the AI assistant to run Terraform commands that could affect production infrastructure. His description of what happened shows that the AI model was not the only cause of the incident.
The agent selected and ran the command, but the surrounding conditions made the damage possible. A person assigned the task. A credential provided access. The infrastructure allowed the command to reach production.
PaperCut: AI Agents Used at Scale
AI agents can also be used by attackers. In August 2026, GreyNoise reported that a malicious actor used hundreds of AI agents to exploit vulnerable PaperCut servers. At least 440 installations across 395 organizations in 48 countries were compromised. Credentials were collected from 280 affected systems, and the attacker gained domain administrator rights in 12 organizations.
Unlike the PocketOS and DataTalks.Club cases, these agents did not have trusted internal access. They were controlled by an external attacker. The GreyNoise investigation shows how quickly agent-driven attacks can grow once access is available.
Up to 100 Targets in Five Days
In September 2026, a Chinese-speaking attacker used AI agents based on Claude, DeepSeek, and Kimi in a large cyberattack campaign. According to Forbes, which reported on findings from Gambit Security, the attacker targeted up to 100 organizations between September 10 and 15.
The agents helped find vulnerabilities, enter systems, steal data, and hide evidence of the attacks. Researchers found data from more than 600,000 credit cards in the attack infrastructure. The affected organizations included companies in the travel, hospitality, retail, and industrial sectors.
The total cost of the operation was about $8,000. Some individual attacks cost only a few dollars. This shows how AI agents can help one person run many attacks at high speed and relatively low cost.
The human operator still remained part of the operation. The person selected the targets and gave the agents instructions. The agents then performed many of the technical steps. This connection between the human operator, the agents, their access, and their actions is important for understanding who was behind the attack.
These incidents are different, but each involves the same chain: an agent, a credential, a set of permissions, a target system, and a human or organization behind the activity.
The Log Shows an Account. Does It Show the Actor?
Suppose a production database has been deleted.
The audit log shows a valid account. The system accepted its credential, and the account had permission to perform the operation. From the system’s point of view, the request was valid.
The account name does not reveal whether the command came directly from an employee, an application, or an AI agent. It does not show whether the agent had its own credential or used the employee’s access. Nor does it show whether the person approved that specific operation or only gave the agent a general task.
The organization can see which account reached the system, but it may not be able to reconstruct the path from the original instruction to the deleted database.
The log may show the credential. It may not show the actor.
Figure 1. A traceable identity chain connects the original human request to the agent’s final action.
An AI Agent Needs More Than a Credential
A digital identity is the information a system uses to recognize a person or machine. It may contain an identifier, credentials, attributes, permissions, an owner, and a record of previous actions.
A credential is part of an identity, but the two are not the same. A password, key, certificate, or token proves that the requester possesses something accepted by the system. It does not necessarily show who is using it or for what purpose.
There is no single, universally accepted model of AI agent identity. An identity could represent the whole agent system, one running instance, one session, or a temporary agent created for a specific task. In some environments, agent identity simply means the account or token available to the agent.
The boundary of the agent can also be difficult to define. The agent may include the AI model, the software controlling it, the connected tools, and the current session. It may create sub-agents and give them parts of the original task.
A concept paper from the National Institute of Standards and Technology (NIST) examines many of these unresolved questions. They include whether an agent identity should be permanent or temporary and how it should be connected to people, software, hardware, and organizations.
Today, an AI agent may have its own identity, use an application identity, work through a user’s account, or rely on a shared token. Each approach produces a different audit record.
If several agents share one account, the log may not identify the agent that performed an action. If an agent uses a person’s credential, its activity may appear to be direct human activity.
Giving an AI agent an identity does not mean treating it as a person. The purpose is to make the machine actor distinguishable from other users and systems.
Where Identity Security Fits
Organizations already manage identities for services, applications, workloads, and automated scripts. These non-human identities use accounts, keys, certificates, and tokens to access business systems.
AI agents resemble this identity category, but they do not always follow a fixed sequence of operations. An agent can receive a general objective, choose its own steps, change its plan, and use several tools to complete the task. The path from instruction to action is therefore harder to predict.
Passing authentication does not make every following action safe. A valid token may give an agent access to a system, including operations that are unnecessary for its task.
For example, an agent may be asked to investigate a problem in a test environment. While working, it finds a credential that can also access production. The production system accepts the credential, and its permissions allow deletion. The command is technically authorized even though it is outside the task assigned by the user.
NIST has warned that sharing credentials with agents creates gaps in accountability. Its guidance on agentic AI and identity recommends treating agents as separate entities with their own identifiers, credentials, and permissions linked to the person or system operating them.
This preserves an important distinction. The human identity shows who requested the work. The agent identity shows which machine actor performed it. Authorization defines the limits of the delegated access.
AI Agent Identity Is the Next Step for Identity Security
AI security can no longer stop at protecting models and data. When an AI agent can use credentials, call tools, access information, and change business systems, it also becomes an identity and access issue.
Organizations already manage access for employees, applications, service accounts, and machines. AI agents must now become part of the same security program. An organization should be able to see which agent performed an action, who gave it the task, which identity it used, what permissions it had, and which systems it accessed.
The industry is still at an early stage. There is no common model for AI agent identity. There is also no single standard for connecting agents to people, applications, and systems. Different technology providers are developing their own approaches, while common security practices are only beginning to appear.
Organizations should not wait for one universal standard. They can already separate human and agent activity, limit agent permissions, connect each agent to an owner, and keep clear records of important actions.
The next step for identity security is to manage people, machines, and AI agents as part of one trusted environment. Every important action should be connected to a clear identity, limited permissions, an accountable owner, and a reliable audit record. Without this chain, an organization may know what happened but still be unable to explain who or what caused it.
__________________________________________________________________
Axidian develops identity security products for authentication, privileged access management, public key infrastructure (PKI) management, and identity threat detection and response.
