Your AI Agents Have Identities. Are You Managing Them?

Identity in Action | Part 2 of 5

The next generation of nonhuman identities is arriving, and most enterprise IAM programs have some catching up to do.

For years, organizations have struggled to manage the growing population of nonhuman identities operating throughout their environments. Service accounts, application identities, API credentials, automation platforms, and machine identities have become essential components of modern enterprise architecture. Unfortunately, they have also become some of the least understood and most inconsistently governed identities in the enterprise.

Now we're introducing artificial intelligence agents into that environment. These agents can independently execute tasks, interact with enterprise applications, invoke APIs, access sensitive information, and make decisions about how to accomplish their objectives. Unlike traditional applications, which generally execute predefined logic, autonomous agents can select tools, adapt their approach, and initiate sequences of actions without requiring a human to approve every step.

If we haven't figured out how to consistently manage the service accounts we created twenty years ago, adding autonomous AI agents to the mix should make for an interesting few years.

The challenge isn't simply that AI agents represent another category of nonhuman identity. It's that these identities may exercise considerable discretion over how they use the access they've been granted. An application service account typically performs a reasonably predictable set of operations. An AI agent may pursue the same business objective through several different paths, interacting with systems and invoking capabilities that its designers did not anticipate.

That difference has significant implications for Identity and Access Management. Before organizations begin granting AI agents access to critical business systems, they need to answer a deceptively simple question:

The Service Account Problem Just Got More Interesting

Consider a common enterprise scenario. An organization deploys an AI agent to assist its finance department with processing vendor invoices. The agent retrieves invoices, validates purchase orders, checks payment records, and identifies discrepancies requiring attention. Eventually, the organization wants the agent to handle routine exceptions automatically, reducing the amount of manual intervention required.

To perform these tasks, the agent needs access to the organization's enterprise resource planning system, document repository, vendor database, and several internal APIs. The development team needs to get the integration working, so it follows a familiar approach: create a service account, assign the necessary permissions, configure the credentials, and connect the agent to the applications.

Everything works beautifully. The agent processes invoices, the finance team saves time, and management celebrates another successful AI initiative.

Six months later, someone in security asks a few questions. Who owns the service account? Which AI agents are using it? Why does it have permission to modify vendor banking information when its original purpose was invoice reconciliation? Are its credentials shared across development, testing, and production? What happens if the agent begins invoking an API that wasn't part of its original design?

Suddenly, the conversation becomes considerably less celebratory.

This is a hypothetical example, but the underlying identity management problems are familiar. Organizations have spent years discovering service accounts with excessive privileges, unclear ownership, embedded credentials, and permissions that have accumulated long after their original business purpose changed.

Autonomous AI doesn't create these weaknesses, but it can amplify their consequences. An overly privileged service account used by a conventional application may expose capabilities that are rarely exercised because the application follows relatively predictable execution paths. An AI agent using the same account may discover and invoke those capabilities while attempting to accomplish an assigned objective.

The credentials haven't changed, and the permissions haven't changed. What has changed is the behavior of the software exercising those permissions.

An AI Agent Needs More Than a Service Account

The first architectural consideration is establishing a reliable identity for each AI agent or independently operating agent instance.

This does not necessarily mean creating a separate directory account for every execution of every agent. The appropriate identity model depends on the architecture, the agent's responsibilities, its operating environment, and the level of accountability required. However, organizations should be able to distinguish agents that have different responsibilities, permissions, ownership, or security boundaries.

A useful approach is to separate the identity of the agent from the identity of the human or system that initiated its work. If an employee asks an AI assistant to retrieve customer information, the organization should understand both who initiated the request and which agent performed the subsequent actions.

Those identities serve different purposes. The employee's identity establishes the requesting principal and may help determine the business authority behind the request. The agent's identity establishes which software entity is interacting with enterprise resources and provides a basis for applying controls, recording activity, and investigating incidents.

Conflating the two creates accountability problems. If every action performed by an agent appears in audit logs as an action performed directly by the employee, security teams may struggle to distinguish human activity from autonomous execution. Conversely, if every agent operates through a shared service account, the organization may know that an automated process accessed a system without knowing which agent was responsible.

Effective identity architecture should preserve these distinctions while maintaining a clear relationship between the requesting user, the executing agent, and the resources being accessed.

Authentication Is Only the Beginning

Once an agent has an identity, it needs a secure way to authenticate to the systems it uses. For many enterprise environments, OAuth 2.0, workload identity federation, certificate-based authentication, and other established machine authentication mechanisms provide useful building blocks.

The appropriate mechanism depends on the application and trust relationships involved. An agent accessing an OAuth-protected API may obtain a narrowly scoped access token, while an agent running in a cloud environment may use workload identity federation to obtain credentials without storing a long-lived secret. Other integrations may require certificates or existing enterprise authentication mechanisms.

What organizations should avoid is allowing convenience to dictate the security architecture. Embedding static API keys in agent configurations, sharing credentials among unrelated agents, or granting broad permissions to simplify integration creates many of the same problems that have plagued traditional service accounts.

