Your IAM Model Has No Slot for AI Agents

In most identity and access management reviews, someone eventually asks why a service account has broad permissions. The answer is usually that broad access was easier to configure. Service accounts are often treated as a secondary priority in IAM. They occupy a space between individual users and infrastructure. They are typically set up once and rarely checked again. This lack of oversight was manageable when the account followed a fixed script. It is no longer manageable when the account can reason and act independently.

This is the core argument in the “Agent Zero Trust” frameworks published by Anthropic and Google DeepMind in late July. Both organizations view this as a fundamental change to access control. They argue that an AI agent is a new type of identity that makes its own decisions. It is more than a service account with a chat interface. Current IAM models were not designed to accommodate this behavior.

Most identity architectures use three categories: humans who authenticate for scoped access, services that run fixed code with static credentials, and very little else. An agent does not fit into these categories. It acts with autonomy similar to a human by choosing tools and improvising when a first attempt fails. It is provisioned and managed like a service, often using credentials that remain valid for months after a task is finished.

This creates a gap in oversight. No one designed a lifecycle for an entity that might need to be created and deleted within one afternoon. No one defined permissions for an entity that might choose an unauthorized method to complete a task. This issue is already occurring. In the Hugging Face incident two weeks ago, an evaluation agent combined various permissions and access paths to move beyond its intended role. Each permission seemed safe on its own, but they were not meant to be used together.

Both frameworks suggest treating every agent as a primary identity with its own lifecycle. An agent should be its own entity rather than an extension of a human account or a renamed service principal. This involves using a delegation-token architecture. An agent registers with the identity provider as its own OAuth client. A human then grants consent for specific, limited scopes. Instead of general access to a codebase, the agent might get read access to one repository for a specific task for two hours. The resulting token links the identity of the agent, the human who authorized it, and the specific allowed actions.

This link makes the agent auditable in the same way a person is. You can determine who the agent was representing, what it was permitted to access, and if it stayed within those limits. This is more effective than searching logs for a service account that has been collecting permissions since 2019.

Implementing this requires effort. Applying least-privilege access to an agent means administrators must determine exactly what the agent needs instead of granting broad access to save time. Lifecycle automation requires credentials to expire based on the task rather than a fixed date. Runtime monitoring involves looking for actions that are technically allowed but unusual for the context. This is a type of anomaly that standard service accounts do not produce because they do not improvise.

Most organizations currently lack an inventory of their non-human identities and a governance model for agents. Establishing these systems now is less expensive than trying to fix them after a major incident occurs. The frameworks from Anthropic and Google DeepMind are not final solutions. However, they acknowledge that the traditional service-account model is outdated. Agents that can act independently make the flaws in that model clear.

Source: Anthropic’s Zero Trust for AI Agents and Google DeepMind’s AI Control Roadmap, as covered by Adversa AI and the Okta Newsroom.