There’s Something Missing in the Discussion About AI in Vulnerability Management

Why trusted exposure intelligence may matter more than the model itself.

John Morton
October 19, 2026
Industry Perspectives
AI in Vuln Management Conversation Blog Thumbnail

The platform determines what is known. AI helps determine what it means. 

Technology solution providers across virtually every industry are racing to add AI, in some fashion, to their offerings. Vulnerability management providers aren’t immune, either. They’re racing just as fast as the rest of them, sometimes faster. 

These vendors are embedding copilots, assistants, and agents powered by technologies like Anthropic Claude, OpenAI GPT, and Google Gemini. They promise faster investigations, automated reporting, natural-language search, and remediation recommendations. 

Those benefits are real and compelling, but are we asking the wrong questions in the quest for better vulnerability management? 

Yes, it’s important to ask, “Which AI model does your platform use?” The more interesting question is β€œWhat security context is the AI operating against?” 

Ultimately, vulnerability management isn’t an AI-only problem. It is a data and context problem. The platform you’re using determines what you know; AI helps determine what that means to your organization. 

Vulnerability Management Has Always Been About ContextΒ 

Most organizations already have all the vulnerability data they need from their scanners, asset inventories, cloud security tools, attack-surface monitoring, threat intelligence feeds, ticketing systems, and remediation workflows. 

That data, each item taken on its own, doesn’t remotely begin to paint a clear picture of what’s happening. An exposure management platform properly augmented by AI takes the following factors… 

  • Which assets matter most
  • Which vulnerabilities pose the greatest business risk
  • Which exposures are actively exploitable
  • Who owns remediation
  • What compensating controls already exist
  • What action should be taken firstΒ 

…and connects those relationships into a coherent picture that users can consume more efficiently, with the proper high-quality security context embedded. 

The Difference Between Deterministic and Probabilistic IntelligenceΒ 

The terms β€˜deterministic’ and β€˜probabilistic’ are rising in relevance and importance as AI adoption soars. Let’s take a look at each, and why they matter. 

Deterministic: of or relating to a process or model in which the output is determined solely by the input and initial conditions, thereby always returning the same results. 

Probabilistic: based on or relating to how likely it is that something will happen. 

AI models are probabilistic in nature. They assess inputs and make decisions based on algorithms that statistically provide a likely answer or response. The proof comes in a simple test: feed the same request with the same parameters into the AI chat of your choice several times and review the results. You won’t get the same answer every time. You might get a similar response, but the details will be different. That is a probabilistic response. 

Deterministic systems, i.e. automation rules, will give you the same response every single time, as long as the input is the same. Both have their place, but the distinction becomes important when evaluating AI-enabled vulnerability management solutions. 

Exposure management platforms operate on deterministic security data: 

  • Assets
  • Vulnerabilities
  • Owners
  • Controls
  • Exceptions
  • Tickets
  • Remediation statusΒ 

These are facts. 

As I mentioned earlier, AI models operate probabilistically. They generate responses by identifying patterns and probabilities within the context provided to them. Depending on AI models to present defensible, trustworthy exposure management decisions is difficult at best, because of their probabilistic nature. 

For exposure management, the best AI experiences occur when deterministic security intelligence leads the way, probabilistic reasoning working as a second layer on top of those processes. In other words: 

The platform determines what is known. AI helps determine what it means. 

This is why the underlying data model often matters more than the underlying LLM. Many of the underlying LLMs will offer similar speed and reasoning capabilities to each other, but the underlying data model can make (or break) the process, and your exposure management program, before the LLM even touches the data. 

Why Embedded AI Is AttractiveΒ 

In addition to the debate about different LLMs and AI models, there’s also the conversation around whether it’s better to embed AI in a platform or use external tools. While connecting to external AI offers advantages like choice and flexibility, there are equally good reasons vendors are embedding AI directly into their products. 

Faster Time to ValueΒ 

Customers can immediately begin using AI-powered workflows without deploying additional infrastructure. 

Simplified ExperienceΒ 

Built-in copilots can provide reporting, summarization, and investigation assistance directly within the product. 

Continuous InnovationΒ 

Vendors can rapidly introduce new AI-driven capabilities without requiring customers to integrate external platforms. 

For many organizations and their customers, these advantages are compelling enough to offset the flexibility gained via the alternative. 

However, embedding a specific AI model creates an architectural decision that customers may not ultimately want their vulnerability management vendor making for them. 

Enterprise AI strategies and capabilities are changing rapidly. Remember at the beginning, OpenAI’s ChatGPT seemed years ahead of its competition in many ways. The landscape has shifted, several times, over a short period of time.  

The model that appears dominant today may not be the model a customer prefers next year. When AI is deeply embedded into a platform, customers inherit part of the vendor’s AI strategy and become locked into their AI decisions. 

