Every vendor pitch these days claims their threat intelligence feed is "AI-powered." Most of the time that just means someone ran a clustering algorithm over a pile of indicators before dumping them into a TAXII server. That's fine, actually useful even, but it changes how you should plumb the feed into your SOC. AI-scored feeds carry confidence values, entity relationships, and decay timestamps that a traditional flat IOC list doesn't. If you ingest them the same way you'd ingest a static blocklist, you'll either drown your analysts in low-confidence noise or silently discard the exact signal you paid for.
I've done this integration three times now across different SOC stacks, and the pattern that works is always the same: treat the AI feed as a scored, decaying dataset rather than a binary blocklist, and build your correlation logic around that score instead of around raw presence/absence of an indicator. This runbook walks through exactly how to set that up, using a generic SIEM/SOAR pipeline running on infrastructure at sw-infrarunbook-01, with the feed vendor endpoint referenced as threatintel.solvethenetwork.com.
Prerequisites
Before you touch a config file, make sure the following are actually in place. I say this because on two of the three integrations I've run, half of these were assumed to be ready and weren't, which cost us a full day of troubleshooting that had nothing to do with the feed itself.
- A SIEM or log aggregation platform capable of accepting STIX 2.1 / TAXII 2.1 objects, or a normalization layer in front of it that can translate JSON feed output into your event schema.
- API credentials from your AI threat intel provider, scoped to a service account, not a personal login. You want this to survive someone leaving the team.
- Outbound HTTPS access from your ingestion host (sw-infrarunbook-01) to the provider's API endpoint, generally over 443, sometimes with a dedicated TAXII port depending on vendor.
- A SOAR platform or at minimum a scripting layer that can act on correlation matches — auto-tagging, ticket creation, or enrichment lookups.
- Internal network documentation so you can build allow/deny lists using RFC 1918 ranges for your own infrastructure, which matters when you're deduplicating internal IPs against external threat indicators.
- A decision, made ahead of time, on your minimum confidence threshold for auto-action versus analyst review. This is a policy decision, not a technical one, and it needs to happen before setup, not during.
That last point is the one teams skip. I've seen a SOC lead approve an integration, then get blindsided a week later when the SOAR platform auto-blocked a partner IP because nobody had agreed on what confidence score justified automated blocking versus a human-reviewed alert.
Step-by-Step Setup
Start with the connector, not the correlation rules. It's tempting to jump straight to writing detection logic because that's the interesting part, but if your ingestion pipeline is flaky, every downstream rule you build on top of it will be unreliable too.
Step 1: Provision the ingestion service account. Create a dedicated user on your SIEM host for the feed connector. I use infrarunbook-admin as the service account name convention across our runbooks, scoped with write access only to the threat intel index, nothing broader.
Step 2: Register the connector against the feed API. Most AI threat intel vendors expose a REST or TAXII 2.1 collection endpoint. You'll need to configure polling interval here — and this matters more than people think. AI-scored feeds often update confidence values on existing indicators as more signal comes in, not just add new ones. If you poll only for new objects and ignore modified timestamps, you'll be sitting on stale scores indefinitely.
Step 3: Build the normalization layer. Map the vendor's schema fields (confidence, ttl, actor_attribution, kill_chain_phase) into your SIEM's internal event fields. Don't skip the TTL/decay field — this is the single biggest difference between AI-scored feeds and legacy static lists. An indicator that was 95% confidence three months ago might be worth nothing today.
Step 4: Set your confidence threshold tiers. I generally use three tiers: auto-action (typically 90+), analyst-queue (60-89), and passive-logging (below 60, retained for retrospective hunting but not alerting). Tune these based on your own false-positive tolerance, not a vendor's recommended default.
Step 5: Wire correlation rules into your SIEM. This is where the feed actually starts doing work — matching incoming telemetry (DNS queries, proxy logs, EDR alerts) against the ingested indicators, weighted by confidence tier.
Step 6: Connect SOAR playbooks to the correlation output. Auto-action tier triggers immediate containment playbooks. Analyst-queue tier creates an enriched ticket with the AI-provided context (actor attribution, related indicators, MITRE ATT&CK mapping) attached so your analyst isn't starting from zero.
Full Configuration Example
Below is a representative connector and correlation configuration. Adjust field names for your specific SIEM/SOAR vendor, but the structure — polling, normalization, tiering, playbook binding — should translate directly.
# ti-feeds.yaml — AI threat intel feed connector config
# Host: sw-infrarunbook-01
connector:
name: ai-scoring-feed-primary
type: taxii2.1
endpoint: https://threatintel.solvethenetwork.com/taxii2/collections/ai-scored/
auth:
method: api_key
service_account: infrarunbook-admin
key_ref: /etc/soc/secrets/ti_api_key
polling:
interval_seconds: 300
fetch_modified_since_last_poll: true
include_revoked: false
normalization:
fields:
- source: confidence_score
target: event.threat.confidence
- source: ttl_hours
target: event.threat.decay_window
- source: actor_attribution
target: event.threat.actor
- source: kill_chain_phase
target: event.threat.attack_phase
- source: indicator_type
target: event.threat.ioc_type
confidence_tiers:
auto_action:
min_score: 90
action: soar_playbook.contain_and_isolate
analyst_queue:
min_score: 60
max_score: 89
action: soar_playbook.create_enriched_ticket
passive_logging:
max_score: 59
action: index_only
decay_policy:
reevaluate_on_ttl_expiry: true
expired_action: demote_to_passive_logging
hard_delete_after_days: 90
correlation_rule:
name: ai-feed-match-external-egress
match_fields:
- event.destination.ip
- event.dns.query
- event.http.host
exclude_internal_ranges:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
minimum_confidence: 60
output_index: soc-ti-matches
soar_playbook_bindings:
contain_and_isolate:
steps:
- isolate_endpoint
- block_indicator_at_firewall
- notify_channel: soc-critical-alerts
create_enriched_ticket:
steps:
- enrich_with_actor_context
- attach_mitre_mapping
- assign_queue: tier2-analyst
Note the exclude_internal_ranges block. This isn't optional. AI feeds occasionally score internal-looking artifacts as suspicious when correlated against telemetry that includes NAT'd or misattributed internal addresses. Excluding your own RFC 1918 space from the correlation match keeps you from generating tickets against your own infrastructure.
Verification Steps
Once the config is deployed, don't just assume it's working because the connector shows a green status. I check these four things every time, in this order.
1. Confirm the connector is actually pulling modified objects, not just new ones. Run a manual poll and check the timestamp of the most recently updated indicator against the vendor's dashboard. If your local copy is stale by more than one polling interval, the modified-since logic is broken.
$ ti-connector test --feed ai-scoring-feed-primary --verbose
> connecting to threatintel.solvethenetwork.com...
> auth: ok (service_account=infrarunbook-admin)
> schema version: stix-2.1
> objects fetched: 1,204 (new: 38, modified: 166)
> last_modified_ts: 2026-08-23T04:12:09Z
> latency: 118ms
2. Send a known test indicator through the pipeline. Most vendors publish a benign test IOC specifically for this. Confirm it lands in the correct confidence tier and triggers the expected playbook, not a different one.
3. Verify decay logic by checking an indicator nearing its TTL. Query your index for anything within 24 hours of expiry and confirm it's flagged for reevaluation rather than silently aging out.
4. Check that internal exclusions are actually excluding. Fire a test event with a source IP inside your 192.168.0.0/16 range and confirm no correlation match fires against it.
$ soc-pipeline verify --rule ai-feed-match-external-egress --dry-run
> loaded exclude_internal_ranges: 3 CIDR blocks
> test event (src=192.168.14.22) -> excluded, no match generated
> test event (src=203.0.113.44, matches feed IOC) -> match, confidence=92, tier=auto_action
> playbook triggered: contain_and_isolate
If all four checks pass, you're in reasonably good shape. I'd still recommend running the pipeline in shadow mode — logging matches without triggering auto-action — for at least a week before letting the auto_action tier actually execute containment playbooks. You want a baseline of match volume before you let anything fire automatically.
Common Mistakes
The single most common mistake I see is treating every indicator in an AI feed as equally actionable. Teams import the whole feed, wire it straight into a blocking playbook, and within a week someone's asking why a customer's mail server got firewalled. The confidence score exists precisely so you don't have to treat everything the same — use it.
A close second is ignoring the decay window entirely. Static blocklists don't expire, so a lot of SOC tooling was built with the assumption that once an indicator is in, it stays in until someone manually removes it. AI-scored feeds are dynamic by design. An indicator's confidence can drop as context changes, and if your pipeline never re-evaluates it, you end up enforcing decisions the model itself has since reversed.
Third, and this one's subtle: not excluding internal address space from correlation matching. I've seen this generate a flood of false positives when a feed vendor's IOC set happens to overlap with a CDN range that also gets used internally via a reverse proxy. It looks like a real hit until someone digs in and realizes it's your own load balancer talking to itself.
Fourth, skipping the shadow-mode period. It's tempting to go live with auto-action immediately, especially if leadership is pushing for visible ROI on the threat intel spend. Don't. A week of shadow-mode logging costs you almost nothing and will surface tuning issues — bad exclusions, threshold mismatches, playbook misconfigurations — before they cause an outage.
Finally, don't forget to monitor the feed connector itself as infrastructure. I've watched a service account's API key expire silently, with the connector still reporting a "connected" status while actually failing every poll. Set up a heartbeat alert on the connector's last successful poll timestamp, not just its process status. A connector that's technically running but hasn't ingested anything in six hours is functionally the same as no threat intel feed at all, and that's a much worse position to be in than having no AI feed in the first place — because everyone assumes the coverage exists when it doesn't.