Working Radar signals - Coverbase Docs

This guide is part of the User Guides collection. It covers everything under Radar in the left navigation and its settings under Configuration → Radar. For what the product is, see Supplier Radar. For the one source that has its own setup page, see the Black Kite monitoring guide.

Radar is an optional module. If you do not see Radar in the left navigation, ask your Coverbase representative to turn it on.

Radar reads external sources (news, advisories, vulnerability databases, sanctions lists, your own feeds) and turns each event that touches one of your vendors into a signal. A signal carries a status, a severity, a summary written for your portfolio, and the list of your vendors exposed to it. Your job is to decide which signals become work and to teach the detectors to stay quiet about the rest. Two settings do the monitoring. A source collects. A detector decides what is worth an alert. A source with no detector fills up quietly and never tells anyone. A detector with a loose threshold fires on every routine patch note. Most Radar problems are one of those two.

The vocabulary

Term	What it is	Where you see it
Source	Your subscription to one feed, API, page or portfolio. Most sources come from the shared library. A source you add by URL is yours alone.	Configuration → Radar → Sources
Detector	A rule for what deserves an alert: plain-language guidance, a severity threshold, category and source filters, and the vendors it applies to.	Configuration → Radar → Detectors
Signal	One event, as it affects your organization. One signal per event, however many detectors fire.	Radar → Signals
Alert	One detector’s verdict that an event matters for one of your vendors, with severity, confidence and reasoning. Alerts sit under the signal on its Detectors tab.	The signal page
Case	An investigation you open from a signal, with one thread per vendor and vendor outreach.	Radar → Cases
Finding	A confirmed problem on a vendor, created from a signal.	Findings, and the vendor page
Reassessment	A draft batch of assessments raised from a signal or a trigger, run once you confirm the vendors.	Radar → Reassessments

The chain is: a source pulls an item, Radar folds the item into an event, the event touches one of your vendors and becomes a signal, each enabled detector that targets that vendor reads the event and either alerts or stays quiet, and an alert at or above the detector’s severity threshold puts the signal In alert. An Informational alert never does.

Where things live

Radar in the left navigation opens the Portfolio risk chart (once there are signals to plot) and three tabs: Signals, Cases and Reassessments. At the right of the tab bar, the Configurations menu links to the three tabs of Configuration → Radar: Detectors, Sources and Reassessments (the reassessment triggers). Beside it, New detector offers From detector library and Create custom detector, and under Also add, Source from library and Log a signal manually. Every vendor page also has a Radar tab. It lists Detectors monitoring this vendor and the vendor’s Recent alerts, with an Edit detector link on each detector.

The signal queue

Open Radar → Signals.

Radar Signals tab listing signals with severity, status, vendors and detectors — The Signals tab. One row per event, grouped by when it was first seen, with the highest severity any detector assigned and the vendors exposed.

Three built-in views sit in the view selector. All Signals is the default and shows everything, newest first. In Alert shows only signals with an active alert, most recently alerted first. This is the queue. Triaged shows signals someone has already acted on. Search signal titles and summaries, add filters, change sorting and columns under Display, and save the arrangement with New view.

Column	What it shows
Severity	The highest severity any detector assigned to this event.
Signal	The title Radar wrote for your organization.
Status	Where the signal stands. See the table below.
Vendors	Your vendors linked to the event.
Detector	The detectors that fired.
Last alerted	When the most recent alert attached.
Risk domains	The domains the firing detectors map to.
First seen	When Radar first saw the event.
Nth Parties, Nth Party Tags	The companies your vendors depend on that the event names, and their tags. Hidden by default; turn them on under Display.

Rows group by Today, Yesterday, This week, Last week and Older. The icon button beside Display collapses or expands every group. The Actions menu offers Download as Excel: the Export Signals dialog exports every signal in the view with the table’s visible columns, and lets you also include the summary, notes and detector results. To record an event by hand, choose New detector → Log a signal manually. Give it a Title and Summary, and optionally the Impact area, When it occurred, Risk domains, a Source URL and Source name, and the Affected vendors. Create signal opens the new signal, and the detectors evaluate it like any other event.

Signal statuses

Status	Meaning
Tracked	A vendor you depend on is linked to the event, but no detector has alerted. Radar shows the exposure and waits.
Open	No detector is alerting, but someone handled the signal by hand: created it, edited it, or restored it after a dismissal.
In alert	At least one detector fired at or above its threshold and the alert is still active.
Triaged	Someone acknowledged the signal, opened a case, created a finding, or started a reassessment.
Dismissed	Every alert on the signal was dismissed, or the signal was dismissed before any alert existed.
Closed	A terminal status. Nothing moves a signal here on its own; set it from the status card on the signal page.

