Securing AI systems used to mean watching the model itself: scanning prompts and outputs for harmful content or leaked sensitive data. Agents change that equation. Because an agent can call external tools, execute code, manipulate data, and pass tasks to other agents, it opens attack surfaces that text filtering was never designed to cover. A single malicious instruction no longer just risks producing a bad response, it can trigger an irreversible action.
To meet this challenge, a new generation of AI security tooling has emerged, falling into four distinct categories: adversarial testing, scanning of tools and configurations, runtime isolation, and an overarching agent security control plane.
This article walks through these four categories in the sequence you'd naturally encounter them while building and running an agent, from development and testing through staging and into production. Along the way, you'll see which tools lead each category:
- Promptfoo for adversarial testing
- Snyk Agent Scan for tool and configuration scanning
- E2B for runtime isolation
- Trust3 AI for the control plane
Of these four, the control plane stands out as the foundation of mature AI agent security posture management. It continuously discovers agents across your environments, enforces policy from the moment an agent is built through every action it takes at runtime, and keeps a complete audit record, closing the gaps that testing, scanning, and sandboxing alone cannot.
By the time you finish this article, you'll be equipped to recognize the specific threats facing your AI agents and know which tools to deploy to defend against each one.
What AI Agent Security Tools Protect Against
An AI agent is fundamentally different from a simple text generator. Rather than just producing a response, it reasons through a problem, makes decisions, takes action, and adapts, often by calling tools, executing code, touching live data, or delegating work to other agents. A chatbot that gets something wrong produces bad text. An agent that gets something wrong can trigger an action you can't undo.
Prompt Injection
Prompt injection tops most industry threat lists because attackers can bury malicious commands inside content the agent processes, whether that's a user message, a retrieved document, a tool description, or output from another agent. Since models struggle to reliably separate legitimate instructions from embedded text, they may carry out hidden commands as if they were authorized.
Tool Abuse and Excessive Agency
Tool abuse happens when an attacker manipulates an agent into invoking a tool beyond its intended scope, such as tricking a support bot into issuing a refund instead of merely reporting refund status. This is typically possible because of excessive agency, an architectural flaw where an agent holds more tools, permissions, or autonomy than its actual task demands.
Credential Overreach
Agents often operate using real credentials that grant access far beyond their job. A reporting agent with the correct read-only tool can still be dangerous if its underlying database login also exposes payroll or customer records, meaning a single hijacked session can expose everything that credential touches.
Data Exfiltration
When an agent can read private data, process untrusted input, and send information externally all at once, that combination, known as the lethal trifecta, lets a basic prompt injection quietly leak secrets without exploiting any software bug.
Lost Identity Between Agent and Data
When multiple agents share one credential to reach a backend system, that system only sees the shared login, never the specific agent, user, or purpose behind each request. This blind spot feeds the classic confused deputy problem, where legitimate authority gets hijacked for unauthorized ends.
Poisoned Tools
Tools accessed through shared protocols like MCP carry text descriptions the agent trusts implicitly. Attackers exploit this through tool poisoning (hiding instructions in descriptions), rug pulls (altering tool behavior after approval), or insecure server setups that skip authentication entirely.
Agent-to-Agent Risk
When agents hand tasks to one another, the original identity and intent can evaporate along the chain. A compromised agent can pass along attacker instructions disguised as routine work, and the receiving agent, with no record of who truly requested it, may execute them anyway.
Category 1: Red-Teaming Tools that Test the Agent Before It Ships
Red-teaming refers to the practice of deliberately probing a system for weaknesses before attackers find them first. Industry frameworks like NIST's Generative AI Profile classify this as a structured risk-management exercise. For AI agents, red-teaming tools simulate prompt injections, jailbreak attempts, PII leakage, and tool-level failures such as broken authorization checks or excessive permissions, catching these issues in development rather than production.
Leading Tools in This Space
Promptfoo, NVIDIA Garak, and Microsoft PyRIT have become the go-to options for adversarial AI testing. Promptfoo in particular stands out as an open-source, MIT-licensed command-line tool built for red-teaming both language models and agents. It's config-driven and designed to run either locally during development or inside CI/CD pipelines. OpenAI acquired Promptfoo in March 2026 and committed to keeping it open source under its existing license.
How Promptfoo Works
Promptfoo generates adversarial test cases and sends them to your agent through an HTTP endpoint or a direct function hook. What sets it apart is a set of agent-aware plugins that go beyond checking for unsafe text, they test for authorization flaws, agency overreach, and injection vulnerabilities.
Its authorization-focused plugins include checks for role-based access control (confirming the agent respects defined role boundaries), broken object-level authorization (verifying it can't be tricked into pulling another user's data), and broken function-level authorization (ensuring it won't call functions outside its permitted scope). Beyond these, the plugins also probe for excessive agency, unauthorized tool discovery, and indirect prompt injection.
Configuring and Interpreting Results
Teams define their test parameters in a configuration file, specifying the target system, the vulnerability categories to test, and the attack strategies to use, ranging from simple single-shot injection attempts to multi-turn escalation sequences designed to wear down the agent's defenses over several exchanges.
The resulting report organizes findings by vulnerability type and severity level. For every successful attack, it documents the exact input that broke through, how the agent responded, and which OWASP risk category the finding maps to.
The Limits of Point-in-Time Testing
Red-teaming only answers whether an agent fails against a given input at a specific moment. It can't continuously monitor or block threats once the agent is live. A clean test result today says nothing about a malicious document the agent might encounter and process tomorrow.
Category 2: Scanners that Vet the Tools Your Agent Trusts
Before an agent ever calls a tool, that tool itself needs to be checked for tampering. A growing set of scanners exists specifically to catch tool poisoning before it reaches production. Snyk Agent Scan, Cisco AI Defense MCP Scanner, and MCP-Shield examine MCP servers and their tool descriptions, while NVIDIA SkillSpector performs similar checks on agent skills.
Running Snyk Agent Scan
Snyk Agent Scan launches with a single command, uvx snyk-agent-scan@latest. It reads through an agent's configuration files to identify which MCP servers and skills are connected, then starts each one to pull its tool descriptions. From there, it inspects both the servers and their descriptions for signs of tool poisoning, embedded prompt injection, and cross-server shadowing, a technique where a malicious server's tool mimics a legitimate tool hosted elsewhere. Because the scan works directly from the configuration file rather than only the descriptions, it can flag a potentially dangerous server even if the agent hasn't invoked it yet.
Four Things to Watch For
Despite its usefulness, Snyk Agent Scan comes with caveats worth understanding before relying on it.
First, the tool transmits your configurations and tool descriptions to Snyk's API, redacting any secrets it detects along the way. Still, it's worth manually reviewing what gets sent when scanning particularly sensitive setups.
Second, reading a server's tools requires actually starting that server, which means executing its code. If you're scanning a configuration you don't fully trust, run the scan inside an isolated sandbox with locked-down filesystem and network permissions to contain whatever a malicious server might attempt.
Third, a scan only captures a snapshot in time. It has no way of catching a rug pull, where a tool's behavior changes after the scan has already approved it, mid-session.
Fourth, passing a scan says nothing about how the agent actually uses that tool once deployed. Vetting happens before the agent ever runs, but failures can still occur once it's live.
Where Scanning Fits in the Bigger Picture
Tool and configuration scanning closes a gap that red-teaming doesn't touch: the supply chain of tools and servers an agent depends on. But like red-teaming, it's fundamentally a pre-deployment check. Neither approach can monitor or control what happens once the agent starts executing code and making real tool calls in production, which is where isolation and runtime enforcement take over.
Conclusion
AI agent security tools have had to evolve well beyond the early focus on filtering prompts and responses. That approach made sense when models only generated text, but agents do far more: they call tools, execute code, read and write data, and hand off work to other agents. Protecting them means controlling not just what an agent says, but what it's permitted to do and reach when it acts.
Each category of tooling covered in this article addresses a distinct stage of an agent's lifecycle. Red-teaming tools like Promptfoo stress-test an agent before release, surfacing prompt injection, authorization flaws, and excessive agency while there's still time to fix them. Scanners like Snyk Agent Scan vet the tools and MCP servers an agent will trust, catching poisoned tools and insecure configurations before they're ever loaded. Sandboxes such as E2B isolate the code an agent executes at runtime, containing the damage a compromised action could otherwise cause. And a control plane like Trust3 AI ties everything together, following an agent from registration through live execution.
A control plane in particular fills the gaps the other three categories leave open: it discovers agents across an organization's environments, including ones nobody registered, records what they actually do at runtime, and enforces policy at integrated checkpoints, both at the gateway and at the data source itself.
No single tool covers every threat. Combining all four categories, matched to where your agents actually operate, gives you a security posture that follows the agent from build time through production.
Top comments (0)