AI agent security tools: the categories, and what each one covers

What AI agent security tools are

AI agent security tools are products and open-source projects that control what AI agents can reach and do. They find agents, give each one a provable identity, decide which calls may run, keep sensitive data in place, contain an agent that has been taken over, and record what happened. Those six controls (discover, identity, authorize actions, data protection, isolation and audit) frame this page and the pillar guide.

As of October 2026, the market has about 10 categories. Most grew out of something older: API gateways, identity providers, cloud posture tools, DLP (data loss prevention) and secure web gateways. That is why lists of AI agent security vendors mix very different products, and why "AI agent security platforms" can mean almost anything.

This page sorts categories by what they control. Examples come from their own public pages, in no particular order. It is not a ranking. For a wider list, see the OWASP GenAI Security Project's community solutions directory, which has an "Agentic" category and endorses no products. Terms are defined in the glossary.

How to choose AI agent security tools

Start with your agents and the harm you want to prevent, not with categories. A tool can only act on what passes through it, so where it sits matters as much as what it claims. Before you shortlist:

• List every agent first, including vendor agents and shadow AI. Enforcement bought before discovery misses some of them.
• Name the 3 to 5 actions that would hurt most, such as refunds, exports, deletions or outbound email.
• Locate the tool in the request path: model calls, tool calls, the host, the network edge or the cloud control plane.
• Check whether it sees the arguments of a call and the record it touches, or only the destination.
• Ask what happens when it is unreachable. A control that fails open is a log, not a control.
• Ask what it stores: prompts, responses and values, or only metadata.
• Ask what evidence each decision leaves, including denials. See AI agent audit trails.
• Confirm it covers agents you did not build, such as SaaS agents and coding agents on laptops.

Then map each candidate to the six controls, using the coverage matrix below.

Gateways, registries and identity

These categories decide which agents exist on paper, which can connect, and with what credentials.

AI and MCP gateways

An AI gateway is a proxy between applications and model providers. An MCP (Model Context Protocol) gateway does the same for traffic between agents and their tools. Gateways authenticate callers, apply rate limits and token quotas, route, and log every request. Many also filter prompts or redact personal data. See MCP security.

What they typically do not cover: agents that hold their own keys and call services directly, code running on the host, and business rules that depend on a record the gateway never reads, such as whether an invoice belongs to the customer on the case.

Examples, as of October 2026:

• agentgateway: an open-source Linux Foundation gateway for service, LLM and agent traffic, with native MCP and A2A support and tool-level scoping.
• Kong AI Gateway: governs LLM, MCP and agent-to-agent traffic, with token quotas, prompt guards, PII sanitization and MCP server auth.
• Cloudflare AI Gateway: analytics on requests, tokens and cost, plus logging, caching, rate limiting and model fallback.
• Azure API Management AI gateway: token limits, semantic caching, content moderation, and REST APIs exposed as MCP servers.

Agent platform registries and governance consoles

Cloud and SaaS platforms now ship their own registries: a catalog of the agents, MCP servers and tools built on that platform, with owners, review workflows and telemetry. Some add identity and policy features. If most of your agents live on one platform, its built-ins are the cheapest first step toward an agent inventory.

What they typically do not cover: agents outside their platform, such as a script on a finance workstation or an agent on another cloud. Coverage also depends on teams registering what they build.

Examples:

• Microsoft Agent 365: a centralized agent registry, with governance through Entra and Purview and threat protection through Defender.
• Amazon Bedrock AgentCore: a Registry for agents, MCP servers, tools and skills with a review and approval workflow, alongside Runtime, Gateway, Identity and Policy.
• Google Cloud Agent Registry: registers and governs agents, MCP servers and tools, with Agent Gateway enforcing IAM and content policies at runtime.
• ServiceNow AI Control Tower: an inventory of AI agents, models and MCP servers with risk, compliance and lifecycle management.

Non-human identity (NHI) and agent identity

NHI tools manage the identities software uses: service accounts, API keys, workload certificates and now agent identities. They find credentials, replace long-lived secrets with short-lived ones, tie each identity to an owner, and apply conditional access. Agent features add delegation, so an agent can act for a named person. See AI agent identity.

What they typically do not cover: what an agent does after it gets a credential. An identity check answers "is this the invoice agent?" It does not decide whether a $4,500 refund on this invoice should run.

Examples:

• SPIFFE and SPIRE: an open workload identity standard and its implementation, which attests workloads and issues identity documents (SVIDs).
• Microsoft Entra Agent ID: identities built for AI agents, created from blueprints, with the same adaptive access and lifecycle protections as users and workloads.
• Okta for AI Agents: discovery, lifecycle management and governance for agents; Okta's Cross App Access issues short-lived, scoped tokens for delegation.
• Aembit: access management for AI agents and workloads, issuing short-lived credentials only after identity and conditional access checks pass.