Your organization can add statuses of its own between these under Statuses, where the target type is Radar Signal.

Acting on several signals at once

Tick rows and a bar appears with Start reassessment, Acknowledge, Dismiss (or Restore (un-dismiss) for dismissed rows), Should have alerted and Clear. Should have alerted is for a Tracked signal a detector missed: pick the detector, and the signal is added to it as a positive example so events like it alert next time.

Reading a signal

Click a row. The page opens with the title (click it to edit), the severity badge, a Vulnerability badge when the event is a CVE, and the Actions menu.

Radar signal page showing the status card, vendors card, summary and Detectors tab — A signal. Status and exposed vendors on the left, the generated summary and time to signal on the right, and the detectors that fired below.

The left column holds:

The status card, named after the current status. Anyone with update permission on alerts can set a different status here.
Triage actions, once any exist: Marked as acknowledged, and the cases, findings and reassessments raised from this signal, each linking to its record.
Vendors: how many of your vendors were exposed, with View full exposure opening the Exposure tab.
Vulnerabilities, on a CVE event: Potential impact (CVSS v3.1), Likelihood of exploitation (EPSS) and Known exploited (KEV). A blank EPSS is common; a blank KEV means no source reported either way.

The main column holds:

Summary, with the Risk type chips. Click the pencil to rewrite it by hand. Regenerate summary rewrites it from what the detectors currently report and discards any hand edit. Custom AI instructions on this card apply to every generated summary in your organization.
Ask Coverbase AI, which can see the event, the exposed vendors, this signal’s triage, and other alerts from the past year.
Time to signal: Event occurred, First public disclosure and Coverbase alert sent, with the gaps between them.

Below those, six tabs:

Tab	What it holds
Detectors	One card per alert: the detector, the vendor, severity, confidence, when it alerted, its reasoning, and the sources it cited. Group by Detector, Severity or Vendor. Each card has its own New finding, Acknowledge and Dismiss actions, and a Rate this result pair of thumbs that adds the event to the detector as a positive or negative example.
Exposure	Every vendor the event touches, with Tier, Inherent risk, Residual risk, Triage (what has been done for that vendor) and Exposure (Direct or Nth Party). Switch between Your vendors and All related entities, and between the Table and the Flow view. Add vendor links a vendor Radar missed.
Sources	The articles, API records and snapshots behind the event, each with Published and Fetched times.
Timeline	Everything in order: sources linked, detections, dismissals, triage.
Notes	Notes on the signal.
Activity	The audit trail, including system entries.

An Nth Party exposure means one of your vendors depends on a company the event names. Those relationships come from SOC 2 reports and subprocessor lists, so one event can implicate vendors nobody mentioned. A vendor whose uploaded SBOM lists an affected component shows as Direct, with the matched components in a Source column; see Bills of materials.

Triaging a signal

Open the Actions menu on the signal page. What it offers depends on where the signal stands.

Action	What it does	Status afterwards
Open case	Starts an investigation with one thread per affected vendor. Shown only while the signal has no open case.	Triaged
Bulk create findings	One finding per vendor you tick, prefilled from the alert.	Triaged
Start reassessment	Drafts a reassessment for the exposed vendors, with an optional assessment plan.	Triaged
Acknowledge	Records that you saw it and no case or finding is needed.	Triaged
Dismiss	Closes the alerts as not needing action, with an optional reason.	Dismissed
Restore (un-dismiss)	Brings a dismissed signal back.	In alert

Bulk create findings and Start reassessment are disabled when the signal has no exposed vendors. Acknowledge disappears once the signal is Triaged or Dismissed.

Dismissing

Dismiss signal dialog with a reason field, the alerted detectors, and the signal's alerts all selected — The dismiss dialog. Every active alert is ticked by default; the signal is dismissed only when all of them are.

