---
name: ioc-bulk-submission
description: >
  Take a validated list of malicious indicators and submit them to the organization's threat
  intel platforms in one pass, closing the loop between enrichment and dissemination. Use this
  skill whenever a user asks to "submit these IOCs", "push these to MISP/OpenCTI/ThreatStream",
  "add these to our TI platform", or has just finished a triage that concluded MALICIOUS/
  SUSPICIOUS and wants the confirmed indicators shared. Do not use this to submit anything that
  hasn't been triaged or explicitly confirmed malicious by the user — always confirm the final
  list and destination before submitting, since this writes to shared, external-facing platforms.
---

# IOC Bulk Submission Skill

Closes the loop that most enrichment workflows leave open: once indicators are confirmed
malicious, get them into the shared threat intel platform without a separate manual step per IOC.

---

## Workflow Overview

```
1. Confirm the validated list  →  2. Confirm destination(s)  →  3. Confirm exact submission
   →  4. Submit in batch  →  5. Report results
```

---

## Step 1 — Confirm the Validated List

This skill submits; it does not decide what's malicious. Only proceed with indicators that were
either:
- Already scored MALICIOUS/SUSPICIOUS in a prior triage this session, or
- Explicitly confirmed by the user as "these are the ones to submit"

If the user pastes a raw list with no prior triage context, ask them to confirm each is intended
for submission rather than assuming a pasted IOC is automatically meant to be shared.

---

## Step 2 — Confirm Destination(s)

Available submission integrations (check `polarity:list_available_integrations` for the current
set, since these change):

| Platform | Integration ID | Notes |
|---|---|---|
| OpenCTI | `opencti_ioc_submission_3_0_0_node_18_1755520815956` | Observables and Indicators |
| Anomali ThreatStream | `threatstream_ioc_submission_3_2_4_node_18_d56e56d002_1697657235` | |
| Dataminr TIP (ThreatConnect) | `threatconnect_ioc_submission_3_2_6_node_18_1746201485` | |

Ask which platform(s) if the user hasn't said, or default to whichever the organization uses as
system of record if that's established earlier in the conversation. Never guess a destination
silently for a write action.

---

## Step 3 — Confirm Exact Submission (required — this is a write action)

Before calling any submission integration, show the user the exact payload:

> "Ready to submit N indicators to [platform]: [list them, typed — IP/domain/hash/URL]. This
> writes to a shared platform other analysts and possibly partners can see. Confirm?"

Do not submit until the user gives a clear yes. This is non-negotiable — bulk submission to a
shared threat intel platform is a write action with downstream visibility to other teams, and a
wrong or premature submission (e.g. a false positive marked malicious) pollutes shared data that's
hard to fully retract.

---

## Step 4 — Submit in Batch

Once confirmed, call `polarity:do_integration_lookup` with the relevant submission integration ID
for each indicator (or batched query if the integration supports multiple entities per call).
Submit sequentially and track per-indicator success/failure — don't treat a partial batch failure
as an all-or-nothing result.

---

## Step 5 — Report Results

Plain summary, not a rendered widget (this is a confirmation, not an investigation report):

- Which indicators submitted successfully, to which platform(s)
- Which failed, and why if the error message indicates a reason (duplicate, malformed, auth)
- A suggestion to retry failures individually if the cause looks transient

---

## Handling Edge Cases

**Indicator already exists on the destination platform**: Report as "already present" rather
than a failure — this is expected and not an error state.

**User wants to submit to multiple platforms at once**: Confirm the full destination list once
upfront (Step 2/3), then run all submissions, rather than re-confirming per platform.

**Large batch (>25 indicators)**: Confirm the count and destination once, then proceed — don't
ask for per-indicator confirmation, which defeats the purpose of a bulk tool. The one batch-level
confirmation in Step 3 is the gate, not N individual ones.

**Submission integration not available in this environment**: Say so plainly and suggest the
user's SOAR/TI platform admin check the Polarity integration configuration — don't attempt a
workaround like emailing the list, since that changes the audit trail the user presumably wants.

**User asks to also remove/retract a previously submitted IOC**: Most Polarity submission
integrations are add-only from this interface. Tell the user this needs to be done directly in
the destination platform's UI, and don't attempt to fake a retraction via a "correction" submission
without flagging that it may not actually remove the original entry.