the triage agent burned its whole ticketing API quota re-filing false positives before it reached the real CVEs

TL;DR: The agent filed tickets in scan order - noise first, real CVEs never. Reorder the pipeline so dedup and suppression happen before any ticket API call, sort what remains by severity and KEV status, cap tickets per run, and dry-run the diff before spending quota.

the triage agent burned its whole ticketing API quota re-filing false positives before it reached the real CVEs

Steps

1. Audit what the quota went on: pull the last run's ticket list and label each as true positive, false positive, or duplicate.

Expected: most of the spend was duplicates and known false positives.

1. Reorder the pipeline: dedupe against existing tickets first, apply the suppression list second, severity-sort (critical and high, KEV members first) third - and only then call the ticketing API.

Expected: the API only ever sees findings worth a ticket.

1. Add a per-run ticket cap with an overflow queue: when the cap is hit, the run stops filing and pages the pipeline owner instead of burning quota silently.

Expected: one noisy run can never spend the whole quota again.

1. Dry-run the ticketing diff before filing: log exactly which tickets would be created, and require the count to be sane before the real calls go out.

Expected: a human or a guardrail sees "400 new tickets" before the API does.

1. Re-run against the backlog: file the real CVEs that never got tickets, in severity order.

Expected: genuine criticals get tickets first this time, inside quota.

Use this when

• Ticketing API quota or rate limits get exhausted by the triage agent
• False positives and duplicates are filed as tickets before real findings
• The backlog has tickets for noise but no tickets for genuine criticals
• You need a guardrail so one bad scan cannot spend the whole budget

Not for this skill when

• The quota problem is elsewhere (another integration shares the key) - fix the sharing first
• Every finding is a genuine new critical - raise the quota, the pipeline is fine
• Tickets are filed manually - this is an agent-pipeline ordering problem

Variant phrasings

• vulnerability scanner filed hundreds of false positive tickets
• triage agent exhausted ticketing API quota on duplicates
• how to rate limit automated CVE ticket creation

Why it happens

The pipeline treated the ticketing API as step one ("file everything, sort it out in the tracker") instead of the last step. Scanners emit findings in their own order - often alphabetical or by layer, not by severity - so the agent filed hundreds of low-value tickets first and hit the quota wall before reaching the criticals. The quota did not run out because there were too many real CVEs; it ran out because nothing filtered the noise before the meter started running.

Edge cases

• Dedupe against the tracker, not just within the run - re-filing "the same finding under a new scan ID" is the classic quota burner.
• A severity-sorted queue can starve mediums forever - age the queue so old mediums eventually surface.
• If the ticketing system charges per API call rather than per ticket, batch aggressively - one call per ticket is the most expensive shape.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KTQAfqiK8PGd-P7Vl4Ikbw