CISO AI uncertainty at RSAC 2026 reveals a control gap

At a glance

What this is: This interview argues that CISO AI uncertainty is a governance signal, not a leadership failure, because boards and security teams are still defining how to control AI risk in practice.

Why it matters: It matters because IAM, PAM, and network segmentation teams now have to govern AI agents, shadow AI, and AI-enabled workflows with the same discipline used for other non-human identities and privileged access.

By the numbers:

• By 2028, 50% of all enterprise cybersecurity incident response efforts will focus on incidents involving custom-built AI-driven applications.
• 97% of AI-related breaches occurred in organizations without proper AI access controls, and shadow AI was a factor in 20% of breaches, adding $670,000 to average breach costs.

👉 Read Elisity's interview on CISO AI uncertainty at RSAC 2026

Context

CISO AI uncertainty describes a security programme operating faster than its planning cycles can absorb. The problem is not hesitation, but the fact that AI risk, AI tooling, and governance expectations are all moving at once, which makes traditional rollout logic unreliable.

For IAM teams, the key issue is that AI systems are increasingly being treated as actors with access, reach, and operational impact. That shifts the discussion from model quality to identity, privilege, containment, and the practical limits of what an AI-enabled workflow should be allowed to touch.

Key questions

Q: How should security teams govern AI systems that can take actions on their own?

A: Security teams should govern AI systems as non-human identities with bounded reach, explicit ownership, and runtime containment. The main questions are what the system can authenticate to, what it can access, and how quickly access can be revoked if behaviour changes. That requires IAM, PAM, and segmentation controls to be designed together, not separately.

Q: Why do AI-enabled workflows increase blast radius risk?

A: AI-enabled workflows increase blast radius risk because they can combine access, decision-making, and tool use in one runtime path. If that path is broad, a single bad action can touch more systems than a human operator would normally reach. The practical response is to narrow exposure before deployment and verify what the system can actually touch.

Q: What do security teams get wrong about AI trust?

A: Teams often focus on whether the model is trustworthy instead of whether the surrounding control plane is bounded. A model can behave safely in one context and still create risk if its credentials, permissions, or tool reach are too broad. Governance should start with reachability, containment, and ownership.

Q: Who is accountable when an AI system causes an incident?

A: Accountability should sit with the team that approved the access scope, monitored the runtime boundary, and owned the response path. If no group can answer those three questions, the programme has treated AI as a feature instead of an identity-bearing actor. Clear ownership is a governance requirement, not an optional add-on.

Technical breakdown

Why AI agent identity turns containment into an IAM problem

An AI agent is not just software that returns text. In operational use, it may authenticate, call tools, retrieve data, and trigger downstream actions using credentials that look a lot like other non-human identities. Once that happens, the security question becomes who or what is authorised to act, what it can reach, and how its activity is constrained in runtime. This is where identity and network controls converge: permissions, segmentation, and logging must all describe the same trust boundary. If the agent can reach broad internal systems, the model itself becomes less important than the access path it carries.

Practical implication: Treat AI agent access as identity scope, not application convenience.

What blast radius means for AI systems with credentials

Blast radius is the amount of damage an identity can cause if it is misused, over-privileged, or compromised. For AI systems, that includes the data they can retrieve, the APIs they can invoke, and the internal systems they can touch without human review. The article’s core architectural point is that defenders cannot rely on predicting every model decision. They have to make the reachable environment narrow enough that a bad decision, prompt injection, or credential abuse cannot spread widely. This is the same logic used for privileged accounts, but the stakes rise when runtime decisions are partly delegated to software.

Practical implication: Map AI access to the smallest possible reachable set before deployment.

How zero trust and microsegmentation change AI governance

Zero trust architecture assumes breach and verifies continuously, while microsegmentation narrows lateral movement by limiting which systems can talk to each other. For AI agents, those ideas matter because the model may be dynamic even when the permissions are not. Security teams need to know not just whether the agent authenticated, but whether it can move beyond the exact workload or data domain it was intended to serve. That is especially important where AI is layered into existing business processes, because the governance failure often sits in the surrounding network and identity design rather than in the model itself.

Practical implication: Use zero trust boundaries to contain AI actions inside narrowly defined segments.

NHI Mgmt Group analysis

AI uncertainty is becoming an identity governance problem, not just a model governance problem. The article shows that boards are asking how much AI they can trust, but practitioners should be asking what identity an AI system uses, what it can access, and how its reach is contained. That is the governing question because the risk materialises through privilege, not language output. The implication is that AI governance now belongs in IAM, PAM, and segmentation planning, not only in AI policy discussions.

