Vulnerability Triage Agent
Tells you which five to patch, and why the other four hundred can wait
6 of 11 findings need action now or soon, led by CVE-2026-1002.
11 findings triaged. 6 are flagged for 24 priority points; the oldest flagged is 75 days old.
CVE-2026-1002 comes first. Payments API has the most urgent findings.
CVSS is a severity score, not your risk: asset value and compensating controls are not in the data.
Why rows were flagged
- High severity, open over 30 days50%
- Exploited and internet-facing25%
- Critical and internet-facing13%
- Actively exploited13%
Value flagged by System
- Payments API1
- Build server1
- Web gateway1
- VPN1
- ERP2
Findings to fix, highest priority first
| Item | System | Value | Days | Why |
|---|---|---|---|---|
| CVE-2026-1002 | Payments API | 5 | 40 | Critical and internet-facing, High severity, open over 30 days |
| CVE-2026-1007 | Build server | 5 | 33 | Actively exploited, High severity, open over 30 days |
| CVE-2026-1001 | Web gateway | 5 | 12 | Exploited and internet-facing |
| CVE-2026-1004 | VPN | 5 | 5 | Exploited and internet-facing |
| CVE-2026-1003 | ERP | 2 | 75 | High severity, open over 30 days |
| CVE-2026-1009 | ERP | 2 | 61 | High severity, open over 30 days |
What to do this week
- Patch or isolate CVE-2026-1002 today: it is the first priority.
- Review everything on Payments API as one change.
- Patch every exploited or internet-facing critical finding before any other.
Do
- Rank by exploitation and exposure first, CVSS second.
Don't
- Don't sort the backlog by CVSS alone.
How to improve
- Add asset criticality so the next report can weigh each finding by what it protects.
- Add the patch owner and due date so the next report can track fix times.
Demo
Overview
A scanner reports four hundred findings. Sorting them by CVSS is not triage — severity is a property of the vulnerability, not of your risk. A critical in a dependency you never call is less urgent than a medium on an internet-facing service holding customer data.
This agent triages against your stack: what you actually run, which components are exposed, and which hold sensitive data. It returns a short ordered list of what to fix now, with the reasoning for each position.
Its more useful half is the dismissal. Every finding it sets aside is listed with why — not reachable, not exposed, compensating control in place, version not affected. That record is what turns a backlog into a decision you can defend to an auditor, and it is what no scanner gives you.
Benefits
~5 actionable
A week's work becomes a morning's
Five ranked items instead of four hundred rows.
Defensible to an auditor
Every deferral has a recorded rationale.
Fewer pointless patches
Effort goes where exposure actually is.
What it does
Ranks by your exposure, not by CVSS
Internet-facing, holding data, actually reachable — the factors that decide real risk.
Dismissals carry reasons
Every set-aside finding records why, so the backlog becomes a defensible decision.
Knows what you do not run
Findings for components absent from your stack are excluded, not ranked low.
Credits compensating controls
A WAF rule or network boundary that genuinely reduces exposure is reflected in the ranking.
Says when it cannot tell
Where reachability is unknown, it says so and ranks conservatively rather than guessing.
What this changes
What this changes about your week
- It takes over
- Deciding which findings actually matter to your deployment.
- Done today by
- A security engineer, drowning in scanner output.
- How often
- Every scan.
- Typical manual effort
- Triaging a few hundred findings honestly is days.
Why Cybersecurity in particular. A scanner sorted by severity is not a plan. Reachability is what decides whether a critical finding is a fire or a footnote.
Runs unattended
Started by you or by an event, and it finishes on its own. Nothing waits for someone to be at a desk.
The same standard every time
The two-hundredth item is held to the bar the first one was. Consistency is the part people cannot sustain.
It cannot act on its own
Vulnerability Triage Agent has no path to sending, spending or committing. That limit is why its output is safe to act on.
How it runs
This agent runs server-side through the PROMIVO runtime. Each run is logged step by step and every tool call is permission-checked before it executes.
- 1InputValidated against the agent input schema
- 2Modelclaude-opus-5 with automatic fallback
- 3Toolsfetch_web_page, extract_structured_data
- 4PermissionsRuns READ actions automatically; anything higher waits for approval
- 5OutputStructured result matching the output schema
- 6LoggingTokens, duration and every step recorded
Requirements
Integrations
No integrations required.
Before you start
- Your stack: components and versions
- Exposure: what is internet-facing, what holds sensitive data
- The findings or advisories to triage
- Requires the All-Access plan or higher
Use cases
Weekly scanner output
Turn a recurring dump into a short ordered queue.
A named advisory lands
Answer 'does this affect us' with reasoning rather than a guess.
Audit preparation
Produce the rationale record for everything deferred.
Pricing
All-Access
Billed monthly through your PROMIVO subscription. Cancel at any time.
Runs consume your plan allowance for agent executions and tokens. See plan limits
FAQ
Does it patch anything?
No, and it cannot. It analyses and recommends. Any change to a running system requires a person — that boundary is enforced by the agent's permissions, not only by its instructions.
How does it know a finding does not apply?
From the stack you describe: components, versions, what is internet-facing, what holds sensitive data, and your compensating controls. Where your description does not settle it, it says so rather than assuming.
Can it replace a scanner?
No. A scanner finds; this decides what to do about what was found. Give it your scanner output.
Reviews
Reviews open once customers have run this agent.
Need this agent to work differently?
Tell us what to change and our team will scope a customised version for your business.
Customize this agent