Build an Architecture, Not a Vendor Collection

One of the questions I've been getting a lot lately is some version of, "We're looking at several AI security vendors. Which one do you recommend?"

On the surface, that seems like a straightforward question. Usually it isn't.

A few weeks ago, I was reviewing a shortlist with a security team. They had five vendors they wanted to compare and asked which one was the strongest. The interesting part wasn't the products. It was that they weren't solving the same problem.

One focused on non-human identities. Another focused on employee AI usage. Another specialized in securing AI applications. Another emphasized detection and response. They all marketed themselves as AI security companies, but they were built to solve very different problems.

That's something I see fairly often right now. Teams compare products that aren't actually competing with one another. The better question isn't, "Which vendor is best?" It's, "What security problem are we trying to solve?"

When people say "AI security," they're usually lumping together several different security challenges. In practice, organizations are trying to answer questions like: Who or what is acting? What is that identity allowed to do? How are employees using AI? Are our AI applications secure? Can we detect attacks involving AI? Can we demonstrate governance and control? Those are related questions, but they aren't the same question. If you expect one product to solve all of them, you're probably going to be disappointed.

Instead of starting with a vendor comparison, I like to start with the security architecture. Most organizations already understand identity and access management, least privilege, logging, monitoring, governance, and risk management. AI doesn't replace those security principles. It extends them. That's why I find it more useful to think about securing the AI lifecycle than buying an "AI security platform." Starting from the architecture also keeps you vendor-neutral. It gives you a durable way to evaluate any product against the capabilities you actually need, including vendors that haven't even entered the market yet.

The capability map I use is straightforward. Identity answers the question, Who or what is acting? That includes users, AI agents, service accounts, workload identities, and other non-human identities. Access answers, What is that identity allowed to do? This is where concepts like least privilege, role-based access control, delegated permissions, secrets management, and approval workflows become important. Usage focuses on how employees are using AI, including shadow AI, sensitive prompts, acceptable-use policies, and data loss prevention. Applications covers building and securing AI-enabled applications, including prompt injection, retrieval-augmented generation (RAG), guardrails, and runtime protections. Operations includes logging, monitoring, threat detection, investigation, incident response, and integrating AI telemetry into your existing security operations center, or SOC. Finally, Governance addresses ownership, risk assessments, policies, evidence collection, auditability, and demonstrating compliance.

Once you've defined those capabilities, evaluating vendors becomes much easier because you're comparing products within the same category instead of comparing products designed for entirely different purposes.

One thing that's becoming increasingly difficult is separating vendors based on feature lists alone. Many products now advertise agent discovery, Model Context Protocol, or MCP, visibility, prompt inspection, sensitive data protection, runtime monitoring, policy enforcement, and prompt injection detection. After a while, every datasheet starts to sound the same.

It also helps to remember that the same words can describe very different capabilities. "Agent discovery," for example, might mean identity discovery, credential discovery, endpoint discovery, application inventory, gateway visibility, or runtime interaction monitoring, depending on the vendor. Those are related, but they aren't interchangeable. That's why I try to validate claims like these through demonstrations and proof-of-value testing rather than taking a datasheet at face value.

When that happens, I stop asking whether a vendor has a particular feature. Instead, I ask what the product was originally built to do. That's usually where you'll find its deepest capabilities, the strongest engineering investment, and the clearest long-term roadmap. Everything else may still be useful, but it may not be the product's primary strength.

For most security organizations, especially lean teams, simplicity matters. If I were building an AI security architecture today, I'd probably start by establishing identities for AI agents, workload identities, service accounts, and other non-human identities so every action can be traced back to an owner. Next, I'd gain visibility into how employees are already using AI across the organization. Then I'd focus on securing internally developed AI applications before expanding autonomous access to sensitive systems. After that, I'd integrate AI telemetry into existing SOC workflows rather than creating a separate AI security operation. Finally, I'd strengthen governance by maintaining an inventory of AI systems, assigning ownership, collecting evidence that controls are working, and regularly reviewing risk.

You don't have to solve every category on day one. As your organization's AI adoption grows, your security architecture should grow with it.

It's also important to remember that technology isn't the whole answer. Even with the right tools, organizations still need to decide which AI use cases are approved, who owns each AI system, how systems are risk-tiered, which actions require human approval, and what evidence auditors or regulators will expect. Those are governance decisions, not product features.

The same is true for secure AI engineering practices. Threat modeling, supply chain security, retrieval-augmented generation security, evaluation criteria, release gates, rollback planning, and action-level authorization all require thoughtful processes in addition to technology. Good tools can support those efforts, but they don't replace them.

Two areas are especially easy to overlook.

The first is data governance. Inspecting prompts and responses for sensitive information is valuable, but it's a different discipline from governing the data that actually powers your AI systems, which means deciding which documents may be indexed, how authorization is enforced inside retrieval, how long embeddings are retained, and which data may be used for fine-tuning or allowed to leave the organization at all.

The second is third-party AI risk. Many of the platforms you already use are quietly adding generative AI features, so it's worth asking which models they rely on, whether your data is retained or used for training, whether the functionality can be disabled, and how AI incidents would be disclosed. Traditional third-party risk management matters just as much in the AI era.

Before adding another AI security product, it's worth taking inventory of what you already have.

Identity governance, privileged access management, secrets management, data loss prevention, cloud access security brokers, secure service edge solutions, API security, cloud-native application protection platforms, SIEM, XDR, and governance, risk, and compliance platforms often provide capabilities that can be extended to support AI security.

In many cases, AI security is less about replacing your existing architecture and more about building on the security controls you already trust. For a small security team, reducing operational complexity is often just as valuable as adding another standalone tool.

When you do get to the point of comparing products, I'd push past the feature list and look at how each one actually operates.

• What telemetry does it draw on, whether that's browser, endpoint, API, cloud, application, agent, gateway, or MCP activity?
• Is enforcement inline, or is it monitoring only?
• Can it actually block, redact, rotate credentials, revoke access, or quarantine activity, or can it only alert?
• Can it connect an agent back to its owner and the identities it uses?
• What data has to leave your organization to be analyzed?
• And which capabilities are generally available today versus still on the roadmap?

Those questions tell you far more about a product's real depth than any feature comparison will.

The AI security market is changing quickly. Vendors will continue adding features, acquiring competitors, and repositioning themselves.

The underlying security principles, however, remain remarkably consistent.

1. Build an architecture instead of a vendor collection.
2. Start with the risks your organization is actually trying to manage, map those risks to security capabilities, and then choose the products that best strengthen the architecture you already have.

That's a strategy that will continue to serve you well, even as the AI security market evolves.