The dialog names the Alerted Detectors with how many alerts each raised, then lists the signal with a count such as 22 of 22 alerts. Every active alert is ticked. Expand the signal (or Expand all) and untick the alerts you want to keep, and the button changes from Dismiss signal to Dismiss N alerts; the signal itself is dismissed only when every alert is. Type a Reason (optional) if you want one on the record. Mention a colleague in it and they get a Dismissal mentions notification. Each dismissed alert also becomes a negative example on the detector that raised it, with your reason attached, so events like it stay quiet next time. That happens only when you can edit detectors; a dismissal by someone who cannot closes the alerts and teaches nothing. Restore (un-dismiss) takes the example back out. Dismissing is the main way a detector learns; the others are the thumbs on each alert and the detector’s own Test detector run, below.

Opening a case

Create a Case asks for a Title (prefilled with the signal title), a Description (prefilled with its summary), and the Affected Vendors. Include all affected vendors is on by default. Create and Continue takes you to Send Emails, where a Shared Draft Template with placeholders for the vendor name and your organization name can be applied to every pending vendor, edited per vendor, and sent one at a time or with Send all remaining. Skip and Go to Case leaves the emails for later. The case page has Overview, Vendors, Notes and Activity tabs, with Send Emails, Add Vendors and Finalize Case at the top and Export as Excel, Import Vendors and Archive Case in the menu beside them. Each vendor thread carries a status, an assignee, a due date and the vendor’s replies. Finalize Case asks how the case was resolved: Resolved, Won’t fix or False positive. The first two raise the affected vendors’ residual risk when the detectors that fired are set to update risk; False positive moves no risk. While vendor threads are still open, the same dialog offers Close case and threads or Close case only to leave them as they are. Reopen Case undoes a close and clears the resolution. Archive Case is final.

Starting a reassessment

Start a reassessment lists the exposed vendors. Remove any you do not want, Add vendor… for one Radar missed, optionally pick an Assessment Plan, and click Start a reassessment. The draft opens on its own page and is listed under Radar → Reassessments. Check the vendors and the plan there, then Run reassessment, which creates one assessment per vendor from the plan. Dismiss closes the draft without running it. Reassessments can also be raised without a person, by the triggers under Configuration → Radar → Reassessments: each trigger names a plan, a vendor scope, and either risk-score conditions or an AI event-type instruction describing the kind of signal that should trigger it.

The risk review

When a firing detector has Residual risk impact switched on, acknowledging, creating a finding, starting a reassessment, or finalizing a case raises the affected vendors’ residual risk. Review vendor risk profile updates opens with the new scores, overall and per domain. Adjust any of them and Save and continue, or Continue to accept. Dismissing never moves risk. How the size of the move is chosen is on the Supplier Radar page.

Sources

Open Configuration → Radar → Sources.

The table shows Name, Type (Article feed, RSS feed, API, Snapshot, Black Kite and so on), Date Added, Last Fetched (Never until the first successful run) and Status. Search by name or filter the list. The row menu has Archive, which stops collection and cannot be undone. Archived sources keep the items they already collected. Add source offers three routes:

From Source Library: tick sources in the curated catalog, narrowed by segment or search (Add all visible ticks everything in view), then Connect. A source Coverbase has withdrawn is greyed out as Unavailable, with the reason. The full list is on the source library page. Library sources are shared and run on a schedule Coverbase sets; you can rename one but not change how it fetches.
Black Kite portfolio: covered in the Black Kite monitoring guide.
New Custom Source: your own Article Feed (a news page or RSS feed), API (a JSON endpoint with a request configuration and a response mapping), or Snapshot (a page or a JSON list watched for changes, with a Fetch Schedule of Hourly, Every 4 hours, Daily or Weekly).

Source status	What it means
New	Not saved yet.
Pending	Saved, and Radar is still building the extractor that reads the page. RSS feeds skip this and go straight to Active.
Active	Collecting.
Unsupported	Radar could not build an extractor for this page. It will not be monitored.
Setup incomplete	Extractor generation was abandoned. Reopen the source and finish it.
Paused	Collection has stopped for this feed, usually because Coverbase withdrew a library source whose page no longer exists or refuses automated requests. Items already collected stay.

A custom Article Feed without an RSS feed needs a generated extractor. The source page shows sample extracted items for you to Accept or Reject, and stays quiet until one is accepted.

A source’s items and runs

Click a source. Besides Configure, it has an Articles tab (Snapshot on a snapshot source) and a Runs tab.

Source Runs tab listing fetch runs with status, duration and item counts — A source's runs. Each row is one fetch, with how many items it fetched, summarized and extracted entities from, and how many detections it produced.

