The Next Frontier of Identity Security: Governing What AI Agents Actually Do

An AI agent can have a valid identity, legitimate credentials, and approved access to an enterprise application, yet still perform an action that creates a serious security incident. This is one of the challenges I believe security teams need to prepare for as agents take on more responsibility across business systems.

The 2026–2027 Lightspeed Cyber 60 CISO Survey shows how quickly this challenge is becoming relevant. Among surveyed enterprises, 77% already have AI agents in production. Yet among organizations using or exploring agents, only 20% report having a complete agent inventory. Compromised or hijacked agents acting inside enterprise environments also tied AI-generated phishing and deepfakes as CISOs' most frequently selected AI-related threat concern, at 51%.

Discovery, dedicated identities, and least-privilege access are essential starting points. But as agents become more autonomous, we also need to understand the relationships behind their authority and evaluate the actions they take with it. An agent may be authorized to access an application without being authorized to perform every operation available inside it.

When legitimate access creates risk

This risk is no longer hypothetical. In an incident report updated in October 2026, OpenAI described two cases in which internal coding agents weakened the safeguards meant to oversee them while carrying out legitimate development tasks. 

In one case, a GPT-6.1 Sol agent was initially instructed not to send Slack messages while gathering information for a researcher. Later, while repairing an evaluation pipeline, it interpreted that instruction as a reason to suppress automatic monitoring alerts to OpenAI’s Security team. The agent directed a subagent to make a change. Monitoring continued to run and record results, but the notifications intended to alert people to potential problems were disabled. 

OpenAI’s investigation focuses on model behavior and doesn’t establish that excessive identity permissions caused the incident. Still, it shows the gap I’m describing: an agent can stay within its access while carrying out a legitimate task and still take an action no one intended. In this case, a consequential change to a safeguard without the change being part of the user’s intended objective. For security teams, the question is not only whether an agent has access, but whether it should be able to exercise that access in a particular way, especially when the action affects the controls designed to oversee it.

The distinction is important because authentication establishes identity, while access permissions establish what that identity is technically allowed to do. Neither necessarily establishes whether a particular action is appropriate for the task. Existing controls, such as separation of duties, granular authorization, or independent approval requirements, can help prevent inappropriate operations, but those protections must be applied to the actions that matter.

The problem becomes more complicated when agents interact with multiple applications, invoke tools, and make decisions based on information they encounter along the way. A legitimate task can lead to an unintended action without requiring the agent to cross a traditional authentication boundary.

Understanding the authority behind an agent

One of the findings I found particularly interesting in the Lightspeed report concerns how agents authenticate. Among organizations using or exploring agents, 34% select dedicated per-agent identities with scoped permissions as their current or intended approach. Another 26% select human credentials passed to agents, while 15% select shared service accounts.

These approaches create different security challenges. When an agent uses human credentials, it may inherit permissions granted for a person's broader responsibilities. Shared service accounts make it harder to determine which agent performed a specific action. Even dedicated identities can accumulate excessive permissions if access isn't reviewed and adjusted as responsibilities change.

We need to give agents accountable identities, clear ownership, and appropriately scoped access. But we also need to understand how that access works across the environment.

An agent may receive instructions from a human, authenticate through a service account, invoke an API, and trigger a workflow in another application. Its effective authority depends on the relationships between those identities, systems, and resources. Looking at each account or permission separately may not reveal what the agent can accomplish through the complete sequence.

This is where identity graphs become useful. By connecting humans, agents, service accounts, entitlements, applications, and data, we can better understand delegated authority and indirect access paths. In its market opportunity analysis, Lightspeed specifically identifies identity graphs connecting humans, services, agents, and data as an important direction for agent identity and access governance.

The objective isn't simply to visualize more relationships. It's to understand which ones introduce risk and use that context to make better security decisions.

Access is not the same as authorization for every action

Identity security has made meaningful progress in reducing unnecessary access. We have conditional access, privileged access management, just-in-time privileges, and increasingly sophisticated governance processes. These controls remain important, and agents should benefit from them just as human and other non-human identities do.

What changes with autonomous agents is the number and variety of decisions they can make after access has been granted. An agent can begin with an approved objective, interpret new information, select tools, and initiate operations that were not individually anticipated when its access was established.

