How to evaluate AI security vendors for agentic AI threats

At a glance

What this is: Akto argues that evaluating AI security vendors for agentic AI requires scrutiny of the full agent stack, because tool use, memory, permissions, and MCP connections create risks that standard AppSec controls miss.

Why it matters: IAM, PAM, and security teams need a vendor-evaluation model that distinguishes model scanning from real agent governance, because agentic risk emerges at runtime privilege, tool invocation, and delegated access boundaries.

Context

Agentic AI security is a governance problem as much as a technical one. AI agents can act through tools, data stores, memory, and protocol connections, which means the security boundary is no longer the model alone but the whole delegated action chain.

That changes how practitioners evaluate vendors. Legacy WAF, CSPM, and static model-scanning tools can still identify some adjacent risks, but they do not measure whether an AI agent is properly scoped, monitored, or blocked when it behaves outside intent.

Key questions

Q: What breaks when AI security vendors only scan prompts instead of governing agents?

A: Prompt scanning misses the control surface where agentic risk usually appears: tool choice, memory, permissions, and protocol calls. That means the product may detect obvious jailbreaks while missing the workflow that actually causes data exposure or unsafe action. For agentic AI, the failure is not the prompt alone, but the delegated execution path built around it.

Q: Why do agentic AI systems need runtime security instead of static guardrails alone?

A: Agentic systems can plan, call tools, and adapt while they are live, so static guardrails cannot reliably predict or contain every harmful sequence. Runtime security matters because the risk appears when the system is acting under real permissions in production, not only when it is being tested.

Q: What are the signs that an AI security vendor is really testing agentic risk?

A: Look for coverage of memory poisoning, unsafe tool chaining, MCP-specific attacks, and adversarial workflows that evolve over time. A vendor whose tests stop at single-shot prompt injection is not measuring the behaviour that makes agents dangerous in production. Effective testing mirrors how an attacker would chain actions across a live system.

Q: Should security teams compare AI-native and legacy AppSec tools differently?

A: Yes. The comparison should focus on whether AI changes coverage, triage quality, and scale of rule creation rather than on branding. Teams should ask whether the tool can handle AI-assisted code, support more languages, and reduce analyst effort without sacrificing precision.

Technical breakdown

Why legacy tools miss agentic AI threat paths

Legacy AppSec and posture tools were built around predictable request-response systems, not systems that reason, choose tools, and carry context across sessions. A WAF can inspect an HTTP request, but it cannot see why an agent selected a tool, whether a memory store is poisoned, or whether a multi-step workflow is drifting toward unsafe action. CSPM can find exposed infrastructure and excessive cloud permissions, yet it does not evaluate whether those permissions are excessive for an agent's actual task. The control gap is not visibility alone. It is the absence of runtime governance over delegated action.

Practical implication: Assess whether a vendor can inspect agent behavior at decision time, not just traffic or infrastructure state.

What credible agentic red teaming must test

Agentic red teaming needs to go beyond prompt injection and into the execution layer where tool misuse, memory poisoning, broken authorization, and MCP-specific exploits emerge. That means testing the full workflow, not a single prompt in isolation, and using a broad probe library that evolves as attack patterns change. Static jailbreak checks are useful but narrow. A real attack often succeeds only after several steps, when the agent is nudged into the wrong tool call or a malicious memory state persists into later sessions. The real test is whether the vendor can simulate that chain convincingly.

Practical implication: Require proof that red teaming covers multi-step workflows, tool chains, memory, and MCP pathways.

Runtime protection must intervene before the action completes

Runtime protection is the dividing line between useful detection and meaningful prevention. If a platform only logs a suspicious tool call after the fact, it has not protected the agent. Effective runtime controls need to intervene while the agent is operating, especially where MCP servers and other tool gateways expand the trust boundary. Behavioral anomaly detection can help by spotting unusual tool sequences, unusual data access, or sudden shifts in workflow patterns. In agentic systems, those signals often appear before a single action is obviously malicious. That makes the timing of enforcement the core design question.

Practical implication: Prioritise vendors that can block or step up review during agent execution, not only alert afterwards.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a controllable execution path that can misuse tools, access data, or trigger unauthorized actions.

1. Entry begins when a malicious prompt, poisoned document, or compromised tool output reaches the agent's input layer and shapes its next decision.
2. Credential access and privilege abuse follow when the agent is steered into invoking tools or MCP servers beyond its intended task scope.
3. Impact occurs when the manipulated agent exposes data, executes unsafe actions, or propagates bad instructions into downstream systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

Agentic AI security is now a delegated-access problem, not just a content-safety problem. The article's strongest message is that control failures emerge when agents can call tools, persist memory, and move through MCP connections with insufficient governance. That is why model scanning alone is structurally incomplete. Practitioners should evaluate security vendors on whether they can govern delegated action across the full agent lifecycle.

Threat-model credibility is the new vendor differentiator. A product that cannot describe input, execution, and output-layer risk in operational terms is probably not built for agentic environments. The named concept here is execution-layer blind spot, the gap between what a model says and what an agent does. Security teams should treat this as a test of whether the vendor understands the actual control surface, not just the marketing category.

Red teaming for agentic AI has to behave like an adversary, not a scanner. That means multi-step workflows, evolving probe libraries, and tests that include tool misuse, memory corruption, and MCP-specific pathways. This aligns closely with OWASP-AGENTIC, OWASP-NHI, and MITRE ATLAS thinking. The practical takeaway is simple: if the testing cannot break the workflow, it is not testing the workflow.

Runtime enforcement and auditability are the controls that make AI security operational. Detection after the event is useful for forensics, but it does not protect the agent while it is acting. Enterprises should expect live interception, clear traceability, and framework mapping that legal, audit, and security teams can use without translation. The vendor landscape is moving toward proof, not promises, and procurement should follow that standard.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Maturity Model

What this signals

Execution-layer blind spot: security programmes will increasingly be judged on whether they can govern what agents do, not only what models say. The practical shift is from scanning outputs to controlling delegated actions, especially where tools and MCP servers extend the trust boundary.

Enterprises should expect procurement language to converge on runtime interception, auditability, and agent identity governance. That means security, IAM, and compliance teams need shared criteria for evaluating whether a platform can trace a malicious action back to a specific agent, prompt, and decision point.

For practitioners

• Evaluate agentic threat-model depth Ask vendors to explain how they handle input, execution, and output-layer risk, with explicit coverage of tool misuse, memory poisoning, broken authorization, and MCP connections.
• Test for live interception Require a demonstration of a multi-step attack being blocked in real time, not a report generated after the malicious action has already completed.
• Review red-team coverage Check whether the probe library includes evolving cases for indirect prompt injection, unsafe tool chaining, and agent-to-agent or agent-to-tool escalation paths.
• Validate audit trail completeness Confirm that every high-risk agent action can be traced back to a specific agent, prompt, and decision point without manual log stitching across systems.
• Map vendor claims to frameworks Require clear alignment to OWASP Agentic AI, OWASP NHI, MITRE ATLAS, and the NIST AI Risk Management Framework so internal governance teams can use the evidence directly.

Key takeaways

• Agentic AI security fails when vendors treat prompts as the main control surface and ignore tool execution, memory, and delegated access.
• The article argues that red teaming, runtime protection, and auditability are the practical tests that separate agent-aware platforms from rebranded legacy tools.
• Security teams should evaluate whether a vendor can stop unsafe agent behaviour in motion and produce evidence that audit and legal teams can actually use.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• 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.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks, potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps security practitioners connect delegated access risk to the controls their programmes already need.