Articles lists every item the source collected, with its Categories and Date Ingested. Click one to read it and see which detectors evaluated it. Runs lists each fetch with Status, Date Started, Duration, Fetched, Summarized, Entities, Detections and Errors. Click a run for its log. A source that runs successfully with zero Fetched for days is usually a feed that has stopped publishing, or a page that started blocking automated access.

Detectors

Open Configuration → Radar → Detectors.

New organizations start with a recommended set already enabled, announced by a banner on the Radar page and a Suggested actions checklist here: review the recommended detectors, customize the vendor scope, assign default reviewers, disable what is not relevant, add more. Mark as complete hides the checklist. The table shows Title, Categories and Reviewers. When any detector is disabled, Enabled and Disabled tabs appear with counts. The row menu has Enable or Disable and Archive. Tick several rows for Assign reviewer, Disable and Archive in bulk. Archiving cannot be undone; disabling can.

Adding one

Add detector (or New detector on the Radar page) offers From detector library and Create custom detector.

Detector library dialog with segment chips, a list of templates and a preview showing guidance and sources — The detector library. Templates by segment; the preview shows a template's guidance and the sources it brings with it.

The library filters templates by All, Recommended and segment (Cybersecurity, Financial, Operational, Legal, Compliance, Reputational, Contractual, ESG, Corporate, Geopolitical & External, AI Risk). Click a template to preview its Guidance, the Sources it deploys with, and an Example. Add detector adds it with its recommended settings; Configure adds it and opens it for editing. On a template you already have, the button reads Enable detector or Disable detector. Tick several and Enable them at once. Every template is listed with its default severity on the detector library page. Enabling a template adds its sources to your organization, where you do not already have them, and scopes the new detector to them, so it starts working without further setup. A source marked Unavailable has been withdrawn and is skipped. A template becomes an ordinary detector on your organization, so everything below applies to it, including changing its sources.

The detector form

Detector editor showing vendor targeting, severity threshold, guidance and risk impact — Editing a detector. Targeting and sources on the left, threshold, guidance, risk impact and examples on the right.

Field	What it does
Name, Description	How the detector appears in lists, on alerts and in notification emails.
Sources	Restrict the detector to specific sources. Empty means every source. A detector added from the library starts limited to the sources it deployed with, so a source you add later is not read by it until you add it here. A detector limited to sources sees events you record by hand only if it includes Manually-created events.
Vendor targeting	Apply to all vendors, or tag conditions: a vendor matches a condition when it has all of that condition’s tags, and conditions are combined with OR. Include specific vendors adds named vendors. Exclude vendors always wins.
Categories	Restrict to impact types (Infosec, Financial, Operational, Legal, Compliance, Reputational, Contractual, ESG, Corporate, Geopolitical & External). Empty means all.
Severity Threshold	No threshold, Informational, Low, Medium or High. An alert is raised when the detected severity meets or exceeds it.
Guidance	Plain-language instructions on what to flag and how severe it is. AI autofill drafts it from the name and description. Either guidance or a threshold is required.
Residual risk impact	Off by default. When on, acting on one of this detector’s alerts raises the vendor’s residual risk by a value between Min impact and Max impact (0 to 100), on the overall score when Affect overall residual risk is on, and on the mapped Risk domains.
Positive examples, Negative examples	Events the detector should and should not alert on. Dismissals and thumbs ratings land here. Remove an example to make the detector reconsider.
Default Reviewers	Users and user groups notified of every alert. Send test alert sends one notification to them, once the detector is saved with at least one reviewer.
Detector enabled	Off keeps the settings but stops evaluation.

Three other detector kinds share the list. A Watchlist detector matches vendors deterministically against connected sanctions and watchlist sources, every 4 hours, and has no guidance, threshold or examples; it needs a watchlist source connected first. A Black Kite detector reads your Black Kite portfolio against thresholds, and is covered in its own guide. An Enforcement register hits detector re-reads the watched vendors’ licence and enforcement registers, OFAC civil penalties and the federal banking regulators included, and signals each enforcement record once per vendor; it needs no source, and is covered in the Bank enforcement checks guide.

Testing before you enable

Test detector on a saved detector re-runs it against your recent events over the Last 7 days, Last 30 days or Last 90 days. Each result reads Will alert or Will not alert. Mark results This should alert or This shouldn’t alert, then Refine with AI proposes a rewrite of the guidance, which you can edit before Apply & re-run. Tick results and Create alerts to turn them into real alerts; a result that already has a live alert is skipped.

