AI agent security platforms expose the limits of legacy IAM controls

At a glance

What this is: This is an analysis of six LLM security platforms and the key finding is that AI agents are expanding the enterprise attack surface faster than legacy defenses can govern.

Why it matters: IAM teams need to understand how agentic workflows change visibility, authorization, and enforcement expectations across NHI, autonomous, and human identity programmes.

By the numbers:

• Two-thirds (66%) of organizations report productivity and efficiency gains from AI adoption.

👉 Read WitnessAI's analysis of six LLM security platforms for enterprise AI

Context

AI agent security now sits at the intersection of identity governance, data protection, and runtime enforcement. The core problem is simple: when a system can act across multiple tools and services with elevated permissions, the control model must account for how that identity behaves in motion, not just how it is provisioned.

This article compares six LLM security platforms, but the deeper issue is the governance gap they are trying to close. Browser-first controls, network-level inspection, and SASE-integrated approaches each solve part of the visibility problem, yet none matter if the enterprise cannot see agent activity, constrain tool use, and attribute actions back to accountable identities.

Key questions

Q: How should security teams govern AI agents that can access multiple systems?

A: Security teams should govern AI agents as identity-bearing actors with a defined owner, policy boundary, and runtime enforcement path. That means mapping which systems they can reach, what data they can expose, and which actions must be routed, redacted, or blocked before execution crosses a trust boundary.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can make runtime decisions across tools and systems, which expands their blast radius beyond a fixed workflow. Traditional automation follows a predefined path, but agentic behaviour can change the action sequence, tool choice, and timing in ways that require continuous governance.

Q: What do organizations get wrong about browser-based AI governance?

A: Organizations often assume browser controls cover the full AI surface, but native desktop apps, IDEs, and agent tool chains can sit outside that boundary. If the control plane only sees browser traffic, it misses a large part of modern AI use and leaves gaps in visibility and enforcement.

Q: How do security teams choose between network-level and browser-level AI controls?

A: Teams should choose based on actual AI usage paths. Browser-level tools fit web-heavy environments, while network-level inspection is better when AI activity extends into desktop apps, agent workflows, or multiple model endpoints. The right choice is the one that covers the real execution path, not the easiest deployment.

Technical breakdown

Why AI agent visibility is an identity problem

AI agent visibility is not just logging. It is the ability to observe prompts, responses, tool calls, and destination systems in a way that ties activity back to a human owner or governed service identity. In enterprise settings, that matters because the agent often spans browser sessions, native desktop apps, and external model endpoints. Without that chain of attribution, security teams can see that an action happened but not which identity initiated it, which policy applied, or whether the workflow crossed a trust boundary. That is where conventional IAM telemetry stops and agent governance begins.

Practical implication: require identity attribution and full-path telemetry before approving any AI control plane.

Policy granularity in LLM security platforms

LLM security platforms differ most in how they enforce policy. Binary allow-or-block controls are useful, but they are too coarse for real enterprise use because AI interactions often contain mixed intent, partial sensitivity, and business context. More mature models support route, redact, and context-aware enforcement, which lets security teams separate low-risk requests from high-risk ones without forcing every interaction into the same treatment. That distinction becomes critical when employees, copilots, and agents all use the same models but under different risk and access conditions.

Practical implication: evaluate whether the platform can apply different controls by role, intent, and data sensitivity.

Agentic workflows extend the attack surface beyond the browser

Browser governance only covers part of the problem. AI agents increasingly operate in native desktop applications, IDEs, embedded copilots, and MCP-connected workflows, which means the security boundary can no longer stop at the browser extension layer. Runtime defense for these environments needs network-level or equivalent inspection that can see both prompts and outputs while preserving business continuity. The technical question is not whether the platform can block malicious content, but whether it can consistently govern the full execution path where prompts, tools, and downstream systems intersect.

Practical implication: validate coverage across desktop apps, IDEs, and agent tool chains, not just browser sessions.

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 agent security is becoming the new identity perimeter. The article reflects a market shift away from point solutions that only watch browser traffic or static data leakage. When AI systems can operate across multiple applications and models, the practical control problem becomes one of identity attribution, policy enforcement, and runtime containment across the whole interaction path. Practitioners should treat agent governance as part of the identity perimeter, not a separate overlay.

