Why CISOs Have Lost Track of Their Own AI Agents

A compliance briefing on identity, access control, and the agentic enterprise

Setting the Context

For most of the last two decades, identity and access management has revolved around one central assumption: the entity requesting access is a person. An employee, a contractor, a partner — someone with an HR record, a manager, and a reason to be there. That assumption is now breaking down at scale.

AI agents — software that can plan, make decisions, and take autonomous action across systems — have moved from pilot projects into production workflows at a pace security teams haven’t been able to match. And according to Okta’s newly released Global CISO Insights 2026 report, most CISOs know it. Fewer than half of CISOs are confident they can identify, control, and authorize every AI agent running in their environment. That’s not a minor visibility gap. It’s a structural governance failure playing out inside organizations that, in many cases, are already certified against information security standards built for a world of human users.

This article breaks down what the Okta findings actually reveal, why the problem is deeper than a tooling gap, and how it maps onto access-control obligations that already exist under ISO/IEC 27001 and ISO/IEC 42001 — obligations many organizations are quietly failing to extend to their non-human workforce.

What the Okta Report Found

Okta’s Global CISO Insights 2026 report surveyed more than 300 CISOs and security executives across the U.S., U.K., Japan, Germany, Canada, and France. The headline numbers are stark:

• Only 47% of CISOs feel confident they can identify all of the AI agents operating in their environment.
• Only 46% feel confident they can control what those agents are able to interact with.
• Only 45% feel confident they can authorize individual agent actions using context and intent.

Put plainly: more than half of security leaders cannot say with confidence what agents exist in their environment, what those agents can touch, or what they’re allowed to do once they get there. And this isn’t a fringe concern — 81% of CISOs surveyed said they worry their AI systems aren’t properly governed.

The report frames the fix around three deceptively simple questions every security leader should be able to answer: Where are my agents? What can they connect to? What can they do? Answering them is presented as the starting point for securing the agentic enterprise. Most organizations, it turns out, can’t answer even one with confidence.

Shadow AI Is Already Inside the Building

Part of the problem is that agents are frequently deployed without security ever being looped in. 68% of CISOs reported seeing at least some unauthorized AI use inside their organization — employees and teams spinning up agents to get work done faster, with or without approval.

This “shadow AI” pattern should feel familiar to anyone who lived through the early years of SaaS sprawl, when business units signed up for cloud tools faster than IT could track them. The difference is that shadow AI agents don’t just store data — they act. They read files, call APIs, move data between systems, and increasingly make decisions with minimal human review. A rogue SaaS subscription is a compliance headache. A rogue AI agent with standing access to a CRM, a code repository, or a file share is an active risk sitting inside your perimeter, indistinguishable at a glance from a legitimate business process.

Even “Authorized” Agents Aren’t Well Controlled

The more uncomfortable finding isn’t about shadow AI — it’s about the agents organizations do know about. Even among sanctioned deployments, access controls are loose:

• Roughly one-fifth of organizations let AI agents access network resources using shared credentials or highly permissioned, agent-specific accounts — both weak boundary models that make it nearly impossible to attribute an action to a single accountable entity.
• A similar share allow the teams that built an agent to manage its access entirely on their own, with no independent oversight.
• Only about a quarter of organizations manage AI agents through a dedicated, centralized access framework.

In other words, most organizations are applying the access-control equivalent of “whoever built it, owns it” to a class of identity that can act at machine speed, across multiple systems, without the natural friction — fatigue, hesitation, a second thought before clicking “approve” — that keeps human error somewhat contained.

Okta’s researchers describe local developer tools such as AI coding assistants as a particularly acute example: these often run directly on employee workstations, sit outside cloud-based security monitoring, and in many cases store credentials in plaintext — a blind spot that, per the report, ranks among the largest most enterprise agent security programs currently have.

The Root Cause: Human Identity Frameworks Applied to Non-Human Actors

Here’s the underlying issue that makes this hard to fix quickly: most identity and access governance programs were designed around human behavior. Onboarding and offboarding tied to employment status. Access reviews on a quarterly or annual cadence. Role-based access control built around job titles. Manual approval workflows that assume a person is on the other end, exercising judgment.

AI agents break nearly every one of those assumptions:

• They can be created in minutes by anyone with API access, not just IT.
• They don’t have a single “employment status” — an agent might be short-lived, spun up for one task, or persistent and constantly reused.
• They can call other agents, effectively delegating access without a human ever approving the downstream action.
• Their permissions tend to be granted generously up front (“give it what it might need”) rather than scoped tightly to the task at hand, because scoping dynamically is harder than it sounds.