Start narrow. Keep the threshold at Medium or High, target the vendors you would act on, and watch two weeks of alerts before loosening anything. Every dismissal makes the detector quieter, so the first weeks are also when it learns fastest.

Which vendors are watched

A vendor is evaluated by every enabled detector whose Vendor targeting includes it. That is the whole rule. The vendor page’s Radar tab lists the detectors that currently apply, so it is the quickest way to answer “is this vendor covered?”. A vendor with no detectors still gets Tracked signals when an event touches it, because tracking needs no detector. Vendors also carry a monitoring flag, which a workflow’s Enable vendor threat monitoring action turns on. That flag is what the vendors monitored by Radar count on your subscription uses, so it decides what monitoring costs, not what a detector watches. The same flag decides who dark web monitoring watches when it is set to follow Radar.

Notifications

Radar sends four notifications. Each person can switch them on or off in their notification settings: Radar detector alert and Reassessment trigger fired sit in the monitoring group, Case created with cases, and Dismissal mentions with mentions.

Notification	Who gets it	When
Radar detector alert	The detector’s default reviewers	A detector raises an alert. In-app it reads as the severity, the summary and the vendor, with a View alert button. The email subject is the severity, “radar alert”, the vendor and the summary; the body adds a line about the vendor, when the event was first found, the detector, and Why this was flagged. Alerts from one run within a minute of each other arrive as one email.
Reassessment trigger fired	The people named under Notify on the trigger	A reassessment trigger proposes a draft.
Case created	The default reviewers of the detectors that fired, plus each affected vendor’s relationship owners and risk analysts	A case is opened from a signal.
Dismissal mentions	The person mentioned	Someone mentions them in a dismissal reason.

A detector with no default reviewers raises alerts that nobody is told about. They still appear in In Alert. The full catalog is in the email notifications guide.

Where signals go next

Findings. A finding created from a signal carries the source type Radar alert, opens with the detector name and the alert summary as its title, and links back to the signal from the Triage actions card. From there it is an ordinary finding: see Findings Manager.
Vendor risk. With Residual risk impact on, triage moves the vendor’s residual score, and the vendor’s risk history records the change and the detector behind it.
Risk register. The register’s Signal Sources settings can attach Radar signals and Radar alerts at or above a severity threshold to risks, and a risk’s Attach signal button does it by hand. Turning a source off stops new attachments and leaves existing ones.
Workflows. A workflow can trigger on a Radar signal, condition on its fields, and update it. The Monitoring signal triage template opens a review and a dated task for every new signal.
Dashboards. The Portfolio risk chart on the Radar page plots signals over time by severity, with a 3M, 6M, 12M or All range and vendor and tag filters; click a point for the affected vendors.
API, MCP and webhooks. Events, alerts, signals, cases, sources and detectors are readable and editable over the Radar API and through MCP (see Work Radar from MCP or the API). RadarEvent.* and RadarDetectorResult.* webhooks fire as they change.

Who can do what

Role (default)	Signals and alerts	Detectors and sources
Admin	Everything	Create, edit, test, enable, archive
Member	Read, triage (acknowledge, dismiss, restore, set status, edit title and summary)	Read only
Siloed member	Read	Read only

Radar is org-wide: a siloed member sees every signal, not only their vendors’ signals. Creating a case, a finding or a reassessment from a signal also needs the permission for that record. Custom roles can change any of this; see Permissions and roles.

Work Radar from MCP or the API

You can manage sources and detectors and work the signal queue from an MCP client or with an API key, as well as in the dashboard. An MCP client reads with query_radar(kind=...) and changes things with mutate(entity=..., action=..., data={...}). The API routes sit under /v1/radar and take an ak_ API key. Each call checks the same permission as the matching dashboard action. Before an MCP client sends a write, it shows you the change and waits for you to confirm it. The write itself carries confirm: true inside data. See Roles and permissions. An API key cannot archive or restore a source or a detector, delete a detector example, or archive a case or a case thread. A signed-in user does those in the dashboard or through MCP.

Sources