Posture, guardrails and data loss prevention

These categories inspect configuration and content. Many security teams already pay for agent security solutions in one of them.

AI security posture management (AI-SPM) and AI-BOM

AI-SPM tools scan cloud accounts and code for AI services, models, agents and their dependencies. They flag misconfigurations, exposed endpoints, over-broad identities and attack paths to sensitive data. Many produce an AI-BOM (AI bill of materials): a list of the models, datasets, frameworks and libraries an AI system uses.

What they typically do not cover: runtime decisions. Posture tools read configuration; they do not stop a single bad call. They also see only the accounts and repositories they are connected to.

Examples:

• Wiz AI-SPM: discovers and catalogs AI models, agents and services, with an AI-BOM, misconfiguration detection, attack paths and data exposure findings.
• Microsoft Defender for Cloud: AI posture management that discovers the generative AI BOM across Azure, AWS and Google Cloud, with attack path analysis.
• Palo Alto Networks Prisma AIRS: a platform spanning AI posture management, model scanning, red teaming, runtime security and agent security.
• CycloneDX ML-BOM: an open bill-of-materials format that records models, datasets, provenance and dependencies.

Runtime guardrails and prompt-injection filters

Guardrails sit in the model path and check text going in and out: prompt-injection and jailbreak detection, hidden instructions in retrieved documents, harmful content, off-topic requests, PII redaction and grounding. Some also check tool call inputs and outputs. They are the control closest to the model's reasoning.

What they typically do not cover: business authorization. Classifiers are probabilistic and can miss, and they do not know who the agent acts for or your refund limit. Microsoft's documentation says Prompt Shields do not determine whether content is compliant with policy.

Examples:

• NVIDIA NeMo Guardrails: an open-source toolkit (Apache 2.0) with input, dialog, retrieval, execution and output rails.
• Prompt Shields in Azure AI Content Safety: detects user prompt attacks and document attacks, and can scan agents' tool responses (in preview).
• Amazon Bedrock Guardrails: configurable safeguards including prompt attack detection and PII redaction, usable with any foundation model through the ApplyGuardrail API.
• LlamaFirewall: Meta's framework for detecting and mitigating security risks in agents and LLM apps, including a prompt-injection scanner.

Data loss prevention for AI

DLP for AI finds sensitive data in prompts, files and responses, then masks, redacts, tokenizes or blocks it. Endpoint and browser DLP stops people pasting customer data into public chatbots. Service-side DLP inspects what agents send to models and what tools return. See AI agent data loss prevention.

What they typically do not cover: whether the action itself is allowed. DLP can tell that a message contains 500 customer records, not whether this agent may email them to this address. Endpoint DLP does not see agents on servers.

Examples:

• Microsoft Purview: DSPM for AI, Endpoint DLP that can block sharing with third-party AI sites, and AI prompts and responses in the audit log.
• Google Cloud Sensitive Data Protection: 200+ detectors and de-identification, including masking and tokenization, for generative AI prompts and responses.
• Nightfall: controls data movement across AI agents, MCP servers, endpoints and SaaS, with pre-trained detectors for secrets, source code and customer PII.
• Presidio: an open-source toolkit for detecting and de-identifying PII in text and images; its documentation warns it may not find all sensitive data.

Sandboxes, network inspection and red teaming

These categories work at the edges: the machine, the network exit and the test bench.

Agent sandboxes and code-execution isolation

Sandboxes run agent code, and code the agent writes, in a confined environment: a hardened container, a user-space kernel or a microVM. Good ones remove network access by default, keep credentials outside, and limit files, system calls, memory and processes. See AI agent sandboxing.

What they typically do not cover: harm done through legitimate channels. A sandboxed agent that is allowed to call the billing API can still issue a bad refund. Sandboxes also do not discover agents or issue identities.

Examples:

• gVisor: an open-source, Linux-compatible sandbox that intercepts application system calls with a kernel written in Go.
• Firecracker: an open-source virtual machine monitor built at AWS that uses KVM to create lightweight microVMs.
• E2B: runs each agent session in its own isolated microVM, built on Firecracker, in E2B's cloud or the customer's own AWS, GCP or Azure account.
• NVIDIA OpenShell: an open-source runtime that sandboxes each agent with policy on files, system calls and network connections, adding credentials only to requests for approved endpoints.

Network and SASE inspection of AI traffic

SASE (secure access service edge) and secure web gateway vendors inspect traffic between users, devices and AI services. They find which AI apps are in use, tell corporate accounts from personal ones, apply DLP to prompts and uploads, and block unsanctioned tools. It is often the fastest way to see shadow AI used by people.

What they typically do not cover: traffic that never crosses the edge, such as an agent in your cloud calling an internal API. They see destinations and content, not the business meaning of a tool call, and they depend on TLS inspection being in place.

