Finding deduplication assist
- Appears
- AI review, proposing identity merges the rules missed, which a person accepts or rejects
- Grounded in
- Identities on the same hosts from different scanners, with their titles and ids
Fifteen AI tasks sit inside the screens where vulnerability work already happens. They draft fix instructions from your own past fixes, propose plans for findings nobody owns, group a campaign by the one change that fixes it, and turn a sentence into a triage rule. Each runs on the model you choose, local by default, and each stops at a proposal a person accepts. Remediation guidance is in every edition; the other tasks come with Professional and Enterprise.
Most of a remediation cycle is not the patch. It is writing up the fix for each team, grouping hosts that share a cause, deciding which plan a new vulnerability belongs in, and documenting what worked. PYXA's AI drafts each of those where the work happens, from data your instance already holds.
Every draft below was written by qwen2.5:7b on Ollama, on the same network as PYXA, against the demo estate. Nothing left the environment.
Asked to draft the Struts emergency, the model proposed upgrading to 6.4.1 or later on the 25 payments hosts still open, Windows first, following the team's recorded procedure FIX-001 in a change window. It kept PYXA's rule that the finding closes only when a verifying scan no longer reports it.
The plan's owner accepts the wording or rejects it. Accepting changes the title and description, nothing else: no status, no priority.
1,796 open findings sat in no plan. The model proposed six plans to cover them; PYXA ordered them by risk, then blast radius, then compliance, then quick wins, and set nothing until a person decided.
A reviewer rejected three. Cisco IOS and ASA do not share a patch, and neither do MongoDB and PHP. The rejections stay on screen with their reasons, so anyone can see where the model was overruled.
Typed "everything failing verification", the model mapped the sentence to the Failed verification view and said so before anything changed. A person clicks Apply. The model never filters a list on its own, and never answers from its own memory: it only picks among the filters the page already has.
Root-cause clustering, knowledge drafting, rule drafting from a sentence and AI triage work the same way, each as a proposal a person accepts. They draft best with a larger model, and Enterprise routes each task to the model that suits it.
Each task is listed as the AI page lists it: where it appears, and what it is grounded in. Each can be routed to its own provider or switched off on its own.
Bring your own provider in any edition: a local model (Ollama or any OpenAI-compatible endpoint), a LiteLLM proxy, OpenAI or Anthropic. Enterprise routes each task on its own, so sensitive tasks can stay local while others use a larger model. The table says, task by task, exactly what would leave your environment. On a local model the answer is nothing.
Every prompt is kept in an audit log an administrator can read. Turning every provider off leaves a working product: no feature in PYXA requires a model.
Only a verifying scanner observing the vulnerability gone can do that. A model's opinion that a fix worked is a claim, like a patch report.
Risk acceptance is a decision with a named owner and an expiry, approved by someone other than the person who asked. Exception review is switched off by design.
A band comes from the score's named contributions. AI can propose which plan a vulnerability belongs in; it cannot make it more or less urgent.
Run the free edition on your own server today, or see PYXA on your own scanner data in a 30-minute demo.