Task	MCP call	API route
List your sources	`query_radar(kind="sources")`	`GET /v1/radar/sources`
Read one source	`query_radar(kind="source_detail")`	`GET /v1/radar/sources/{source_id}`
Browse the source library	`query_radar(kind="source_library")`, `kind="source_library_detail"`	`GET /v1/radar/source-library`, `GET /v1/radar/source-library/{library_id}`
List the origins Radar pulls	`query_radar(kind="origins")`	`GET /v1/radar/origins`
Add a source	`mutate(entity="radar_source", action="create")`	`POST /v1/radar/sources`
Rename a source or change its feed	`mutate(entity="radar_source", action="update")`	`PATCH /v1/radar/sources/{source_id}`
Archive or restore a source	`mutate(entity="radar_source", action="archive")`	Not available with an API key
Pull a source on the next scheduler run	`mutate(entity="radar_source", action="pull")`	`POST /v1/radar/sources/{source_id}/pull`
Read or configure the Black Kite monitor	`query_radar(kind="black_kite_config")`, `mutate(entity="black_kite", action="configure")`	`GET` and `PUT /v1/radar/black-kite`
Read what a snapshot source captured and what changed	`query_radar(kind="source_snapshot")`	`GET /v1/radar/sources/{source_id}/snapshot`
Review or accept a generated extractor	`query_radar(kind="source_extractor_run")`, `mutate(entity="radar_source", action="accept_extractor")`	`GET` and `POST /v1/radar/sources/{source_id}/extractor/accept`
Test an API source	Not available through MCP	`POST /v1/radar/sources/{source_id}/test`
Read the raw items Radar pulled	`query_radar(kind="radar_data")`, `kind="radar_data_detail"`, `kind="radar_data_content"`	`GET /v1/radar/data`
Read pull runs and their logs	`query_radar(kind="runs")`, `kind="run_detail"`	`GET /v1/radar/runs`

Adding, editing and archiving a source need radar_detector:update:org. Pulling a source needs radar_detector:run:org.

Detectors

Task	MCP call	API route
List your detectors	`query_radar(kind="detectors")`	`GET /v1/radar/detectors`
Read one detector’s configuration	`query_radar(kind="detector_detail")`	`GET /v1/radar/detectors/{detector_id}`
See which detectors watch a vendor	`query_radar(kind="detectors_for_vendor")`	`GET /v1/radar/vendors/{vendor_id}/detectors`
Create a detector	`mutate(entity="radar_detector", action="create")`	`POST /v1/radar/detectors`
Edit a detector	`mutate(entity="radar_detector", action="update")`	`PATCH /v1/radar/detectors/{detector_id}`
Back-test a detector over past events	`mutate(entity="radar_detector", action="test")`	`POST /v1/radar/detectors/{detector_id}/tests`
Read a back-test’s candidate alerts	`query_radar(kind="detector_test_run")`	`GET /v1/radar/detectors/{detector_id}/tests/{test_run_id}`
Turn back-test candidates into real alerts	`mutate(entity="radar_detector", action="create_alerts_from_test")`	`POST /v1/radar/detectors/{detector_id}/tests/{test_run_id}/alerts`
Label back-test candidates so the detector learns	`mutate(entity="radar_detector", action="teach")`	`POST /v1/radar/detectors/{detector_id}/tests/{test_run_id}/teach`
List a detector’s learning examples	`query_radar(kind="dismissal_examples")`	`GET /v1/radar/detectors/{detector_id}/dismissal-examples`
Add, edit or remove a learning example	`mutate(entity="radar_dismissal_example", action="create")`, `action="update"`, `action="delete"`	`POST /v1/radar/detectors/{detector_id}/dismissal-examples`, `PATCH` and `DELETE /v1/radar/dismissal-examples/{example_id}`
Get a suggested rewrite of a detector’s instructions	`query_radar(kind="suggest_detector_instructions")`	`POST /v1/radar/detectors/{detector_id}/suggest-instructions`
Run a detector on one event	`mutate(entity="radar_event", action="run_detector")`	`POST /v1/radar/events/{event_id}/detector-runs`

A suggested rewrite saves nothing. To use it, send it as a detector update.

Alerts

Task	MCP call	API route
List alerts, one row per detector result	`query_radar(kind="detector_alerts")`	`GET /v1/radar/alerts`
Read one alert	`query_radar(kind="detector_alert_detail")`	`GET /v1/radar/alerts/{alert_id}`
Dismiss alerts	`mutate(entity="radar_alert", action="dismiss")`	`POST /v1/radar/alerts/{alert_id}/dismiss`
Restore a dismissed alert	`mutate(entity="radar_alert", action="undismiss")`	`POST /v1/radar/alerts/{alert_id}/undismiss`
Edit an alert’s summary, reasoning or confidence	`mutate(entity="radar_alert", action="update")`	`PATCH /v1/radar/alerts/{alert_id}`
Replace or clear a dismissal reason	`mutate(entity="radar_alert", action="set_dismiss_reason")`	`PUT /v1/radar/alerts/{alert_id}/dismiss-reason`
Write an alert by hand	`mutate(entity="radar_alert", action="create")`	`POST /v1/radar/alerts`