Blast-radius control is now the primary security variable for AI-enabled workflows. If an AI system can authenticate and act, the decisive issue is how far it can move when its credentials, prompts, or tools are abused. This is where zero trust and microsegmentation become operational rather than aspirational. Practitioners should treat containment as the first measure of AI readiness, because prediction alone will not keep pace with runtime behaviour.

The old assumption that access can be reviewed after deployment is already weakening. That assumption was designed for stable systems where privileges persisted long enough for governance cycles to observe them. It becomes less reliable when AI-driven workflows can chain actions quickly and amplify exposure before review catches up. The implication is that identity governance must shift from periodic visibility to tighter runtime boundaries and narrower authorisation scope.

CISO AI uncertainty: the real gap is not confidence, but the absence of a mature control model for AI actors with access. The article’s value is that it makes uncertainty explicit instead of hiding it behind marketing language. That honesty should be treated as a maturity signal, because programmes that admit incomplete control are the ones most likely to build durable governance. Practitioners should read that honesty as a prompt to define ownership, containment, and escalation paths before AI usage scales further.

From our research:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows that the control gap is behavioural as well as technical.
• For adjacent reading, LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how exposed credentials can become an AI attack path in minutes.

What this signals

AI reachability, not AI capability, will become the programme-level metric that matters. If security teams can describe what an AI system is allowed to reach in business terms, they can govern it. If they cannot, the programme is relying on optimism rather than control. That shift should push identity leaders to align IAM, PAM, and network segmentation around AI use cases before adoption spreads further.

Containment will increasingly define whether AI adoption is operationally defensible. The organisation that can show narrow, auditable AI reach will have a much stronger board story than the organisation that only talks about model risk. For practitioners, this means policy has to be translated into access boundaries, segmentation rules, and revocation workflows that actually operate at runtime.

For practitioners

• Define AI access as a privileged identity boundary Inventory every AI system that can authenticate, call tools, or reach enterprise data, then classify those paths with the same discipline used for privileged non-human identities. Link each access path to a named owner and a revocation point.
• Constrain AI workloads with explicit network segments Place AI-enabled applications and agents into narrowly scoped segments so the workload cannot reach broad internal services by default. Use this to limit lateral movement if prompts, credentials, or tool actions are abused.
• Replace confidence statements with reachability tests Before approving AI use cases, test what the system can actually reach under valid credentials, then document the reachable data sets, APIs, and downstream automations. This gives the board a concrete control view instead of a vague assurance.
• Build incident playbooks for AI-driven workflows Create response steps for compromised AI credentials, unexpected tool use, and unapproved data access so teams know how to contain the workflow before it fans out across the environment.

Key takeaways

• CISO AI uncertainty is best read as a control gap, not a leadership gap, because the operating model for AI risk is still forming.
• The most important question is what an AI system can reach, because runtime access determines the size of the blast radius.
• Identity teams should treat AI governance as a containment problem and align IAM, PAM, and segmentation before the next wave of adoption.

Key terms

• AI Agent Identity: The identity used by an AI system when it authenticates to tools, APIs, or data sources. For governance purposes, it should be treated as a non-human identity with explicit ownership, narrow scope, and a clear revocation path when behaviour changes.
• Blast Radius: The amount of damage an identity can cause if it is abused, compromised, or over-privileged. In AI environments, blast radius includes data access, tool invocation, and downstream automation that can spread impact far beyond the original action.
• Microsegmentation: A network control approach that limits which systems can communicate with each other. For AI and other non-human identities, it reduces lateral movement by keeping runtime access inside tightly defined zones rather than broad shared environments.
• CISO AI Uncertainty: A security operating condition where AI risk changes faster than planning, policy, and control cycles can absorb. It does not mean indecision. It means the programme must govern with incomplete certainty and tighter runtime constraints.

What's in the full article

Elisity's full article covers the interview detail this post intentionally leaves at the governance level:

• The full RSAC interview context around Joan Goodchild's panel observations and board-room questions.
• The 60/9/30 board framing in more detail, including how CISOs can explain controlled, compensated, and moving-risk areas.
• The article's discussion of AI agents, microsegmentation, and why reachability matters more than abstract model trust.
• The surrounding RSAC commentary on AI uncertainty, awareness training, and emerging AI security expectations.

👉 The full Elisity post includes the RSAC discussion, the 60/9/30 board frame, and the AI agent containment angle.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity programme, it is worth exploring.