Agentic AI security needs platform coverage, not point products

At a glance

What this is: This analysis argues that agentic AI security is emerging as a platform category, but most current tools remain narrow point products that miss major deployment patterns and runtime risk.

Why it matters: IAM, NHI, and security teams need to treat agent identity as necessary context, not a complete control plane, or they will leave embedded and custom agents outside governance.

By the numbers:

• The UK AISI research showed that agent tooling grew from roughly 5,000 to 177,000 tools in just over a year.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations 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 Zenity’s analysis of what comprehensive agentic AI security requires

Context

Agentic AI security is the set of controls used to discover, govern, monitor, and constrain AI systems that can choose actions and use tools at runtime. The central problem in this article is that the market is fragmenting into point products that only cover one deployment pattern or one control layer, while enterprises are adopting endpoint, SaaS, and custom agents at the same time.

For identity teams, the issue is not whether agents have identities. It is whether identity, data sensitivity, runtime behaviour, and governance can be connected into one operating model. Without that connection, organisations will end up with isolated controls that leave blind spots in embedded SaaS agents and internally built cloud agents.

Key questions

Q: How should security teams govern AI agents across endpoint, SaaS, and cloud environments?

A: Security teams should govern AI agents as a multi-environment identity problem, not a single product category. That means discovering endpoint, SaaS, and custom agents separately, then applying consistent policy, runtime monitoring, and enforcement across all three. If a control only sees one environment, it will miss embedded and homegrown agents that often carry the highest business risk.

Q: Why is identity not enough for AI agent security?

A: Identity is necessary because it shows which agent holds access, but it is insufficient because it does not explain intent, action chaining, or runtime misuse. An agent can stay within its permissions and still behave dangerously by combining permitted calls in a harmful sequence. Teams need identity plus behaviour, data context, and enforcement.

Q: What do security teams get wrong about agentic AI security tools?

A: The most common mistake is treating agentic AI security as an extension of an existing category such as NHI, endpoint, or DSPM. That view misses the fact that agents operate across multiple deployment patterns and require both posture controls and runtime response. A narrow tool can be useful, but it is not comprehensive governance.

Q: How can organisations tell whether their agent controls are actually working?

A: Look for evidence that you can discover agents, trace their tool usage, detect anomalous action chains, and stop high-risk actions before execution. If your programme only reports after the fact, or only sees one deployment pattern, it is producing partial assurance rather than operational control.

Technical breakdown

Three deployment patterns that break single-purpose agent controls

Enterprise agents now show up in three distinct places: on endpoints as coding assistants and agentic browsers, inside SaaS platforms as embedded workflows, and in cloud environments as custom-built agents. A tool that only inspects one of those places cannot claim comprehensive coverage because the control surface changes with each deployment pattern. Endpoint telemetry, SaaS admin context, and cloud runtime access are different sources of truth, and each exposes different forms of action risk. A complete security model has to connect discovery, policy, and enforcement across all three, or the organisation will keep buying visibility for one slice while leaving the others unmanaged.

Practical implication: inventory agents by deployment pattern before buying controls, because coverage gaps usually follow environment boundaries.

Why identity context is necessary but not sufficient

Agent identity tells you who or what is acting, what credentials it uses, and which systems it can reach. That is essential, but identity alone does not show whether the agent is behaving within intent, whether it has been manipulated through prompt injection, or whether a sequence of individually permitted actions has become dangerous in combination. This is why identity should be treated as one signal inside a broader control stack that also includes data sensitivity, reachability, runtime behaviour, and action-chain analysis. If identity is the only lens, a platform can confirm access while missing misuse.

Practical implication: pair NHI governance with runtime behaviour monitoring and action-chain analysis, not just credential and role management.

AISPM, AIDR, and hard boundaries define the real control stack

The article’s strongest architectural point is that agent security needs both build-time and runtime layers. AI Security Posture Management finds misconfigurations, overbroad tool access, and policy drift before deployment. AI Detection and Response watches the live action chain for anomalous behaviour, policy violations, and intent mismatch. Hard boundaries sit below both, enforcing non-negotiable limits such as blocking destructive actions or external exfiltration even when an agent attempts them. This stack matters because probabilistic reasoning alone cannot guarantee restraint. The architecture must combine assessment, monitoring, and deterministic enforcement.

Practical implication: require both posture management and inline enforcement, because alerting after execution does not contain agent-driven risk.

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

Point products are the wrong mental model for agentic AI security. The market is repeating the same fragmentation cycle that security teams saw in cloud security, where separate tools covered posture, workload, entitlements, and runtime with no single operational picture. Agentic AI raises the same problem faster because the agent surface spans endpoint, SaaS, and custom environments at once. Practitioners should treat unified coverage as the category requirement, not a feature wish list.

