Bring Your Own Key: How Vexta's AI Vulnerability Triage Works

AI vulnerability triage is the use of a language model to help decide which findings from a scan matter most and what to do about them, on top of the scanner's own detection and verification. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, runs this on a bring-your-own-key basis: you connect your own Anthropic, OpenAI, Gemini or Azure OpenAI account, Vexta caps what it spends per scan, and the feature is optional throughout.

What does bring-your-own-key actually mean here?

Rather than routing every user's AI calls through a shared account VITI Security pays for, Vexta lets you supply your own API key for Anthropic, OpenAI, Google Gemini, or an Azure OpenAI deployment. Vexta supports GPT-4 Turbo, GPT-4o and GPT-3.5 through OpenAI, Gemini Pro and Gemini 1.5 through Google, Claude 3 and later through Anthropic, and custom deployments through Azure OpenAI.

When more than one key is configured, Vexta picks in a fixed order: Anthropic first, then OpenAI, then Gemini, then Azure, using whichever is the first one with a value set. That means you control which provider handles your data and which model runs, rather than the scanner making that decision for you.

What AI triage actually does with a scan

AI involvement in Vexta spans a handful of specific capabilities rather than one generic "AI mode." Report enhancement uses AI to draft executive summaries and remediation language for a finished scan. Asset Insight, surfaced through a button in the interface, runs a per-asset attack vector analysis. Finding triage adjusts a finding's confidence based on surrounding context. Scan planning lets an LLM make next-step decisions when Vexta is running in autonomous mode, and a related capability handles AI-assisted configuration and security analysis of the target's setup.

There is also a discovery loop where, once an AI key is configured and the right profile is selected, an LLM examines each endpoint Vexta has crawled, proposes ranked ideas for what to probe next, fires those probes, and evaluates what comes back. Every one of those calls is logged, along with its prompt, its completion, and its cost, and the whole process respects the same per-scan cost ceiling as the rest of AI triage. Without a configured key, that same profile falls back to a fixed set of deterministic seed payloads instead of LLM-proposed ones, so the scan still runs.

None of these capabilities change what Vexta actually detects. They sit on top of the same 25+ vulnerability class detectors and the same finding data everyone else on the platform sees; what AI adds is a faster first pass at explaining, prioritizing, and probing that data, not a different set of findings underneath it.

Why cost-capping and opt-in status matter

Every AI capability in Vexta is cost-capped per scan, so a long or unusually chatty scan cannot run up an open-ended bill against your own provider account. It is also entirely optional: AI is off by default until you configure a key, and turning it off does not disable scanning. Vexta still discovers assets, runs its 25+ vulnerability class detectors, verifies findings through the proof-of-exploitation engine, and ranks results with the Vexta Confidence Score with no AI involved at all.

That separation is deliberate. The scanner's core findings and their proof status do not depend on an LLM being available or configured correctly; AI sits on top as an enhancement to summaries, triage, and autonomous decision-making, not as a dependency for whether a finding is real.

Because the scan's core work does not depend on AI, a hunter can turn triage on for a routine, low-sensitivity target where a faster draft summary saves time, and turn it off entirely for a client engagement where no scan data should ever leave the machine Vexta runs on, even to a provider you trust. That choice can be made target by target rather than committed to once for every scan.

Why bug hunters care about which provider handles the data

On an engagement with a strict client NDA, or a bounty program with rules about where scan data can travel, being able to name the exact provider and account that will see any AI-assisted analysis is not a minor detail. Bring-your-own-key means that decision stays with you: pick a provider you already have a relationship and data agreement with, or skip AI entirely for a particularly sensitive target and rely on the scanner's own detection and verification.

It also means switching providers, or dropping AI use altogether partway through an engagement, does not require a different tool or a different scan. It is a configuration change, not a workflow change.

This also matters when a program or client asks, directly, whether any part of their data touched a third-party AI service. With bring-your-own-key, the honest answer is specific and verifiable: either no key was configured for that scan, or a named provider and account processed a named set of prompts, each one logged with what it cost. That is a very different conversation than trying to explain a vendor's own AI subprocessor chain.

Setting expectations before you turn it on

AI triage adjusts confidence and drafts summaries; it does not replace the proof-of-exploitation engine's non-destructive verification, which stays evidence-based regardless of whether AI is configured. Treat AI output the way you would treat a colleague's first read of a finding: useful context and a starting draft, worth checking against the actual evidence before it goes into a client deliverable or a bounty submission.

Exactly which AI capabilities are available at each license tier is worth confirming on the pricing page, since bring-your-own-key covers the provider relationship, not which parts of the platform can call it.

Key takeaways