AI cybersecurity vendors still split defense from AI security

At a glance

What this is: This is an analysis of AI cybersecurity vendor categories, with the key finding that buyers must separate AI-powered defense from security for AI before evaluating platforms.

Why it matters: It matters because identity, cloud, and security teams need different controls for endpoints, workloads, and AI systems, and conflating those problems leads to blind spots in NHI, autonomous, and human identity governance.

By the numbers:

• 84% of organizations now use AI in the cloud and 62% already run at least one vulnerable AI package.
• 80% of organizations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Orca Security's analysis of AI cybersecurity providers and cloud risk

Context

AI cybersecurity is the use of machine learning and generative models to detect, prioritise, and respond to threats, but the market now spans two different problems: defending traditional systems with AI and securing the AI systems themselves. For identity programmes, that split matters because the controls for endpoints, cloud workloads, and AI agents are not interchangeable.

Orca Security’s article is useful because it frames the buying problem around coverage, explainability, and control boundaries rather than marketing labels. The central issue for practitioners is whether a platform can see exposure paths, understand who or what holds access, and keep human approval where autonomy is not justified.

Key questions

Q: How should security teams evaluate AI cybersecurity platforms for cloud-native environments?

A: Start by checking whether the platform ranks risk using exposure, identity reach, and data adjacency, not just severity scores. Then confirm it can inventory AI workloads and the secrets or service identities they depend on. A cloud-native platform should reduce uncertainty about reachable blast radius, not just produce more findings.

Q: Why do agentic AI systems require different governance than AI assistants?

A: AI assistants can help humans decide, but agentic systems may decide and execute within a workflow. That changes the control boundary because the question is no longer only what the tool says, but what it can do without approval. Governance must define autonomy limits before the workflow goes live.

Q: When should organisations prioritise AI security posture management over broader detection tuning?

A: Prioritise AI security posture management when your AI risk is driven by exposed endpoints, over-permissioned data access, or shadow AI that has not been inventoried. If the main problem is unknown AI exposure, better detection does not fix the asset gap. Inventory and access control come first.

Q: Who is accountable when an AI system takes an unsafe action in security operations?

A: Accountability belongs to the team that granted the system its authority, set its approval boundaries, and allowed it to act on production data or identities. If human review was bypassed or made optional, the governance failure sits with the operating model, not the model output.

Technical breakdown

AI-powered security vs. security for AI

AI-powered security uses models to defend environments by spotting anomalies, correlating alerts, and prioritising risk. Security for AI protects the AI estate itself, including model endpoints, training data, prompts, and connected tools. The distinction matters because a platform may be strong at behavioural detection and still miss exposed AI assets or over-permissioned model access. In practice, AI security posture management covers the inventory and exposure side, while AI-powered detection covers the analysis side. Buyers should treat those as related but separate control planes, especially when AI workloads sit on shared cloud identity and data paths.

Practical implication: evaluate whether the platform secures both the defender and the AI asset, not just one side of the problem.

Blast-radius scoring beats raw severity in cloud risk

Raw severity is a poor guide in cloud estates because the same vulnerability can have very different consequences depending on exposure, identity reach, and data adjacency. A weak control on an isolated dev box is not the same as the same finding on an internet-facing workload that can reach sensitive data. Good prioritisation models combine exploitability, asset value, and reachability into one decision. That is why context graphs and dependency mapping matter more than long vulnerability queues. In cloud-native security, the real question is not how many findings exist, but which ones can chain into meaningful compromise.

Practical implication: rank findings by reachable blast radius, not by severity alone.

Agentic AI changes the approval boundary

Generative AI can summarise incidents or draft detections, but agentic AI goes further by planning and executing multi-step tasks with limited human input. That changes the control problem because the system no longer just recommends action, it may initiate it. The security concern is not AI branding but runtime authority: what the system can decide, what it can touch, and when it can act without escalation. Prompt injection becomes more dangerous in this model because crafted input can steer downstream actions if the agent trusts the content it reads. Governance needs to distinguish assistance from delegated execution.

Practical implication: define which actions remain human-approved before enabling any autonomous workflow.

Threat narrative

Attacker objective: The attacker aims to turn AI exposure or identity reach into faster access to sensitive data, operational disruption, or compromised decision-making.

