AI Security Tools List: The 14 Categories That Actually Show Up in Enterprise Architecture

The AI security category has fragmented into 14 distinct tool types over the past 18 months. The fragmentation tracks the AI stack: model security, agent security, gateway security, data security, infrastructure security, and process security each have their own vendor cohort. Buyers who treat the category as one bucket end up with overlap across three or four categories and gaps at the enforcement layer. Buyers who read the category map first can build a stack that covers the stack without spending three times what is needed.

The most common buying mistake is purchasing in the wrong order. Teams buy a model security tool, then discover they need a gateway. Teams buy guardrails, then discover the guardrails cannot enforce policy on traffic the application bypasses. The category that has to be in place before others are useful is the enforcement layer.

I want to walk through the 14 categories, what each covers, where each sits in the architecture, and the order in which they actually need to be deployed.

The 14 categories

The categories below are listed in approximate deployment order. The first three are the foundation. The next four are the depth layer. The last seven are specialist categories that come in when the first seven are in place.

Category 1: AI gateway / policy enforcement

The AI gateway sits between authenticated users or agents and any LLM endpoint. It intercepts the HTTP traffic, verifies identity, applies policy, routes to the correct model, and writes a per-decision audit record. The category includes DeepInspect, Aporia (governance focus), Credal, Bedrock Guardrails (AWS-locked), Azure Content Safety (Microsoft-locked), and the open-source LLM gateways like LiteLLM with a policy layer added.

The gateway is the enforcement point for residency rules, data classification rules, allow-list rules for model endpoints, and tool-use authorization for agents. It is also the source-of-record for audit trails. Without a gateway, the rest of the categories operate on incomplete data because they only see the traffic that happens to flow through whichever path they monitor.

Category 2: AI DLP

AI DLP detects and redacts sensitive data in AI prompts and responses. PII, PHI, financial account data, source code, secrets, and customer records each need their own detection ruleset. The category includes Nightfall (cloud DLP retrofit), Lakera (acquired by Check Point), Polymer, and the AI DLP modules from established DLP vendors like Symantec and Forcepoint.

AI DLP is most effective when integrated at the gateway. A standalone AI DLP that operates on application logs misses the actual prompt content if the application bypasses the DLP. A gateway-integrated AI DLP sees every request because the gateway is the chokepoint.

Category 3: AI security posture management (AI SPM)

AI SPM discovers AI assets across an environment, inventories model usage, identifies shadow AI deployments, and reports on configuration posture. The category includes Wiz AI-SPM, Orca AI Security Posture Management, and HiddenLayer's posture-management tier.

AI SPM is the visibility layer. It tells the security team what AI is running where, who is using it, and whether the configuration matches policy. It does not enforce. Enforcement requires the gateway category.

Category 4: Model security

Model security covers the model itself: training data integrity, model weight protection, model serialization vulnerabilities, and model evasion attacks. The category includes Protect AI (acquired by Palo Alto), HiddenLayer, the Cisco AI security tier (built on the former RI acquisition), and the open-source projects from MITRE's ATLAS framework.

Model security matters most for organizations that train, fine-tune, or host their own models. Organizations that consume models via API (OpenAI, Anthropic, Bedrock) need much less of this category because the model security is the provider's responsibility.

Category 5: AI guardrails

Guardrails are content-filter and behavior-constraint layers that sit at the model interaction point. Input filters block prompt injection attempts. Output filters block disallowed content categories. Behavior constraints prevent the model from disclosing system prompts or executing tool calls outside an allow list.

The category includes NeMo Guardrails (NVIDIA, open source), Bedrock Guardrails (AWS), Azure Content Safety (Microsoft), LLM Guard, and Guardrails AI. The category has consolidation: most guardrails ship as a feature inside a gateway product now rather than as standalone tools.

Category 6: Agent identity and authorization

Agent identity is the category for AI agents that act on behalf of users or services. The agent needs an identity that is not the static service credential the application uses. The category includes Astrix (acquired by Cisco), Oasis Security, Anetac, Britive, and the agent-identity modules from established IAM vendors like Okta and CyberArk.

Agent identity matters because tool-use authorization fails without it. The decision to permit an agent to call a specific tool depends on knowing the agent's identity, the user the agent represents, the policy that applies to that combination, and the request context. Static service credentials collapse all of this into one undifferentiated identity.

Category 7: AI red teaming and adversarial testing

Red-teaming tools run adversarial prompts, jailbreak attempts, and model-evasion attacks against AI systems to find vulnerabilities before deployment. The category includes Lakera Red, the Cisco adversarial testing tier, HiddenLayer's adversarial testing, and the open-source PyRIT, garak, and Promptfoo projects.