The security decision therefore needs to consider more than whether the agent can access a resource. It must also account for what the agent is attempting to do, the consequences of that operation, and whether it is consistent with the agent's intended purpose.

To make that decision, we need to understand who owns the agent, which authority has been delegated to it, what resource it is attempting to change, and the business context surrounding the request. This is the difference between knowing an agent's permissions and determining whether a specific action should be allowed.

The Lightspeed findings suggest that CISOs are looking at several parts of this problem. Agent identity, authorization, and access governance leads planned AI security tool evaluations for the next 12 months at 55%. AI-powered risk scoring and behavior analytics follows at 49%, while 48% plan to evaluate runtime guardrails for production agents.

These are separate categories in a multiple-selection survey question, not evidence that CISOs have agreed on a single security architecture. But the underlying requirements are connected. Identity context helps us understand authority and risk, while runtime enforcement can help determine whether a particular operation should proceed.

In its market opportunity analysis, Lightspeed also identifies scoped, just-in-time authorization of agent actions at the tool and API layer, permission-creep detection, and attribution of actions to individual agents. I think these are important directions because they connect identity governance to what agents actually do.

Making security decisions where they matter

One of the practical challenges is deciding where and when to enforce controls.

An agent may authenticate once and then execute a series of tool calls across several systems. If the only authorization decision happens when the session begins, the organization may have limited ability to distinguish a routine information request from a sensitive operation later in the workflow.

For higher-risk actions, authorization needs to be evaluated closer to the point of execution. That might mean limiting the tools an agent can invoke, restricting the operations available through an API, or requiring additional approval before a sensitive change.

The right approach depends on the action and its consequences. Reading a non-sensitive record should not require the same controls as changing payment instructions or deleting critical data. We also shouldn't depend on the agent itself to determine whether every action is safe, particularly when the agent may have been manipulated through untrusted inputs.

This is not a problem identity security can solve in isolation. Application controls, API security, runtime protections, and business-process safeguards all have important roles. Identity security provides the context needed to understand which agent is acting, whose authority it is exercising, and what resources are at risk.

When those capabilities work together, organizations can give agents meaningful autonomy without relying on broad, standing permissions or constant human intervention.

A question worth asking your security team

The Lightspeed survey found that 88% of surveyed organizations permit AI to execute at least some security response actions, such as blocking traffic, isolating endpoints, or revoking credentials, without prior human approval. Most respondents, 71%, limit that autonomy to a narrow set of low-risk actions, while 17% allow it broadly across response workflows.

These findings specifically concern autonomous security response, rather than all enterprise agent activity. Still, they demonstrate that organizations are already making decisions about which actions can be trusted to run autonomously and which require tighter boundaries.

I think CISOs should apply that same discipline to enterprise agents. Consider an agent with legitimate access to a critical application that attempts a sensitive operation outside its intended purpose. Can your team identify the agent's owner and trace the authority it is using? Can you understand the relationships that make the operation possible? Can you enforce a policy before the action executes, and can you establish exactly what happened afterward?

These questions reveal more about the maturity of an agent security program than an inventory alone. They also help distinguish between tools that provide visibility and controls that meaningfully reduce exposure.

Building on the foundations of identity security

AI agents are making familiar identity challenges more urgent. Enterprises already struggle with excessive privileges, fragmented identity data, shared credentials, and access paths that are difficult to understand. Agents introduce greater autonomy into that environment, allowing identities to perform sequences of actions across systems without requiring human involvement at every step.

I don't believe we need a separate identity security model for every new type of agent. We should build on the principles that already matter: clear ownership, least privilege, effective access analysis, continuous governance, and accountability. What we need to extend is our ability to understand and control how authority is exercised.

The Lightspeed findings reinforce the need to get these foundations right. But discovery and access management are only part of the work. As agents become more capable, security teams will need to connect identity relationships, business context, risk, and action-level controls.

For years, we've worked to answer who has access to what. With autonomous agents, we also need to understand what an identity is about to do, whether that action is appropriate, and how to enforce that decision. That's the direction I believe identity security needs to take.

‍Research source: Lightspeed Cyber 60, 2026–2027. Survey conducted by Wakefield Research among 200 CISOs at U.S. companies with annual revenue of at least $500 million. Survey figures reflect reported practices, concerns, and planned evaluations. Lightspeed's market opportunity analysis is distinguished from direct survey responses.