AI security vendor categories are fragmenting around agent risk

At a glance

What this is: Akto says AI security buying is fragmenting into five categories as teams split agent risk, runtime protection, governance, detection, and platform coverage into separate control decisions.

Why it matters: IAM and security teams need that category map because agentic AI creates identity, access, and tool-use risks that traditional one-size-fits-all evaluations miss.

Context

AI security is not one control problem. The article separates risks tied to autonomous agents, LLM runtime safety, shadow AI governance, AI-native detection, and broader platform coverage, which means evaluation has to start with the exposure, not the brand.

That matters for identity and access governance because agentic systems act through tool permissions, MCP connections, API calls, and delegated access paths. When the control point moves into runtime behaviour and tool invocation, teams need to think about identity, authorisation, and policy enforcement together rather than in silos.

Key questions

Q: What should teams do first when AI security categories do not line up?

A: Start by mapping the AI exposure, not the vendor list. Separate agent and MCP access, LLM runtime safety, posture and governance, AI-native detection, and enterprise platform coverage so each risk is matched to the control layer that can actually enforce it.

Q: Why do autonomous AI agents create a different security problem from ordinary software access?

A: Autonomous AI agents blur the line between user and system because they can act, decide, and share data within workflows. That creates new risk around unintended autonomy, model manipulation, and data leakage. Traditional controls often miss those actions because they were built for fixed applications, not systems that can change behavior at runtime.

Q: What are the signs that AI governance controls are not keeping pace with adoption?

A: Common warning signs include unclear ownership for AI use cases, inconsistent approval processes, limited visibility into where sensitive data enters models, and weak evidence for audits or assessments. Teams also struggle when privacy, security, and legal review happen late or manually, because that usually means governance is reactive rather than embedded in the AI delivery process.

Q: Should organisations consolidate DLP and AI agent security in one platform?

A: Consolidation can reduce tool sprawl, but only if the platform proves real enforcement across the actual runtime paths your agents use. The decision should be based on coverage depth, transport visibility, and whether controls can block, redact, revoke, or approve before completion. If those capabilities are fragmented, separate controls may still be safer.

Technical breakdown

Why agent and MCP security is a distinct control layer

Autonomous agents are not just another application workload. They can select tools, call APIs, and interact with databases or third-party services in ways that are not fully predetermined, which creates a new governance boundary around who or what is allowed to trigger those actions. Model Context Protocol (MCP) strengthens the integration layer but also expands the blast radius if the connection policy is weak. The security problem is therefore not only model safety, but tool-use authorisation, connection scope, and runtime visibility over delegated actions.

Practical implication: Treat agent-to-tool access as a governed identity path and review it separately from standard application permissions.

How LLM runtime and prompt protection differs from governance

LLM runtime protection focuses on request-response safety inside the application path. It is designed to catch prompt injection, jailbreak attempts, harmful outputs, and input patterns that try to steer the model outside intended behaviour. That is different from AI posture and governance, which looks across the environment for shadow AI, inventory gaps, and policy compliance. In practice, one layer watches what happens in the conversation, while the other watches what AI exists and whether it is approved.

Practical implication: Use runtime controls for prompt and output risk, and governance controls for discovery, policy enforcement, and auditability.

Why platform vendors are entering AI security through adjacent controls

Enterprise platforms are absorbing AI security because many organisations prefer to extend existing infrastructure rather than introduce a completely separate control stack. That does not remove the need for specialist tools. It changes the buying pattern into layered coverage, where some risks are handled inside broader platforms and others require purpose-built controls for agents, LLM behaviour, or governance. For practitioners, the key question is which risk should sit inside the platform and which requires a dedicated control plane.

Practical implication: Map each AI risk to the control layer that can enforce it, then decide where platform consolidation is acceptable and where it is not.

Threat narrative

Attacker objective: Exploit delegated agent trust and tool access to drive harmful actions, data exposure, or downstream abuse through the agent's own permissions.

1. Entry occurs when an autonomous agent is connected to databases, APIs, or third-party services through MCP or similar tool links.
2. Credential or permission abuse follows when the agent can act with delegated access wider than the task actually requires.
3. Impact occurs when attackers misuse the agent or manipulate prompts so the system produces harmful outputs or exposes data through its own authorised connections.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

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

NHI Mgmt Group analysis