Through MCP, one dismiss call takes several alerts in alert_ids. Each person mentioned in the reason gets a notification.

Signals

Task	MCP call	API route
List signals	`query_radar(kind="signals")`	`GET /v1/radar/signals`
Read one signal with its alerts	`query_radar(kind="signal_detail")`	`GET /v1/radar/signals/{signal_id}`
Move a signal to another status	`mutate(entity="radar_signal", action="set_status")`	`PATCH /v1/radar/signals/{signal_id}`
Dismiss signals and their alerts	`mutate(entity="radar_signal", action="dismiss")`	`POST /v1/radar/signals/dismiss`
Restore dismissed signals	`mutate(entity="radar_signal", action="undismiss")`	`POST /v1/radar/signals/undismiss`
Acknowledge a signal	`mutate(entity="radar_signal", action="acknowledge")`	`POST /v1/radar/signals/{signal_id}/acknowledge`
Accept, skip or replace the proposed risk impact	`mutate(entity="radar_signal", action="decide_risk_impact")`	`POST /v1/radar/signals/risk-impact-decision`
Rewrite a signal’s title and summary from its alerts	`mutate(entity="radar_signal", action="regenerate_summary")`	`POST /v1/radar/signals/{signal_id}/regenerate-summary`
Rename an event or link more vendors to it	`mutate(entity="radar_event", action="update")`	`PATCH /v1/radar/events/{event_id}`
Read an event’s updates	`query_radar(kind="event_updates")`	`GET /v1/radar/events/{event_id}/updates`
Find out why an event did not reach you	`query_radar(kind="event_diagnostics")`	`GET /v1/radar/events/{event_id}/diagnostics`
List events, or count them by when they happened	`query_radar(kind="events")`, `kind="event_detail"`	`GET /v1/radar/events`
Read an event’s data items, time to signal or exposed vendors	`query_radar(kind="event_data_items")`, `kind="event_time_to_signal"`, `kind="event_exposure_vendors"`	`GET /v1/radar/events/{event_id}/data-items`
List the alerts a signal acts on	`query_radar(kind="signal_alerts")`	`GET /v1/radar/signals/{signal_id}/alerts`
Read a vendor’s Radar stories	`query_radar(kind="vendor_stories")`, `kind="vendor_story"`	`GET /v1/radar/vendors/{vendor_id}/stories`

Acknowledging a signal proposes a residual-risk change for the affected vendors. The change waits until you decide it with decide_risk_impact. Rewriting a summary replaces any title or summary your organization edited by hand.

Cases and case threads

Task	MCP call	API route
List cases	`query_radar(kind="cases")`	`GET /v1/radar/cases`
Read one case	`query_radar(kind="case_detail")`	`GET /v1/radar/cases/{case_id}`
Open a case	`mutate(entity="case", action="create")`	`POST /v1/radar/cases`
Draft a case description from its signals	`query_radar(kind="case_description_suggestion")`	`POST /v1/radar/cases/{case_id}/description-suggestion`
Rename, describe, assign, close or reopen a case	`mutate(entity="case", action="update")`	`PATCH /v1/radar/cases/{case_id}`
Archive a case	`mutate(entity="case", action="archive")`	Not available with an API key
Link signals to a case	`mutate(entity="case", action="add_signals")`	`POST /v1/radar/cases/{case_id}/signals`
Unlink a signal from a case	`mutate(entity="case", action="remove_signal")`	`DELETE /v1/radar/cases/{case_id}/signals/{signal_id}`
List a case’s vendor threads	`query_radar(kind="case_detail")`	`GET /v1/radar/cases/{case_id}/threads`
Read one vendor thread	`query_radar(kind="case_thread")`	`GET /v1/radar/cases/{case_id}/threads/{thread_id}`
Add one vendor to a case	`mutate(entity="case_thread", action="create")`	`POST /v1/radar/cases/{case_id}/threads`
Add up to 200 vendors to a case	`mutate(entity="case_thread", action="bulk_create")`	`POST /v1/radar/cases/{case_id}/threads/bulk`
Change a thread’s status, owner or due date	`mutate(entity="case_thread", action="update")`	`PATCH /v1/radar/cases/{case_id}/threads/{thread_id}`
Stop a thread’s automatic follow-up emails	`mutate(entity="case_thread", action="pause_follow_ups")`	`POST /v1/radar/cases/{case_id}/threads/{thread_id}/pause-follow-ups`
Fill threads that have no contacts	`mutate(entity="case_thread", action="source_contacts")`, `query_radar(kind="case_contact_search")`	`POST /v1/radar/cases/{case_id}/threads/source-contacts`
Email the vendor on a thread	`mutate(entity="case_thread", action="send_email")`	`POST /v1/radar/cases/{case_id}/threads/{thread_id}/emails`
Export a case	Not available through MCP	`GET /v1/radar/cases/{case_id}/export`

