Blackpoint Incident Response

Blackpoint Incident Response

The functional Blackpoint tool surface today is read-only and centers on detections and the assets they fire against. This skill walks the investigation flow: tenant → asset → detections → vulnerabilities, plus dark-web and external-vulnerability cross-references.

Anti-triggers

• Responding, acknowledging, isolating, or closing — despite the skill name there is no incident object and no write tool here. The MCP surface cannot mutate CompassOne state; response happens in the portal. If the intent is an actionable incident lifecycle, the operator is probably thinking of huntress-incidents or sentinelone-alerts.
• blackpoint_alerts_* and blackpoint_tickets_* — those domains are stubs, not an alternative alerting surface. Detections are the only detection object Blackpoint exposes.
• Exposure work in its own right — CVE filtering, scan history, dark-web, and external exposure have their own skill: blackpoint-vulnerability-management. Use this one only when a detection is the starting point.
• Sweeping every customer rather than investigating one — use blackpoint-multi-tenant-operations.

API Tools

Tenants

Assets

Detections

Vulnerabilities

Common Workflows

Walk a detection end-to-end

1. Identify the tenant: blackpoint_tenants_list → blackpoint_tenants_get.
2. List recent detections: blackpoint_detections_list.
3. Pick the detection of interest: blackpoint_detections_get.
4. Pivot to the affected asset: blackpoint_assets_get and blackpoint_assets_relationships.
5. Cross-reference vulnerabilities on that asset: blackpoint_vulnerabilities_list.

Per-tenant exposure rollup

1. blackpoint_tenants_get to confirm scope.
2. blackpoint_vulnerabilities_external_list for internet-facing exposure.
3. blackpoint_vulnerabilities_darkweb_list for credential / data leakage.
4. blackpoint_vulnerabilities_scans_list for recent scan history.
5. Roll up: count by severity, age, and asset. Surface anything high-severity with no recent scan.

Asset relationship map

1. blackpoint_assets_search to find the entry asset.
2. blackpoint_assets_relationships to enumerate connected assets.
3. For each related asset, summarize detections and vulnerabilities to build a blast-radius view.

Multi-tenant detection sweep (partner view)

1. blackpoint_tenants_list to enumerate customers.
2. For each tenant, call blackpoint_detections_list for a recent window.
3. Roll up: detections per tenant, severity distribution, top detection types.
4. Surface tenants with abnormal volume or new detection types as priority follow-ups.

Edge Cases

• Stub domains — blackpoint_alerts_*, blackpoint_cloud_security_*, blackpoint_notifications_*, blackpoint_partners_*, blackpoint_threat_intel_*, and blackpoint_tickets_* are placeholders today and should not be invoked. Prefer the four functional domains.
• Read-only — Any "respond" or "acknowledge" action must happen in the CompassOne portal; the MCP surface cannot mutate state yet.
• Asset identity drift — Re-imaged endpoints can produce two asset records. Use blackpoint_assets_search and dedupe on hostname / serial before reporting.

Best Practices

• Always include tenant name in every output — partner-level work spans many customers and ambiguity bites.
• Pair detections with the associated asset and any related vulnerabilities in a single view; analysts should not have to chase the link themselves.
• For QBRs, pull the external-vulnerability list and dark-web list together — they tell complementary stories.

Related Skills

• api-patterns - Auth, hierarchy, pagination