AI security is splitting into control layers, not vendor tiers. The market is fragmenting because the risks are genuinely different: delegated agent access, runtime prompt abuse, environment-wide governance gaps, and AI-assisted detection all need different enforcement points. A buying process that compares them as substitutes obscures the real question, which is where the control must sit in the operating model. Practitioners should evaluate AI security by control boundary, not by product family.

Agent identity is becoming the new governance boundary for AI systems. Once an agent can invoke tools, the security problem is no longer only model output quality. It becomes an identity and authorisation question about what the agent may do, what context it may use, and when a tool call is legitimate. That is why AI agent and MCP security belongs in the same governance conversation as NHI and delegated access. Practitioners should treat agent permissions as a live access model, not a static configuration.

Prompt protection and AI governance solve different failure modes. Runtime filtering can reduce prompt injection and harmful output risk, but it does not answer whether the organisation even knows where AI is deployed or who approved it. Conversely, posture tools can inventory shadow AI without stopping a malicious or manipulated interaction in the request path. The category split is a reminder that visibility is not enforcement. Practitioners should avoid using governance coverage as a substitute for runtime protection.

Enterprise platform consolidation will simplify procurement before it simplifies risk. Platform vendors are pulling AI security into broader stacks because many buyers want fewer tools and faster integration. That may improve adoption, but it can also blur whether the platform truly enforces agent, runtime, and governance controls at the depth the risk requires. The deciding factor should be control fidelity, not procurement convenience. Practitioners should check whether consolidation reduces risk or merely repackages it.

One named concept matters here: agentic control layering. This is the practical separation of AI security into agent access control, runtime protection, governance, and detection rather than forcing one product to cover every exposure. The article shows that this layering is already the market's operating reality. Teams that align their evaluation to that structure will make cleaner architecture decisions. Practitioners should build AI security roadmaps around layered controls, not single-vendor narratives.

From our research library:

• 54% of organisations are actively deploying AI agents across workflows, yet only 21% report a mature governance model for agentic AI.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agentic control layering: AI security programmes will need to split control ownership across agent access, runtime safety, governance, and detection instead of treating AI as a single security domain. That separation changes how teams assign ownership, measure coverage, and decide where platform consolidation is acceptable.

The more AI systems act through delegated identity and tool connections, the more the control problem starts to resemble privileged access governance. Teams that understand that shift will be better placed to decide where identity, policy, and runtime enforcement must intersect.

53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey. That makes governance design, not procurement speed, the real programme risk.

For practitioners

• Map AI controls to the actual exposure Separate agent access, LLM runtime safety, posture and governance, detection, and platform-wide coverage before comparing vendors. Use that map to decide where a specialist control is required and where an existing platform is sufficient.
• Review delegated tool permissions for agents Inventory every API, database, and third-party service reachable by an autonomous agent, then limit each connection to the smallest task-scoped scope you can justify.
• Split runtime protection from governance Use one control set for prompt injection, jailbreaks, and harmful output filtering, and another for shadow AI discovery, inventory, and policy compliance.
• Test whether platform coverage is really enforcing Challenge any enterprise platform claim by asking whether it can actually monitor agent behaviour, not just embed AI features across the stack.
• Build a category-first evaluation shortlist Shortlist vendors only after deciding which AI risk category matters most, then compare candidates that solve that same problem rather than mixing unrelated control layers.

Key takeaways

• AI security is fragmenting because agent access, runtime protection, governance, detection, and platform coverage are different control problems.
• The article's central point is that AI security evaluation should start with the exposure being governed, not with a generic vendor shortlist.
• For identity and access teams, the highest-value move is to treat agent permissions and tool connections as part of the access model, not as an afterthought.

Key terms

• Agentic Control Layering: A governance approach that separates AI security into distinct enforcement layers for agent access, runtime protection, posture management, and detection. It avoids treating all AI risk as one problem and makes control ownership clearer across security, platform, and AI teams.
• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• AI Posture And Governance: The programme layer that inventories AI usage, discovers shadow AI, and enforces policy, compliance, and approval rules. It is primarily about visibility and control over what AI exists, where it operates, and whether it is sanctioned.
• Runtime Prompt Protection: Controls that inspect prompts and outputs during the live request-response path to stop injection, jailbreaks, harmful content, or unsafe model behaviour. This is enforcement at the interaction layer, not a substitute for discovery or governance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security practitioners align identity controls to emerging AI and automation risk.