During a quarterly access review, an application owner sees a line item for a service account with write access to the purchasing system. The request ticket from eight months ago says “invoice reconciliation pilot.” The pilot owner moved to a different business unit in March. The scheduled runs are still using the account. The manager approves the access renewal because denying it might break a process they do not understand.
Identity and access management was built on a binary foundation. There are humans who join, move, and leave. There are applications that get provisioned, updated, and retired. AI agents are neither. They are a third principal type, and the enterprise identity governance process only has two buckets.
When a project team needs to deploy an agent, it needs to access systems. The IAM team has a backlog for new service accounts. The path of least resistance is to use the developer’s delegated token or a shared integration account. If the agent uses the developer’s token, it inherits every permission that user has accumulated over a decade of project work, role transfers, and exception requests. The agent does not know the difference between a permission needed for today’s task and a forgotten artifact from a migration five years ago. If the agent uses a shared service account, every invocation gets the same broad reach. The cryptographic link between the user’s request and the agent’s action is severed.
This becomes a forensic failure the first time something goes wrong. A security operations center gets an alert that an account is mass-downloading files from a restricted drive and sending them to an external API. The analyst locks the account and pages the user. The user is asleep and has never seen the agent. The threat is a summarization workflow running on a scheduled job. The audit log proves a token was used. It does not show which agent used it, what prompt triggered the logic, or which human originally authorized the workflow. A token proves the call was permitted by a system. It does not prove the call was authorized for the task.
In architecture reviews, teams often rely on the system prompt to enforce boundaries. A security architect asks what prevents a customer-service agent from pulling the entire database. The lead engineer explains that the system prompt instructs the model not to do that. A system prompt is not an access-control boundary. A model instructed to only read data will eventually find a way to write data if the identity token it holds has write permissions. The model hallucinating is an engineering problem. The model hallucinating and having write-access to the production database is a security failure.
The deeper issue is lifecycle management. You cannot put an HR hold on a Python script. When an employee leaves, the offboarding workflow disables their identity, revokes their tokens, and transfers their files. It does not touch the agent they created. If the agent was built on a separately consented connector or a standalone service account, it keeps running. The organization has to build a transfer-of-ownership workflow specifically for autonomous processes, requiring a new human to accept risk for the agent’s actions before the original creator leaves. Most enterprises do not have this workflow.
Treating an agent as a distinct principal solves the naming problem, but it does not solve the ownership problem. The agent needs an identity registered in a system of record, but that identity must be tied to a business object. An access review cannot just ask if a credential is still in use; it must ask what the agent is still doing. The reviewer needs the agent’s purpose, the sponsoring team, the connected systems, and the permitted actions. An unfamiliar principal name in a certification queue gives a manager no basis to approve it.
Approval must also attach to a specific action, not just general access. Allowing an agent to help with supplier maintenance is different from approving a change to a named supplier’s bank details. The latter requires the proposed values and the approver’s identity to be recorded before execution. An approval buried in a chat transcript is hard to match to a transaction posted under an integration account.
The audit trail must bind the user’s identity, the specific prompt, the model’s output, the required approvals, and the resulting API action into a single record. If the default token log is the only evidence, the audit trail is answering the wrong question.
The identity governance platform has a process for onboarding a person and a process for onboarding an application. It needs a third process for something that is neither.