Closing a case as resolved or wont_fix raises the residual risk of the case’s vendors, as Finalize Case does. Adding a vendor to a case notifies the vendor’s owners and analysts, and nothing reaches the vendor. Marking a thread email_sent records that you emailed the vendor and sends nothing. Three case tasks stay in the dashboard: emailing a vendor from a thread, importing vendors from a spreadsheet, and sourcing missing contacts. Triage writes need radar_alert:update:org. Through MCP, dismissing alerts or signals and archiving a case or a thread also need radar_alert:archive:org. The API dismiss routes need only radar_alert:update:org, which API keys hold.

Troubleshooting

What you see	What is happening
A source runs and Fetched climbs, but no signals appear.	No enabled detector targets the vendors in those items, or the detector’s threshold is above what it is finding. Check the vendor page’s Radar tab, then the detector’s Severity Threshold.
A signal is Tracked and nothing happens.	That is the design. A related vendor is linked and no detector has alerted. Use Should have alerted to teach a detector, or act on it directly from Actions.
A dismissed signal is not under Triaged.	Triaged holds signals with a triage action. Open All Signals and filter Status to Dismissed, or Restore (un-dismiss) it.
Reviewers got no email for an alert.	The detector has no Default Reviewers, the reviewer switched Radar detector alert off in their settings, or the alert is Informational and did not put the signal in alert.
Acknowledge is missing from the menu.	The signal is already Triaged or Dismissed.
Bulk create findings is grayed out.	The signal has no exposed vendors. Add one on the Exposure tab first.
Send test alert is disabled.	Save the detector first, and add at least one default reviewer.
A detector alerted on the same event twice.	It fired for two different vendors. Each alert is one detector on one vendor, and both sit under the same signal.
A library source cannot be edited.	Library sources are shared. You can rename them; for different settings, create a custom source.
A detector from the library ignores a source you added later.	It is scoped to the sources it deployed with. Add the new source under the detector’s Sources.
A dismissal did not stop similar alerts.	The person who dismissed it cannot edit detectors, so nothing was taught. Ask an admin to add the event as a negative example on the detector.

Supplier Radar

What the product does, the signal lifecycle, and how triage moves residual risk.

Black Kite monitoring guide

Connecting a Black Kite portfolio as a source and alerting on its findings.

Detector library

Every template with its default severity and what it flags.

Workflow templates

Enrolling vendors in monitoring and routing new signals into reviews and tasks.

Dark web monitoring guide

Leak sites, breach catalogs, infostealer logs and lookalike domains for your organization and your vendors.

​The vocabulary

​Where things live

​The signal queue

​Signal statuses

​Acting on several signals at once

​Reading a signal

​Triaging a signal

​Dismissing

​Opening a case

​Starting a reassessment

​The risk review

​Sources

​A source’s items and runs

​Detectors

​Adding one

​The detector form

​Testing before you enable

​Which vendors are watched

​Notifications

​Where signals go next

​Who can do what

​Work Radar from MCP or the API

​Sources

​Detectors

​Alerts

​Signals

​Cases and case threads

​Troubleshooting

​Related

Supplier Radar

Black Kite monitoring guide

Detector library

Workflow templates

Dark web monitoring guide

The vocabulary

Where things live

The signal queue

Signal statuses

Acting on several signals at once

Reading a signal

Triaging a signal

Dismissing

Opening a case

Starting a reassessment

The risk review

Sources

A source’s items and runs

Detectors

Adding one

The detector form

Testing before you enable

Which vendors are watched

Notifications

Where signals go next

Who can do what

Work Radar from MCP or the API

Sources

Detectors

Alerts

Signals

Cases and case threads

Troubleshooting

Related