AI Agents Are Becoming Digital Identities. Security Architecture Isn’t Ready.

For years, identity and access management was built around a fairly stable assumption: a person, application, or service requests access to a system, and that access can be controlled through authentication, authorization, and policy. AI agents are beginning to challenge that model.

Unlike traditional applications, agents are increasingly capable of acting on behalf of users, interacting with multiple systems, making decisions, invoking tools, retrieving sensitive data, and carrying out tasks with limited human involvement. In practical terms, this means they are starting to behave less like software features and more like digital identities. That distinction matters.

A chatbot that answers questions from a static knowledge base is not particularly difficult to reason about from an identity perspective. An agent that can read email, update a CRM record, query cloud infrastructure, generate code, create support tickets, or approve workflow steps is different. It can take action. It can make decisions within a defined context. It can interact with systems that traditionally expect either a human identity or a machine identity.

Most security architectures were not designed with this type of actor in mind. The result is a growing mismatch between what AI agents are being asked to do and the controls available to govern them.

Traditional identity models were simpler

Enterprise identity architecture has historically revolved around a few familiar categories. There are human identities, such as employees, contractors, administrators, and customers. There are service accounts used by applications. There are workloads, APIs, devices, and other non-human entities that authenticate using keys, certificates, tokens, or managed identities. Each of these categories has well-established control models.

Human users are typically governed through identity providers, multifactor authentication, role-based access control, conditional access, privileged access management, and lifecycle processes for onboarding, transfers, and termination. Service accounts and applications are handled differently, often through secrets management, machine identities, workload identity, and tightly scoped permissions. AI agents do not fit neatly into either category.

An agent may technically authenticate using a service account, but its behaviour may be driven by instructions from a human user. It may inherit the user’s access, act using application credentials, or combine both. It may be capable of deciding which tools to use, what data to retrieve, and what actions to perform. This creates an identity problem that is not just technical but conceptual.

If an AI agent sends an email, changes a customer record, modifies a cloud configuration, or submits a transaction, who performed the action? Was it the user, the agent, the service account behind the agent, or the application through which the agent operated? In many environments today, the answer is not always clear.

Delegated access becomes much more complicated

The security industry is familiar with delegation. Users authorize applications to access resources on their behalf every day. OAuth, API tokens, delegated permissions, and service principals are all established mechanisms. AI agents make delegation more difficult because they introduce greater autonomy.

A user might ask an agent to “review these support tickets and resolve the straightforward ones.” That sounds harmless until the agent is given enough access to modify customer records, issue refunds, change account settings, or trigger downstream workflows.

The user has not necessarily instructed the agent exactly what to do in every case. The agent is interpreting intent and taking action. This creates a gap between authorization and behaviour.

Traditional access control asks whether an identity is allowed to perform an action. With autonomous agents, the harder question becomes whether the agent should perform that action in this context, for this purpose, at this time. Those are not the same question.

A user may be authorized to refund a customer up to $1,000. That does not necessarily mean an AI agent acting on behalf of that user should have unrestricted authority to issue hundreds of refunds automatically. The underlying permission may be valid, while the delegated behaviour is still unsafe.

Excessive privilege will become an agent problem

Most organizations already struggle with excessive access. Employees accumulate permissions over time, service accounts are frequently overprivileged, and application integrations are often granted broader access than necessary because narrowing permissions can be operationally difficult. AI agents have the potential to magnify this problem.

An agent becomes more useful as it gains access to more systems. If it can read calendars, email, documents, CRM records, ticketing systems, cloud consoles, and internal databases, it can perform increasingly complex tasks. That usefulness creates pressure to expand permissions.

A compromised employee account may expose one identity. A compromised AI agent with broad access could become a highly capable intermediary across multiple systems. If the agent can retrieve information from one environment and act in another, the impact of a credential compromise, prompt manipulation, misconfiguration, or faulty decision can become much larger. This is particularly concerning when agents are granted standing access.

One of the lessons identity teams have learned from privileged access management is that permanent privilege creates unnecessary exposure. The same principle should apply to agents. Access should be scoped, time-bound, contextual, and ideally issued only when required.

Yet many early AI deployments are moving in the opposite direction. Agents are often given broad API permissions simply because that is the easiest way to make them useful. That approach may work during experimentation. It does not scale safely.

Identity governance will need to include agents

Most identity governance programmes focus on people. They ask whether employees still need access, whether privileged roles are justified, whether terminated users have been removed, and whether managers periodically review entitlements. AI agents will need similar governance.