Prompt-only defense is now an incomplete security model. A platform that inspects only one side of the interaction misses exfiltration in the response path, unsafe tool calls, and policy drift between input and output. The article makes clear that the more mature architectures are bidirectional, because data loss and misuse can occur after the model has already processed the request. Security teams should evaluate controls on both ingress and egress.

Identity blast radius is the named concept this category needs. AI agents with elevated permissions across multiple systems create a larger blast radius than human users because a single runtime decision can fan out across tools, data stores, and models. That is not just a visibility problem, it is a governance problem tied to how much damage one governed identity can cause before controls react. Practitioners should map blast radius as a first-class risk metric for agentic environments.

Browser-first governance is a useful entry point, not a complete model. The article shows why some platforms fit web-heavy environments while others are designed for broader deployment across native apps and agentic workflows. That split matters because identity teams increasingly have to govern the same AI use case across multiple execution surfaces. The right question is not which model is universally best, but which one matches the actual shape of enterprise AI usage.

AI governance now demands coordination between IAM, security, and data teams. The controls discussed here sit at the junction of access, content inspection, and sensitive data handling. No single team owns all of those domains, which means governance will fail if it is treated as a point product evaluation instead of an operating model change. Practitioners should align ownership before they buy tooling.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% say governance is critical to enterprise security.
• The next step is to pair agent governance with runtime identity controls, as outlined in OWASP Agentic AI Top 10.

What this signals

Identity blast radius: the most useful way to think about AI agent risk is as a widening execution radius, not just a broader data exposure problem. As agent workflows spread across apps and models, IAM and security teams will need to measure how far one identity can move before policy intervenes.

With 92% of organisations saying AI agent governance is critical but only 44% having implemented policies, the adoption curve is outpacing operating model maturity. That gap matters because control design, not model quality, will decide whether AI becomes governable at scale.

Teams should expect purchasing decisions to shift toward platforms that can see native apps, browser traffic, and agent tool calls in one policy plane. The practical lesson is that fragmented controls will continue to leave blind spots wherever AI runs outside the browser.

For practitioners

• Map the full AI footprint Inventory where AI is used across browser sessions, native apps, IDEs, embedded copilots, and agent workflows. Tie each use case to the governing identity, the data it can reach, and the systems it can invoke so you can see where control gaps begin.
• Test bidirectional runtime enforcement Verify that a platform can inspect prompts and responses, not just inputs. Require controls that can route, redact, or block content before sensitive data leaves the environment, especially when tools and downstream systems are involved.
• Require identity attribution for agent actions Ensure every agent action can be linked back to a human owner or governed non-human identity. That attribution is essential for incident response, audit, and access review when an agent acts across multiple systems.
• Evaluate policy granularity by role and intent Compare tools on whether they support context-aware enforcement for different user groups, data classes, and business scenarios. A single global rule set is too blunt for mixed human and agentic usage.

Key takeaways

• AI agents are expanding enterprise attack surfaces faster than legacy IAM and security models were built to handle.
• The evidence points to a governance gap, with AI agent adoption rising faster than policy coverage and runtime control maturity.
• Practitioners should prioritize identity attribution, bidirectional inspection, and full-footprint visibility before standardizing on any AI security platform.

Key terms

• AI Agent Identity: An AI agent identity is the governed identity used by software that can select actions, call tools, and decide when to execute. In practice, it must be treated as a non-human identity with ownership, scope, and audit requirements that reflect its runtime behaviour, not just its provisioning record.
• Bidirectional Runtime Defense: Bidirectional runtime defense inspects both the request sent to a model and the response returned from it. This matters because sensitive data, unsafe instructions, and policy violations can occur in either direction, especially when agents and downstream tools are part of the same workflow.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause before controls stop it. For AI agents, the concept includes tool reach, data access, and downstream system impact, making it a more useful measure than simple privilege count when evaluating runtime governance.
• Agentic Workflow: An agentic workflow is an AI-enabled process in which the system can sequence tasks, choose tools, and continue execution with limited or no human intervention. The governance challenge is that these workflows behave more like active identities than static automations, so traditional access assumptions no longer hold.

Deepen your knowledge

AI agent security and runtime governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic workflows, it is worth exploring.

This post draws on content published by WitnessAI: the guide comparing six LLM security platforms for enterprise AI. Read the original.