1. Entry begins when exposed AI systems, over-permissioned model integrations, or cloud workloads create a reachable attack surface that can be discovered by attackers.
2. Escalation follows when the attacker uses the most reachable path into identities, data, or AI-connected tooling to increase privilege or influence security workflows.
3. Impact occurs when the attacker reaches sensitive data, disrupts detection, or manipulates the AI system into taking unsafe actions at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI cybersecurity is now an identity problem as much as a detection problem: the article shows that the useful distinction is not whether AI is present, but whether the platform can govern who or what is acting, what it can reach, and how much blast radius it can create. Once AI drives prioritisation or response, identity context becomes part of the security decision, not a side input. Practitioners should stop treating AI capability as a pure analytics feature and evaluate it as an access-control and governance layer.

Blast-radius intelligence is the named concept that matters here: the article’s strongest argument is that security value comes from ranking reachable impact, not from surfacing more alerts. That is the right model for cloud-native estates because exposure, identity, and data are chained together. The implication is that teams should measure whether a platform understands dependency paths well enough to distinguish noise from a path to compromise.

Agentic AI collapses the old assumption that response tools only advise: human approval gates were designed for systems that recommend action, not systems that can plan and execute multi-step workflows. That assumption fails when the actor can make runtime decisions, choose actions, and initiate execution without waiting for a person. The implication is that governance teams must rethink delegated authority before they worry about tuning the workflow.

AI security and NHI governance are converging in the cloud stack: exposed AI workloads, service identities, and data paths are increasingly the same risk surface. The article points toward a market where CNAPP, AI security posture management, and identity governance will be evaluated together rather than in separate budgets. Practitioners should expect more pressure to unify inventory, approval, and exposure management across these domains.

False confidence is the practical failure mode in AI security buying: a platform that explains models well but cannot control autonomy, or can score risk but not map identity reach, leaves the programme with a gap that looks sophisticated on paper. The standard to apply is whether the tool reduces decision uncertainty for the operator. If it does not, it is adding another layer of noise.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Read OWASP NHI Top 10 for the control patterns that address agentic misuse and prompt-driven abuse.

What this signals

Blast-radius governance will become the deciding control for cloud AI deployments: the market is moving from alert volume to reachable impact, and teams that cannot explain why one issue matters more than another will struggle to justify their tools. With 84% of organizations now using AI in the cloud, the scale of the problem is already large enough to make prioritisation a governance function, not just an operations task.

AI and identity security will keep converging at the control plane: once models can read data, rank risk, or trigger response, the same service identities that support cloud automation become part of the AI security boundary. Practitioners should expect tighter coupling between CNAPP, AI posture management, and lifecycle governance, especially where secret sprawl or shadow AI creates hidden access paths.

For practitioners

• Separate defender AI from AI asset security Map whether each tool is protecting your environment with AI or protecting the AI systems you operate. Use that split to identify missing coverage for exposed model endpoints, prompt paths, training data, and identity-linked access.
• Test blast-radius scoring against a live cloud path Compare the platform’s top-ranked findings with a real dependency chain from public exposure to sensitive data. If the tool cannot explain why one issue outranks another in terms of reachable impact, treat the ranking as incomplete.
• Define autonomy boundaries before enabling agentic workflows Document which actions an AI system may take independently, which require human approval, and which are forbidden. Apply the same boundary to incident response, ticket creation, and identity changes so the control model stays explicit.
• Inventory AI-linked identities and secret paths together Trace service accounts, API keys, tokens, and model integrations as one dependency graph. That lets you find where a compromised identity could be used to move from cloud access into AI misuse or data exposure.

Key takeaways

• The core problem is not whether a vendor uses AI, but whether it governs the AI systems and identities that create risk.
• Platform value depends on whether risk scoring reflects reachable blast radius, exposed data, and identity paths, not just severity.
• Teams should define autonomy limits and inventory AI-linked identities before they trust agentic workflows in 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.
• Security For AI: The discipline of protecting AI systems themselves, including model endpoints, training data, prompts, and connected tools or identities. It focuses on exposure, misuse, and governance gaps around the AI asset. For cloud and identity teams, it behaves like a posture problem with access-control implications.
• Blast Radius: The set of systems, identities, and data an attacker can reach after a compromise or unsafe action. In cloud and AI environments, it is more useful than raw severity because it captures how far an issue can spread. Good prioritisation reduces blast radius before it reduces the total number of findings.
• Agentic AI: AI that can plan and execute multi-step work with limited human input, rather than only producing recommendations. The governance challenge is not intelligence, but delegated authority. Once the system can act on its own, approval boundaries, auditability, and identity controls must be explicit.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: AI cybersecurity companies and how to choose the right provider. Read the original.