Organizations will need to know which agents exist, who owns them, what systems they can access, which credentials they use, what data they can retrieve, what actions they are allowed to perform, and whether those permissions are still appropriate. This sounds straightforward, but it becomes difficult very quickly.

An organization may deploy one agent for HR, another for IT support, several in software development, and others across finance, customer service, security operations, and procurement. Different teams may build agents using different platforms, each with its own connectors, tokens, permissions, and integration models. Without proper governance, agent sprawl could start to resemble the service account problem many organizations already have, only with greater autonomy.

Consider an AI agent created to support the finance team. Initially, it is given access to invoices and expense records. Later, someone connects it to procurement data. Then it receives access to email so it can contact vendors. Eventually, it is allowed to update payment status in an internal system. Over time, the agent has quietly accumulated a significant level of business authority. If no identity governance process exists for reviewing that access, the organization may not even realize how powerful the agent has become.

Audit trails will become more important, not less

Another challenge is accountability. Security teams are accustomed to reviewing logs that show which identity performed an action. If an administrator changes a firewall rule, the event can usually be attributed to a user account. If a service modifies a record, the application identity can be traced. AI agents complicate attribution because there may be multiple layers of identity involved.

A user instructs the agent. The agent interprets the request. The agent invokes a tool. The tool authenticates to another application. That application records the action under a service account. A conventional audit log may show only the service account.

Organizations will increasingly need to reconstruct the full chain of action: which user initiated the request, which agent interpreted it, what instructions or context influenced the decision, which tools were invoked, what permissions were used, and what changes resulted. Without this level of traceability, incident investigation becomes much harder.

Imagine an agent deletes a set of cloud resources. The infrastructure logs show that a service principal performed the deletion. Was the deletion requested by an authorized administrator? Did the agent misunderstand an instruction? Was the agent manipulated through malicious input? Was the service principal itself compromised? Those are very different security events, but they may look identical if identity and activity logs are not designed to distinguish them.

Zero Trust principles apply, but the architecture needs to evolve

Many of the principles required to secure AI agents are not new. Least privilege, strong authentication, continuous authorization, segmentation, activity monitoring, separation of duties, just-in-time access, and explicit trust decisions are already central to modern security architecture. The challenge is applying them to actors that are partially autonomous and capable of operating across multiple systems.

A Zero Trust model should assume that an agent is not inherently trustworthy simply because it was created by an internal team or is acting on behalf of an authenticated user. Its access should be evaluated based on context.

What task is it performing? Which user authorized that task? What system is being accessed? What level of risk is associated with the action? Is the requested activity consistent with normal behaviour? Does the action require human approval? Some activities may be appropriate for full automation. Others should require confirmation.

An agent might be allowed to retrieve a document without intervention but require approval before changing payroll information. It might be allowed to restart a development service but not a production database. It may be permitted to draft an email but require a human to send it if the content contains regulated information. The security architecture must distinguish between reading, recommending, preparing, and executing. Those distinctions are essential if AI agents are going to operate safely at scale.

AI security is becoming an identity problem

Much of the discussion around AI security has focused on model risks such as prompt injection, data leakage, model manipulation, hallucination, and training data exposure. Those risks remain important. But as AI systems become more agentic, identity may become one of the most important control layers.

An agent that cannot access sensitive systems has limited ability to cause harm. An agent with broad privileges can turn a model-level weakness into an enterprise-level incident.

Prompt injection becomes more serious when the agent can execute commands. A hallucination becomes more serious when the output can modify production data. A compromised session becomes more serious when the agent has persistent access to several critical systems. The security impact of an AI failure therefore depends heavily on identity and authorization. This means AI security cannot remain separate from IAM, PAM, application security, cloud security, and governance. These disciplines will need to converge.

The architecture needs to catch up

Organizations adopting AI agents should begin treating them as first-class identities rather than invisible features inside applications. Each agent should have a clearly defined owner. Its permissions should be documented and reviewed. Credentials should be managed securely. Access should be restricted to the minimum required. High-risk actions should require additional controls. Agent activity should be logged in enough detail to support investigation and accountability.

Just as importantly, organizations need to resist the temptation to give agents broad authority simply because it makes the technology more impressive. The more autonomous the agent becomes, the more important identity becomes. AI agents are not replacing identity architecture. They are exposing where that architecture was designed for a simpler world.

The central security question is no longer just whether a user or application should be trusted. It is whether an autonomous digital actor should be allowed to act, under whose authority, within what limits, and with what level of accountability. That is a very different problem. And most enterprise security architectures are only beginning to confront it.