Credential lifecycle management becomes particularly important when agents operate autonomously. Credentials should be issued through controlled processes, protected against disclosure, limited in scope and duration where practical, and revoked when no longer required. Organizations also need to understand where credentials are stored, whether agents can access or reproduce them, and how quickly access can be terminated during a security incident.

The October 2026 guidance from NIST, NSA, and CISA, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, reinforces these principles. Among its recommendations are limiting agent access to what is necessary for intended tasks, restricting network connectivity, and implementing mechanisms to rapidly block or terminate unauthorized agent activity.

The publication primarily addresses highly capable super intelligence agents, rather than prescribing an enterprise IAM architecture. Nevertheless, its emphasis on least privilege, credential control, and containment is directly relevant to organizations deploying autonomous agents into production environments.

Just Because an Agent Can Doesn't Mean It Should

Authentication establishes an agent's identity. Authorization determines what that identity is permitted to do, and this is where autonomous agents introduce some particularly interesting challenges.

Returning to our invoice processing example, the agent may legitimately need permission to retrieve vendor information, examine invoices, and verify payment status. It probably doesn't need unrestricted permission to modify vendor banking details, approve payments above established thresholds, or create new administrative accounts in the financial system.

The problem arises when the agent's technical permissions exceed its intended business responsibilities. If the underlying service account possesses broad access, the agent may be technically capable of performing operations that were never part of its assigned task.

This is why authorization should be enforced by the systems and services controlling the protected resources, rather than relying exclusively on instructions telling an agent what it should or should not do.

An instruction such as "never modify vendor banking information" may help define intended behavior, but it is not a substitute for an authorization policy that prevents the operation. If modifying banking information is outside the agent's responsibilities, the API or application should reject that action regardless of how the agent arrived at the decision to attempt it.

This distinction becomes even more important as organizations introduce agents capable of discovering available tools and selecting among them. A tool being available to an agent should not automatically mean every operation exposed by that tool is authorized.

The objective is to establish enforceable boundaries between what an agent is technically capable of doing and what the organization has authorized it to do.

Delegated Authority: Whose Permissions Are We Using?

One of the more complicated questions arises when an AI agent performs work on behalf of a human user.

Suppose a sales representative asks an AI assistant to prepare a customer proposal. The assistant needs to retrieve account information from the CRM, review previous transactions, and obtain pricing information from another enterprise application.

Should the agent access those systems using its own permissions, the employee's permissions, or some combination of the two? There isn't a universal answer, but the distinction matters.

In some situations, the agent is performing a task directly on behalf of a user, and access should be constrained by that user's authority. In others, the agent performs an independent business function and may require its own application permissions. Some workflows involve both models, with the agent acting on behalf of a user for certain operations while using separately authorized application capabilities for others. The security architecture must account for these differences.

Where delegation is appropriate, organizations should preserve the relationship between the requesting user and the executing agent while ensuring that delegated permissions are limited to the intended purpose. OAuth-based delegation mechanisms and token exchange can support aspects of this model, provided the applications and authorization infrastructure are designed to enforce the resulting restrictions.

An important principle is that delegation should not become an opportunity for privilege escalation. An agent acting on behalf of an employee should not automatically gain access to resources the employee cannot access, nor should it be permitted to use unrelated service account privileges to circumvent those restrictions.

There is another complication. Increasingly sophisticated agent architectures may involve multiple agents collaborating to accomplish a task. One agent may retrieve information, another may analyze it, and a third may initiate an action based on the results.

Each delegation introduces another trust relationship and another opportunity for permissions to expand beyond their intended scope. Organizations need to understand how authority is transferred between agents, how that authority is constrained, and how the resulting actions can be attributed to the appropriate identities.

This is an area where established IAM principles remain highly relevant, but their implementation requires careful consideration of the agent architecture.

Who Owns the Agent?

Identity governance is frequently discussed in terms of access certifications, provisioning, deprovisioning, and compliance. Those capabilities remain important, but autonomous AI introduces additional questions about ownership and accountability.

Every production AI agent should have an identifiable business owner responsible for its purpose and an accountable technical owner responsible for its implementation and operation. These responsibilities may reside with different individuals or teams, but they should not be ambiguous.

The business owner should understand why the agent exists, what business processes it supports, and which categories of information or transactions it is authorized to access. The technical owner should understand how the agent authenticates, which tools and integrations it uses, how its permissions are enforced, and how its activity can be monitored or terminated.

Governance processes should connect these responsibilities to the agent's identity and access lifecycle.

When an agent is introduced, its access should be reviewed and approved according to its intended responsibilities. When its capabilities expand, its permissions should be reassessed. When an agent is replaced, retired, or no longer required, its credentials and access should be removed.

This sounds familiar because it is fundamentally the same lifecycle management discipline organizations should already apply to human and nonhuman identities.

The difference is that an agent's responsibilities and capabilities may evolve more rapidly than those of a conventional service account. Changes to available tools, orchestration logic, integrations, or operational objectives can alter what an agent is capable of doing without necessarily changing its underlying identity.