Examples:

• Zscaler: controls which AI tools users can access, shows input prompts, applies inline DLP and can render AI apps in browser isolation.
• Netskope: inline inspection across 1,800+ AI apps, separating corporate, personal and shadow AI, plus an inventory of AI agents and public MCP servers.
• Palo Alto Networks AI Access Security: shadow AI visibility, app classification as sanctioned, tolerated or unsanctioned, and scanning of prompts and attachments.

Red teaming and evaluation tools

Red teaming tools attack your own agents before someone else does. They send prompt injections, jailbreaks and tool-misuse attempts, score the results, and run in CI so regressions show up before release. The OWASP agentic top 10 makes a good test plan.

What they typically do not cover: anything at runtime. A passing run shows that the attacks you tried failed on that day. It does not stop the next one.

Examples:

• PyRIT: Microsoft's open-source Python Risk Identification Tool for generative AI (MIT license).
• garak: an open-source LLM vulnerability scanner that probes for prompt injection, data leakage, jailbreaks and other failures.
• Promptfoo: open-source red teaming for agents, RAG apps and chatbots, with CI/CD integration.
• Inspect: an open-source evaluation framework from the UK AI Security Institute, with agent evaluations and sandboxed execution.

Action-level authorization

Action-level authorization checks each tool call before it runs: the operation, its arguments, the record it touches, who the agent acts for, and limits such as amount per week. The answer is allow, deny or hold for a person. It decides whether this $4,500 refund should happen, not just whether the agent can reach billing. See AI agent authorization, spending limits and human approval.

What it typically does not cover: agents that bypass the enforcement point, code running on a host, and hidden instructions in content. It also needs each service's operations described, which takes owner time.

Examples:

• Open Policy Agent: a CNCF graduated, general-purpose policy engine with the Rego language; it makes decisions, and you wire in enforcement.
• Cedar: an open-source policy language for RBAC and ABAC that denies by default and lets forbid override permit.
• Amazon Bedrock AgentCore Policy: intercepts tool calls at AgentCore Gateway and checks identity and tool inputs against Cedar policies, which can be authored in plain English.
• Cerbos: externalized runtime authorization for apps, APIs, AI agents and MCP servers, with an open-source policy decision point.
• AgentFort Access: checks each REST or MCP call's identity, operation, arguments and target record before it reaches the service.

Coverage matrix: which category covers which control

The table shows general patterns as of October 2026, not ratings of any vendor. Products within a category vary, and suites span several rows. "Usually" means a core job of the category; "sometimes" means some products do it, or partly; "no" means outside its normal job.

Discovery and audit are widely covered, but each tool sees only its own slice. Authorizing actions and isolation are each a core job of one category only. Red teaming tests controls rather than enforcing them.

Build your stack: three example stacks

Most teams combine 3 or 4 categories. Start from the enforcement points you already run, then fill the gaps. These are illustrations, not product recommendations.

Cloud-native shop. Agents run as containers on AWS or Google Cloud and call internal APIs. Use AI-SPM for posture and the cloud's agent registry for inventory. Give workloads short-lived identities through cloud IAM or SPIFFE. Put an AI or MCP gateway on model and tool traffic, and action-level authorization in front of services that move money or hold customer data. Sandbox code-executing agents. Gap to watch: agents on laptops and SaaS platforms.

Microsoft-heavy enterprise. Most agents are built in Copilot Studio or Microsoft Foundry. Microsoft's stack covers a lot: Agent 365 as registry, Entra Agent ID, Purview for DLP and audit, Defender for posture, and Prompt Shields with the API Management AI gateway. Add SASE inspection for public AI apps. Gaps to watch: agents on other clouds, per-call checks on non-Microsoft APIs such as billing, and isolation for agents that run code.

Startup building its own agents. A few agents, one cloud, a small team. Keep it small and mostly open source: one gateway for model and MCP traffic, OPA or Cedar for the 3 to 5 risky actions, a guardrail library, a sandbox for code execution, and promptfoo or garak in CI. Gap to watch: shared API keys. Give each agent its own identity before the second one ships.

Where AgentFort fits

AgentFort is security for AI agents. For action-level authorization, AgentFort Access sits between agents and the services they call. It denies by default, holds large actions for a named approver, enforces budgets, and calls the service with its own scoped credential, so agents never hold the key. Around it, AgentFort Discover builds the inventory, AgentFort Identity uses existing identities or issues SPIFFE ones, AgentFort Data Protection inspects calls in both directions, and AgentFort Isolation contains code-executing agents. Every request gets a chained receipt. It works with your API gateway and identity provider rather than replacing them. All controls run end to end in a lab today. See AgentFort Access, watch a demo or become a design partner.