There is also a practical reality that vulnerability management vendors cannot predict their customers’ long-term AI strategies. Some enterprises may standardize on Microsoft Copilot and Azure OpenAI. Others may require sovereign AI deployments for regulatory reasons.  

Some organizations may determine that certain AI providers do not align with their procurement, privacy, geopolitical, or risk-management requirements and choose never to adopt them. In those environments, a vulnerability management platform tightly coupled to a specific AI provider can unintentionally create friction where security teams simply want the flexibility to leverage AI that aligns with their broader enterprise strategy. 

This becomes particularly important in large enterprises, where AI decisions are increasingly being made by CIOs, legal teams, procurement organizations, data governance boards, and risk committees rather than by individual security teams. A security platform that mandates a specific AI provider may be introducing constraints that have little to do with vulnerability management and everything to do with broader corporate AI policy. 

But wait. Should our vulnerability management vendor be selecting our AI strategy at all? 

That question shifts the discussion away from which model is ’bestβ€˜ and back to the more fundamental challenge: delivering trusted security context, accurate exposure intelligence, and actionable risk insights regardless of which AI technology an organization chooses to adopt. 

Why Many Security Leaders Are Prioritizing FlexibilityΒ 

A growing number of organizations are beginning to view AI models as interchangeable components rather than long-term strategic differentiators. Part of this might be due to the advances in these technologies, or possibly organizations’ approaches to AI are maturing alongside the technology itself. 

The larger challenge is building trusted context around the model. 

The NIST AI Risk Management Framework emphasizes trustworthiness, governance, and risk management as critical elements in AI systems rather than focusing solely on model performance. 

That philosophy aligns closely with exposure management. 

  • The underlying data is accurate
  • The relationships are meaningful
  • The risk calculations are defensible
  • The recommendations are explainableΒ 

The AI is helpful. The context is essential. 

The Nucleus Perspective: Command Your Own AIΒ 

This is one reason a ’command your own AIβ€˜ approach can be compelling for exposure management. 

Rather than forcing customers to adopt a specific AI provider, the platform focuses on delivering rich, trusted security context while allowing organizations to leverage the AI technologies that align with their own enterprise strategy. 

  • Nucleus provides exposure intelligence.
  • Customers choose the AI.
  • Security data remains the source of truth.
  • AI becomes the interface for interacting with that data.Β 

As AI capabilities continue to evolve, organizations can adopt new models without rebuilding their vulnerability management program. 

This philosophy reflects a broader belief that customers should own their AI strategy, while Nucleus focuses on providing the exposure intelligence, context, and security relationships that make any AI strategy more effective. 

MCP and the Future of Security AIΒ 

The emergence of Model Context Protocol (MCP) reinforces this trend. 

Rather than embedding intelligence into every security product, MCP enables organizations to connect trusted AI systems with authoritative data sources through standardized interfaces. 

The concept is remarkably similar to ideas being discussed across the broader AI industry: the long-term value may not come from owning the model, but from providing the most trusted context around the model. 

That is also reflected in the ontology concepts popularized by Alex Karp and Palantir, where a governed contextual layer sits between enterprise systems and AI applications. Applications and AI agents consume trusted context instead of operating directly against disconnected data sources.Β 

For vulnerability management, the equivalent is an exposure intelligence layer that connects assets, findings, threat intelligence, ownership, remediation, exceptions, and business context before AI ever enters the conversation. 

The AI becomes more valuable because the context becomes more valuable. 

Trusted Exposure Intelligence Will Remain IntegralΒ 

The future of vulnerability management AI is unlikely to be determined solely by which vendor embeds the smartest AI model or frontier capability. 

AI models will continue to improve. Model leaders will change. 

What will remain valuable is the ability to provide trusted security context, meaningful relationships, and accurate exposure intelligence. 

The organizations that succeed will be those that separate the security data foundation from the AI layer, allowing customers to adopt the models they prefer while maintaining confidence in the underlying security intelligence. 

AI may become a commodity. Trusted exposure intelligence will not. 

As generative AI becomes even more ubiquitous than it already is, vulnerability management platforms will increasingly be judged not by which LLM they embed, but by the quality of the context they provide. The winners will be the platforms that help organizations understand risk, prioritize remediation, and reduce exposure, regardless of which AI technology sits on top. 

Because in the end, customers should own their AI strategy. 

The vulnerability management platform should provide the intelligence that makes that strategy successful.

John Morton
John is a field-facing cybersecurity executive with 15+ years leading high-performing technical sales teams. He has deep expertise designing and scaling cloud-native security solutions across AWS, Azure, and GCP, specializing in identity, access governance, Zero Trust architectures, and entitlement management. As a veteran leader, he blends technical depth, pre-sales excellence, and strategic vision to accelerate growth, customer trust, and market leadership.

See Nucleus in Action

Discover how unified, risk-based automation can transform your vulnerability management.