Consequently, governance should consider not only the permissions assigned to an agent, but also the capabilities available through the tools and systems it can invoke.

An access review that confirms an agent still needs an API credential may be insufficient if nobody examines what that API credential actually allows the agent to accomplish.

When an Agent Goes Rogue, Can You Stop It?

The first article in this series examined the possibility of autonomous agents taking actions outside their intended operating boundaries. Establishing identity, implementing least privilege, and governing access are essential preventive measures, but organizations must also prepare for situations in which those controls fail.

The NIST, NSA, and CISA guidance recommends mechanisms to detect unexpected activity, preserve evidence, revoke exposed credentials, and terminate agent activity when control failures occur. It also emphasizes verifying that containment measures are effective before resuming operations.

From an IAM perspective, this raises several practical questions.

Can the organization immediately revoke an agent's credentials without disrupting unrelated applications? Can it identify every active session or token associated with the agent? Can authorization policies be changed quickly enough to prevent additional sensitive operations? Can the organization determine whether the agent delegated access to another agent or established an alternative path to the same resources?

These questions highlight why shared credentials and poorly documented integrations are especially problematic. If several agents use the same service account, disabling that account may interrupt legitimate business processes while still leaving uncertainty about which agent caused the incident.

Short-lived credentials, distinct agent identities, centralized authorization, and well-defined termination procedures can reduce these challenges. However, credential revocation alone may not immediately invalidate every previously issued token or terminate every active operation. Effective containment may also require enforcement at API gateways, application authorization points, orchestration platforms, and the infrastructure hosting the agent.

Identity is a critical component of containment, but it must operate as part of a broader security architecture.

Extending IAM to the Autonomous Enterprise

Organizations do not necessarily need to replace their existing IAM infrastructure to support autonomous AI. Many of the capabilities required to manage agent identities already exist within modern identity platforms, including authentication, token issuance, federation, authorization, privileged access controls, identity governance, and audit integration.

The challenge is determining whether those capabilities are being applied appropriately to AI agents and identifying where additional controls are necessary.

An organization beginning this evaluation should first establish visibility into the agents operating within its environment. It should understand which agents exist, who owns them, what business functions they perform, which systems they access, and what credentials or identities they use.

The next step is to evaluate whether those identities have appropriate permissions and whether the organization's authorization architecture can enforce meaningful restrictions on agent activity. This includes examining the APIs and tools available to agents, the relationships between human and agent identities, and the mechanisms used to delegate authority.

Finally, organizations should assess how agent identities are governed throughout their lifecycle and how quickly access can be restricted or terminated when necessary. These activities should be coordinated with security operations, AI engineering, and application teams to ensure that identity controls align with monitoring and incident response capabilities.

The objective is not to introduce unnecessary complexity into AI adoption. It is to establish a security foundation that allows organizations to benefit from autonomous technology without losing control over the identities and permissions operating within their environments.

The Identity Fusion Perspective

At Identity Fusion, we've spent years helping organizations address the complexities of enterprise identity architecture, authentication, authorization, and governance. One lesson that consistently emerges from those engagements is that identity problems rarely become easier when organizations introduce new technologies without first considering how those technologies will be governed.

Autonomous AI is no exception.

The introduction of AI agents creates an opportunity for organizations to revisit how they manage nonhuman identities, particularly in environments where service accounts, application credentials, and machine identities have historically received less governance attention than human users.

Rather than treating AI agents as an entirely separate security problem, organizations should evaluate how established IAM principles can be extended to accommodate their unique capabilities. That means creating attributable identities, enforcing least privilege, establishing clear ownership, managing credentials throughout their lifecycle, and maintaining the ability to revoke access when circumstances require it.

It also means recognizing that traditional IAM capabilities may need to be supplemented by additional controls for agent orchestration, behavioral monitoring, and runtime authorization.

The organizations that approach this challenge systematically will be better positioned to introduce autonomous AI into critical business processes while maintaining appropriate security and accountability.

After all, we've spent decades trying to ensure that the right people have the right access to the right resources. Now we're introducing software that can independently decide how to use that access.

Perhaps we should make sure we know who these new identities are before handing them the keys to the kingdom.

What's Next in the Identity in Action Series?

In our next article, "Beyond Authentication: Detecting When AI Agents Cross the Line," we'll explore why knowing an agent's identity and controlling its permissions are only part of the solution. We'll examine how organizations can monitor autonomous behavior, recognize when agents exceed their intended boundaries, and respond before an unexpected action becomes a significant security incident.

More articles in the Identity in Action Series:

When AI Agents Go Rouge: Why Identity Is the First Line of Defense

Identity Fusion helps organizations design, implement, and strengthen enterprise Identity and Access Management programs. Our expertise spans identity architecture, authentication, authorization, identity governance, privileged access, and the integration of identity security controls across complex enterprise environments.

As organizations explore autonomous AI, understanding how existing identity capabilities can support this new class of nonhuman identity is an important first step toward secure adoption.

Source(s): NIST CAISSI, NSA SISC, and CISA, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, October 2026.