Identity is critical context, but it is not a control plane. Identity answers who or what the agent is and what access exists, but it does not answer whether the agent is acting within user intent, whether tool chaining is safe, or whether a permitted action becomes dangerous in sequence. That means IAM and NHI programmes remain necessary, but they cannot be the whole agent security strategy. The practitioner conclusion is clear: access governance must be layered with runtime decision visibility.

AI Security Posture Management and AI Detection and Response are the two halves of the same operating model. One layer assesses trust boundaries, permissions, and configuration before execution. The other watches the live action chain and intervenes when behaviour drifts. Without both, organisations either discover risk too late or never see it at all. Security leaders should evaluate whether their controls work across the full lifecycle from configuration to execution, not just one stage.

Comprehensive agent security will consolidate around governance that spans identity, data, and action. The article’s strongest signal is that agent control cannot stay trapped inside adjacent categories such as endpoint, DSPM, or NHI if the platform cannot reason across deployment patterns. That creates a named concept worth tracking: agent security coverage fragmentation, the condition where tools see only one environment or one layer of control. The practitioner conclusion is to buy for cross-environment governance, not category adjacency.

Autonomous behaviour changes the meaning of least privilege because the action sequence is chosen at runtime. Least privilege was designed for access that is known and reviewable at provisioning time. That assumption fails when the actor can select tools, combine actions, and change execution timing without a human gate. The implication is that governance must stop assuming static intent and start accounting for runtime agency.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
• For a broader view of how quickly agent tooling is expanding, see AI Agents: The New Attack Surface report and the OWASP Agentic Applications Top 10.

What this signals

Agent security coverage fragmentation: the market is moving toward a model where teams need one view of identity, data, and action across endpoint, SaaS, and cloud agents. Programmes that still evaluate tools by category fit will keep missing the environments where agent behaviour becomes hardest to govern.

With 80% of organisations already reporting AI agents acting beyond intended scope, the issue is no longer theoretical. Security teams should assume that discovery, policy, and runtime enforcement must work together before agent adoption scales further.

Teams building controls for AI agents should align their design discussions with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, because governance failures are increasingly about action chains, not isolated prompts.

For practitioners

• Map agent deployment patterns separately Inventory endpoint, SaaS, and custom agents as distinct control surfaces. Use that map to identify where your current tools have direct telemetry and where they rely on indirect signals only.
• Require runtime action-chain visibility Evaluate whether your controls can reconstruct sequences of tool calls, data reads, and outbound actions in real time. If they cannot, you have access governance without behavioural governance.
• Define hard boundaries for non-negotiable actions Identify actions an agent should never perform, such as destructive production changes or external data exfiltration, and enforce those boundaries deterministically rather than relying on prompts or policy text.
• Separate posture review from execution monitoring Build one process for pre-deployment trust boundary review and another for live behaviour detection. Treat them as complementary controls, not interchangeable capabilities.
• Align identity governance with business criticality Connect agent identities to the systems, data, and workflows they can affect, then assign stronger review to the highest-impact paths. That makes governance decisions easier to prioritise and explain.

Key takeaways

• Agentic AI security is fragmenting into point products, but the real control problem spans endpoint, SaaS, and custom agents together.
• Identity remains necessary context for agents, yet runtime behaviour, data sensitivity, and action-chain analysis determine whether access becomes risk.
• Security leaders should evaluate platforms on discovery, posture management, runtime response, and hard enforcement across the full agent lifecycle.

Key terms

• Agent security coverage fragmentation: A control gap where security tools each see only one part of the agent problem, such as endpoint, SaaS, or cloud. The result is partial visibility, inconsistent policy enforcement, and a false sense of governance because no single control layer can follow the agent across its full operating surface.
• AI Security Posture Management: The pre-execution layer that reviews agent configuration, trust boundaries, permissions, and exposure before the agent acts. In practice, it is the build-time discipline for reducing misconfiguration and overbroad access, but it must be paired with runtime monitoring because static review alone cannot prove safe behaviour.
• AI Detection and Response: The runtime layer that watches agent behaviour as actions unfold and intervenes when patterns deviate from policy or intent. It focuses on live action chains, anomalous tool use, and behavioural drift, giving teams a way to stop misuse that configuration review would never see in isolation.
• Hard boundary: A deterministic control that blocks an agent from performing a non-negotiable action, regardless of what the model generates or suggests. This matters because probabilistic reasoning cannot guarantee restraint, so critical limits need programmatic enforcement rather than policy text or prompt instructions alone.

Deepen your knowledge

Agentic AI 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 agents across identity, access, and behaviour, it is worth exploring.

This post draws on content published by Zenity: After RSA, Here Is What Comprehensive Agentic AI Security Actually Looks Like. Read the original.