Security leaders at RSAC 2026 made a version of this same point directly: an AI agent needs to be treated less like a static service account and more like a privileged session — requesting exactly what it needs, exactly when it needs it, and nothing more. Applying legacy identity governance to entities that behave this differently isn’t a small mismatch. It’s a structural gap, and it’s precisely the gap Okta’s data quantifies.

Where ISO/IEC 27001 and ISO/IEC 42001 Already Apply

Here’s the part that should get the attention of any GRC or compliance team: this isn’t an unregulated frontier waiting for new standards to catch up. Existing frameworks already speak directly to it — organizations are simply not extending the requirements to their agent fleets.

ISO/IEC 27001:2022, Annex A already contains the relevant obligations:

• A.5.15 (Access control) requires access to information and associated assets to be restricted and managed according to defined business and security requirements — a requirement that doesn’t stop applying just because the requester is software rather than a person.
• A.5.16 (Identity management) requires the full lifecycle of identities — registration, verification, and timely deregistration — to be managed, and identities to be uniquely attributable to one accountable entity. Shared credentials for agents are a direct conflict with this control.
• A.5.18 (Access rights) requires access rights to be provisioned, reviewed, and revoked in line with the organization’s access control policy, and reviewed at defined intervals.
• A.8.2 (Privileged access rights) requires the allocation and use of privileged access to be restricted and closely controlled — squarely relevant to agents holding broad, standing permissions across sensitive systems.

None of these controls needed to be rewritten for the AI era. They were written to be entity-agnostic. The gap isn’t in the standard — it’s in implementation, where “access control” quietly got scoped to mean “human user access control” without anyone deciding that explicitly.

ISO/IEC 42001:2023, the world’s first AI management system standard, adds a second, complementary layer. Its Annex A control set covers AI-specific concerns across the AI system lifecycle — including the resources, data, and organizational roles that support AI systems, and the ongoing monitoring and change management expected once systems are in operation. An organization running agentic AI without mapping agent access into both its ISO 27001 Statement of Applicability and its AI management system controls is, in practice, leaving a documented compliance gap that an auditor is increasingly likely to test for directly.

This is where the “nobody’s closing it” framing earns its place. The gap isn’t a lack of applicable standards. It’s the absence of a deliberate decision to extend existing, audited controls to a new category of identity — and the absence of evidence, when asked, that anyone made that decision at all.

Closing the Gap: Where to Start

Security leaders don’t need to build agent governance from scratch. The starting point is closing the same three questions Okta’s report frames as the benchmark, mapped onto existing control language:

1. Inventory every agent, human-created or otherwise. You cannot govern what you cannot see. This means treating agent discovery as a continuous process, not a one-time audit — new agents can be created faster than annual reviews can catch them.
2. Give every agent a unique, attributable identity. No shared service accounts, no generic “automation” logins. This directly satisfies A.5.16 and makes every subsequent control — logging, review, revocation — actually enforceable.
3. Scope access to task, not convenience. Default to least privilege and time-bound, context-aware permissions rather than broad standing access “just in case.” This is the practical application of A.5.15 and A.8.2 to non-human identities.
4. Bring agent access into the same review cadence as human access — or a tighter one. Given how quickly agent permissions can be created and reused, quarterly human-access reviews are often too slow for a fleet of agents that can spin up and act within hours.
5. Document the decision, not just the control. Under both ISO 27001 and ISO 42001, auditors don’t just want to see that a control exists — they want to see that leadership deliberately decided how AI agent access fits into the existing management system, with the rationale captured in the Statement of Applicability.

None of this requires waiting for a new standard. It requires treating agents as first-class identities under the frameworks organizations have often already implemented — and closing the accountability gap between “we have an access control policy” and “our access control policy actually governs the software making decisions on our behalf.”

Moving Forward

The Okta Global CISO Insights 2026 findings aren’t really a story about AI risk in the abstract. They’re a story about a specific, measurable failure: organizations extending trust to a new class of identity faster than they’re extending governance to match it. Fewer than half of CISOs can currently say with confidence what their AI agents are, what those agents can reach, or what they’re authorized to do — and that uncertainty sits on top of access-control obligations that many of those same organizations have already committed to under ISO/IEC 27001 and, increasingly, ISO/IEC 42001.

The good news is that this is a solvable problem with existing tools. It doesn’t require a new regulatory framework or a wholesale rebuild of the security program — it requires applying the identity and access discipline security teams already know how to do, to a category of identity that hasn’t been getting it. Organizations that treat this as an extension of their existing ISMS and AI management system work, rather than a separate AI problem, will be the ones that can actually answer Okta’s three questions when it matters — in an audit, in an incident review, or in front of a board that’s starting to ask harder questions about what, exactly, their AI agents are doing.

About the Author

EdTeam

Administrator

View All Posts