AI cybersecurity companies in 2026 expose an IAM governance gap

At a glance

What this is: This roundup looks at how AI is being used in cybersecurity in 2026 and finds that the real issue is not feature adoption, but whether IAM governance can keep pace with AI-driven action and accountability.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern systems that can initiate actions faster than human review cycles, and that changes how access, authority, and oversight should be designed.

Context

AI cybersecurity now covers both using AI to defend environments and governing AI systems that participate in security work. The article’s central point is that these are not the same problem, because one is a capability layer and the other is an identity governance challenge.

For IAM teams, the key question is whether existing access models can still answer who is acting, what they can do, and how accountability is assigned when AI participates in detection, response, or other security execution.

Key questions

Q: How should security teams govern AI agents that inherit authority from other identities?

A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What is the difference between securing AI and using AI for security?

A: Securing AI protects models, data, and pipelines from attack. Using AI for security applies machine learning to improve detection, prioritisation, and response. Both matter, but they solve different problems. A mature programme needs controls for the AI system itself, not only AI-assisted security operations.

Q: How do organisations know whether AI is truly under governance control?

A: They should be able to show where AI is recommend-only, where it can act, who owns each AI identity, what evidence is logged, and how access is revoked. If those answers live in different tools or are informal knowledge, the programme does not yet have defensible control over AI.

Technical breakdown

AI in cybersecurity versus securing AI systems

The article’s FAQ draws a useful distinction between AI-powered security and securing AI itself. The first uses models to improve detection, triage, and response. The second asks how those models, agents, and surrounding services are authenticated, authorised, and governed. That distinction matters because security teams often evaluate AI as a capability while underestimating the identity layer that lets it operate. If the system can trigger actions, call tools, or influence workflows, it is no longer just analytics. It becomes an identity-bearing participant in the security stack.

Practical implication: evaluate AI initiatives as both capability deployments and identity-governed systems.

Why AI agents change the access model

AI agents are not just automated scripts with better language output. When an agent can choose actions at runtime and execute them through connected tools, the access model has to cover decision authority, not just permission grants. That shifts the control problem from static entitlements to runtime governance, because the risk sits in what the system can do in context, not only in what it was provisioned to do. This is where traditional reviews struggle: they examine assignment, but agentic systems need controls around invocation, tool use, and delegated authority.

Practical implication: govern agent access at execution time, not only at provisioning time.

IAM accountability becomes a design issue

The article’s question set points to a broader governance gap: organisations still rely on human-centric accountability models even as AI participates more directly in security operations. If an AI system initiates detection actions, response steps, or policy-driven changes, the programme must define who approves the scope, who owns the outcomes, and who can revoke authority. Without that clarity, AI becomes a shared responsibility nobody can actually operationalise. Identity governance has to track decision rights as carefully as credentials.

Practical implication: map AI decision rights to named owners before allowing operational use.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security is now an identity governance problem, not just a tooling category. The article shows organisations using AI across defence workflows, but that does not remove the need for authority and accountability controls. Once AI participates in operational decisions, IAM and IGA have to govern execution rights, not just access requests. The practical conclusion is that AI security programmes and identity programmes can no longer be treated as separate workstreams.

Agentic behaviour collapses the assumption that access is always human-paced. Traditional IAM assumes that permissions are granted to people or services that act within a predictable review cycle. That assumption fails when an AI agent can act at runtime, because authority may be exercised before a human can observe, certify, or revoke it. The implication is that governance has to move from periodic review to runtime control over delegated action.

Security teams need a named concept for the gap between model capability and governed authority: execution without accountability. This is the point where AI can influence or initiate action faster than identity controls can attribute responsibility. The article surfaces that tension through its FAQ framing, even if it does not spell out a control model. The practitioner takeaway is that every AI-enabled security use case should be tested for who owns the action path, not just who owns the model.

Securing AI and using AI for security demand different control stacks. The former is about authenticating the system, constraining its access, and governing its runtime behaviour. The latter is about improving detection and response. Conflating them creates false confidence, because a model that helps defend the environment may still introduce new identity and privilege risks of its own. The programme response is to separate capability evaluation from governance evaluation.

The market signal is clear: AI cybersecurity vendors are being judged on governance fit, not just detection claims. The article’s FAQ emphasis suggests buyers are asking whether vendor claims map to real operational controls. That shifts scrutiny toward identity boundaries, accountability, and privilege scope. The practitioner conclusion is that AI security selection now belongs in the identity architecture conversation, not only in the SOC tooling conversation.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Execution without accountability: AI-assisted security workflows can expand faster than IAM review models if organisations do not separate recommendation rights from action rights. That distinction matters because the control failure is not just overprivilege, but unclear ownership of the decision path.

Identity programmes should treat AI-enabled security functions as governed actors with explicit authority boundaries. Without that shift, periodic certification will keep lagging behind systems that can trigger actions in real time.

For practitioners

• Define AI authority boundaries Document which AI use cases may initiate, recommend, or execute actions, and which require human approval. Separate observation-only use cases from systems that can change state.
• Review delegated access paths Inventory every account, token, or service relationship that lets an AI system call tools, query data, or trigger workflows. Treat those paths as governed identity relationships, not just integrations.
• Assign accountable owners to AI actions Name a business and technical owner for each AI-enabled workflow so responsibility exists before the system is permitted to act in production.
• Separate model risk from identity risk Assess AI security capabilities and AI governance controls as distinct review tracks, with one focused on model behaviour and one focused on access, privilege, and revocation.

Key takeaways

• AI security use cases are only safe when the organisation can say exactly what the system is authorised to do.
• The governance gap is about delegated authority, accountability, and runtime action, not just AI model quality.
• IAM, IGA, and PAM teams should evaluate AI initiatives as identity-bound workflows before they reach production.

Key terms

• AI-Powered Security: Security tooling that uses machine learning or generative models to help detect, correlate, prioritise, or respond to threats. The AI is the method of defence, not the thing being defended. In practice, value comes from better decisions, lower noise, and faster containment, not from the label alone.
• Securing AI: Securing AI means protecting the AI system itself, including its data, prompts, tools, permissions, and outputs. For identity teams, this becomes a governance problem when the system can access secrets, call APIs, or act with delegated authority.
• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.

Deepen your knowledge

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