Routing Reports to Teams

Why It Matters

On a small program, one triager reads every report. As your program grows, a single queue becomes a bottleneck: a Payments bug and a Mobile bug land in the same pile, and the right engineer only sees the report if someone remembers to loop them in.

A component catalog fixes this. You describe your product areas once — “Payments API”, “Mobile App”, “Marketing Site” — and Kit suggests the owning area for every incoming report, hands ownership to that area’s default assignee, and pings the responsible team’s Slack channel once the report is validated. Routing stays best-effort and always human-confirmed: Kit proposes, your team decides.

What Is a Component

A component is a per-program catalog entry describing one product area under your Vulnerability Disclosure Program. Each component carries four things:

Field	Purpose
Name	The area label shown on reports and in Slack (e.g. Payments API). Required.
Description	A short summary of what the area covers. The AI classifier reads this when deciding where an ambiguous report belongs, so make it specific.
Scope patterns	URL globs matched against a report’s affected endpoint (see Scope Patterns below).
Slack channel	The responsible team’s channel. Gets a “Take it over” notification once a routed report is validated.
Default assignee	A team member who auto-owns reports routed to this area, if the report is still unassigned.

Only the name is mandatory. A component with just a name still works as a manual label; add scope patterns, a channel, and an assignee to unlock automatic suggestions and routing.

Setting Up Components

Open VDP > Program Settings > Components. The Components tab is the catalog — add, edit, and archive product areas here.

To add one, click New component, fill in the fields, and save:

• Give the area a clear name and a specific description
• Add one or more scope patterns, one glob per line
• Pick the responsible team’s Slack channel (optional)
• Pick a default assignee (optional)

New VDP subscribers also see an optional “Set up product areas” step during onboarding. You can complete it then or skip it and build your catalog later — nothing else depends on it.

Scope Patterns

Scope patterns are URL globs, one per line, matched against the affected endpoint a researcher enters on their report. They drive the deterministic half of routing: if a report’s endpoint matches exactly one component’s patterns, that component wins outright.

The one rule that trips people up: a pattern without a leading * is anchored at the start of the endpoint. Because affected endpoints are usually full URLs beginning with https://, you almost always want to wrap the meaningful part in * so it matches as a substring.

Matching is case-insensitive, and * matches across /, so *pay* is a true substring match.

Given the endpoint https://app.example.com/api/pay/charge:

Pattern	Matches?	Why
*pay*	✅	Leading and trailing * — matches “pay” anywhere in the string
*/api/pay/*	✅	Wildcards on both ends anchor the path segment wherever it appears
https://app.example.com/*	✅	No leading *, but the endpoint begins with exactly this text
app.example.com/*	❌	Anchored at the start — but the endpoint starts with https://, not app.
/api/pay/charge	❌	Anchored at the start — the endpoint doesn’t begin with /api/…

How Routing Works

Routing is suggest-only. Kit never silently reassigns a report — every step below surfaces a suggestion your team confirms.

1. Kit suggests an area

When a report is submitted, Kit picks a candidate component in two stages:

1. Deterministic match — if the report’s affected endpoint matches exactly one component’s scope patterns, that’s an unambiguous, full-confidence match.
2. AI classifier — if the patterns match nothing, or match two or more components ambiguously, an AI classifier reads the report against your component descriptions and proposes the best fit, or none.

Kit only surfaces a suggestion when it’s reasonably confident. If nothing fits, the report simply arrives with no suggested area — routing never blocks or delays a submission.

2. Staff confirm the area

On the report page, the sidebar shows an “Area / responsible team” card. When Kit has a suggestion, it appears as a “Suggested area” with a confidence percentage and a one-line reason. Your team then:

• Accept the suggestion, or
• Choose a different area from the picker, or
• Leave it unset.

Accepting a component sets the report’s area and, if that component has a default assignee, assigns that person as the report owner (unless someone already owns it). You can clear or change the area at any time from the same card.

3. The responsible team gets pinged

Once a routed report is validated (passes triage — see Triaging Reports), if its component has a Slack channel, Kit posts a notification card to that channel with a “Take it over” button. Any member of the team can click it to claim the report and become its owner. The ping fires exactly once per report, so re-validating or reassigning won’t spam the channel.

Do / Don’t

Do	Don’t
Wrap the meaningful path in * (*payments*)	Leave off the leading * and expect a substring match
Write specific descriptions — the AI classifier reads them	Rely on scope patterns alone for areas with fuzzy URL boundaries
Treat every suggestion as a proposal to confirm	Assume a suggested area is already assigned — it isn’t until accepted
Set a default assignee for areas with a clear owner	Point a component at a Slack channel Kit isn’t a member of
Archive areas you retire	Delete history — archiving preserves it

Managing via MCP Tools

The catalog is also available to AI agents and API clients through MCP tools, so you can build and route your catalog programmatically:

• csirt_list_components — list the catalog (read)
• csirt_create_component / csirt_update_component — add or edit an area (write)
• csirt_archive_component — retire an area (write)
• csirt_assign_component — set, clear, or ask for the suggested area on a report. Omit the component id to get the deterministic/AI suggestion without changing anything, then call again with the suggested id to confirm it.

Write tools require the csirt_write scope and always confirm before acting, mirroring the suggest-then-confirm flow of the UI. See AI Integration for the full tool reference and connection setup.

Archiving a Component

To retire an area, click Archive on the Components tab. Archiving is a soft delete:

• Reports already routed to the component keep their history — the area still shows on those reports.
• New reports stop routing to it — it disappears from suggestions and the picker.

This is the safe way to sunset a product area without rewriting the past. There’s no hard delete from the UI; archiving is intentionally reversible-safe rather than destructive.

Quick Checklist

• Create a component for each product area with a clear team boundary
• Write a specific description — the AI classifier depends on it
• Add scope patterns, wrapping the distinctive path in * (e.g. *payments*)
• Set a Slack channel so the owning team gets the “Take it over” ping
• Set a default assignee for areas with a clear owner
• On new reports, confirm or change the suggested area in the sidebar card
• Archive areas you retire instead of deleting them

Next Steps

• Triaging Reports — the triage board, SLA indicators, and the validation step that triggers team notifications
• Configuring Your Program — scope, SLAs, bounty matrix, and the rest of Program Settings
• AI Integration — the full MCP tool set, including the component catalog tools