Red teaming is testing, not enforcement. The output of a red-teaming engagement is a list of vulnerabilities that the gateway and guardrails categories then have to address. Red teaming without a gateway to enforce the findings is a report-generation exercise.

Category 8: AI model risk management (MRM)

Model risk management extends the traditional financial-services MRM discipline (SR 11-7 in the US, PRA SS1/23 in the UK) to AI and LLM systems. The category covers model documentation, validation, performance monitoring, and version control. Vendors include ValidMind, RiskLens, the AI extensions from Moody's, S&P, and the established financial-services MRM platforms.

MRM is most relevant for regulated financial-services deployments. The audit-trail outputs from the gateway feed MRM. The MRM platform itself does not enforce.

Category 9: AI observability and evaluation

AI observability tracks model performance, drift, latency, cost, and quality over time. The category includes Arize, Fiddler, Galileo, Langfuse (open source), Helicone, and the LLM observability tiers from Datadog and New Relic.

Observability is operational, not security-first. The category overlaps with model risk management on monitoring and with AI SPM on inventory, but its primary purpose is engineering reliability, not policy enforcement.

Category 10: AI third-party / vendor risk management

AI TPRM covers vendor diligence for AI providers and AI features inside vendor products. Specialized questionnaires, AI-specific contract clauses, and ongoing vendor monitoring fall here. Vendors include Vendia, the AI extensions from OneTrust, ProcessUnity, and BitSight.

The category matters because most enterprise AI usage is third-party model APIs. The contract is the first line of liability, the gateway is the second, and the audit log is the evidence.

Category 11: AI incident response and forensics

AI incident response covers playbooks, evidence collection, and post-incident analysis for incidents involving AI agents and AI-related attack paths. The category is nascent. Most vendors in adjacent categories ship some incident-response tooling. Dedicated vendors include the AI extensions to security incident management platforms.

The gateway audit log is the primary forensic artifact. Without it, AI incident response runs on application logs that lack identity and policy context.

Category 12: AI training data security

Training data security covers data lineage, poisoning protection, and PII handling in training datasets. The category is most relevant for organizations that train or fine-tune models. Vendors include the AI extensions from established data-governance platforms (Collibra, Alation), Protect AI's training-data tier, and dataset-scanning tools.

Category 13: Federated learning and privacy-preserving ML security

Federated learning security covers cryptographic protocols for distributed model training, secure aggregation, and differential privacy. Vendors include Duality, Inpher, and the privacy-preserving ML extensions from major cloud providers.

The category is highly specialized. Most enterprises do not need it. Healthcare consortia and financial-services data-sharing arrangements are the primary use cases.

Category 14: AI supply chain security

AI supply chain security covers model provenance, AIBOM (AI bill of materials), and the dependency graph for AI systems. The category overlaps with traditional SBOM tooling. Vendors include the AI extensions from Anchore, Snyk, and the SBOM-tooling cohort.

What to ask vendors before buying

The five questions that disambiguate vendors across these categories:

1. Where does the tool sit in the data path? Gateway tools sit inline. SPM tools sit out-of-band. Guardrails tools sit at the model interaction point. The answer determines whether the tool enforces or observes.
2. What does the tool produce as audit evidence? A tool that produces audit records suitable for EU AI Act Article 12 or NIST AI RMF MEASURE.2.7 is enforcement-tier. A tool that produces dashboards is observation-tier.
3. Is the tool model-provider-locked? Bedrock Guardrails covers AWS-hosted models only. Azure Content Safety covers Microsoft-hosted models only. Identity-aware gateways that intercept HTTP traffic to any model endpoint are provider-neutral.
4. What identity does the tool see? A tool that operates on the application's service credential sees the application, not the natural person. A tool that propagates the authenticated caller's identity into the policy decision sees the natural person.
5. Does the tool fail closed or fail open? A guardrail that defaults to "allow" when its evaluation times out is not a security control. A gateway that fails closed under the same condition is.

DeepInspect

DeepInspect operates in Category 1: AI gateway and policy enforcement. It is the layer that turns the recommendations of every other category into enforced policy on actual traffic. Identity propagation, classification evaluation, per-route policy, fail-closed defaults, and per-decision audit records all execute at the gateway. The audit records are the primary evidence artifact for the EU AI Act, NIST AI RMF, ISO 42001, DORA, and HIPAA.

The gateway category is the foundation. The other 13 categories layer on top of it. Buyers who start with a gateway end up with a coherent stack. Buyers who start with category 4 (model security) or category 7 (red teaming) end up with reports that they then need a gateway to act on.

If you are mapping your AI security stack and want to know which categories you actually need and in what order, book a demo today.