# Threat intelligence matched to what you actually run.

> Threat intelligence in ColossalX is matched to what you actually run: your SBOM and AI-BOM, models, agents, vendors, public addresses and container images. A daily AI supply-chain watch, known-exploited and exploit-likelihood feeds, advisories and STIX bundles arrive in one place, a person reviews what applies, and each threat ends in a recorded decision.

Feeds, advisories and a daily AI supply-chain watch, matched to your models, agents and libraries, and decided by a named person.

Canonical page: https://colossalx.tech/platform/threat-intelligence · Last reviewed: 6 Oct 2026

*Illustration:* Matched to your estate, then decided: known-exploited to your estate; advisory found calling your estate (matched); model warning to your estate; your estate to owned work (affected); your estate to gateway rule (restrict model); your estate to recorded no (not affected).

## The threat and the control

- **The threat:** A library inside one of your agents is added to the known-exploited list overnight.
- **The control:** ColossalX matches it to the agents that use it, ranks it, and asks a person to decide.

## How it works: From an advisory overnight to a recorded decision.

A library inside a production agent turns up in an advisory. It is matched, reviewed by a person and ends as owned work.

### Workflow: an exploited library, decided (illustrative)

1. **Advisory arrives.** The daily supply-chain watch finds an advisory for an installed AI library.
   AI library · agent framework, installed · Exploited | Source: public advisory data; Status: pending review
2. **Matched to estate.** It is matched to your AI-BOM and the agents built from it.
   In AI-BOM: refunds-service repository; Agents: refunds-agent, claims-agent; Criticality: production
3. **Person reviews.** A named person accepts it as affected and actionable, with a reason.
   Threat intelligence lead: Affected and actionable: upgrade this sprint | [Accept] [Dismiss]
4. **Decision recorded.** It becomes owned work, and each affected agent gets an advisory.
   Remediate · Test · Watch · Archive | Owner: Payments team; Advisory: on refunds-agent | x, accounted for

## What you see: What your own controls caught, in one feed.

Detections from the MCP firewall, runtime guard, behaviour monitor, shadow AI, exposure management and red team, in one feed, with the control that acted first.

1. **State what you need.** Intelligence requirements record the questions your team committed to answer. Each requirement has an owner and shows how long it has been open; answering one needs a note. The feeds panel shows the age of each check and lists plainly what is not collected.
2. **Match to your estate.** Feeds and STIX bundles are matched to your SBOM, AI-BOM and agents. The intel store shows three counts on purpose, stored, checkable and matched, so an observable that cannot be checked is never read as clean. A new known-exploited listing re-ranks findings you already hold, without a rescan.
3. **A person reviews.** New items wait for a person, showing the agents they reach first. The daily AI supply-chain watch checks each versioned AI component against public advisory data, including known malicious packages, and lands new items pending. A person accepts or dismisses each with a reason; ranking weighs active exploitation and the criticality of the agents reached.
4. **Decide and record.** Fix, test, watch or archive it; the decision stays on record. Remediate opens owned work with a due date, test hands the technique to a run against a live agent, watch keeps it on a watchlist while no fix exists, and archive records why it does not apply. A warning about a model can become a restriction at the gateway.

*Illustration:* An illustrative threat intelligence feed matched to an estate: a new agent framework advisory matched to the two agents that use it, with a re-test scheduled; a known-exploited library recorded as not affected; and a model warning that restricted the model at the gateway.

## How we know

- The intel store counts stored, checkable and matched items, so the uncheckable is never read as clean.
- A detection source that is not wired is reported as not wired, never as zero.
- Each decision is recorded, including a decision that a threat does not apply.
- Threat profiles drafted for agent frameworks wait for a person before they apply.

## Where a decided threat goes next.

A decision is a record that moves other work, not a note in a feed.

- **Owned work.** Remediate opens one issue with an owner and a due date, closed on positive evidence.
- **A test on demand.** Test hands the attack technique to an authorised run against a live agent.
- **A gateway restriction.** A warning about a model becomes a restriction on that model at the gateway.
- **The risk register.** An affected and actionable decision writes a risk entry, weighted by agent criticality.

Where an x ends up: x, accounted for.

## Specs: delivery and data

- **Delivery:** SaaS, from one login.
- **Isolation:** Each customer runs in an isolated workspace with its own database.
- **Certifications:** None held. Frameworks are mapped to and assessed against.

## Frameworks

- Assessed per agent against OWASP Top 10 for Agentic Applications: Agentic exposure in each framework profile.

## What it does not do

- Dark web, NVD and national CERT feeds are not collected, and the feeds panel says so.
- Model weights have no curated advisory source, so model intelligence enters only by import.
- IP addresses and file hashes are stored but cannot be checked without network data.
- Framework threat profiles start as drafts and run in monitor; blocking is your decision.

*Illustration:* Feeds · stated plainly: Known-exploited Collected; Exploit likelihood Collected; Dark web Not collected; NVD Not collected; National CERTs Not collected; Model weights Import only. Stated on screen.

## Questions

### What is threat intelligence for AI systems?

Threat intelligence for AI systems tracks the threats that touch models, agents and the AI libraries they are built from: exploited vulnerabilities, malicious packages, weaknesses in agent frameworks and new attack techniques. It is useful only when matched to what you run, which is why ColossalX starts from your SBOM, AI-BOM and agent registry.

### How is intelligence matched to our estate?

Items from feeds, advisories and STIX bundles are compared with your SBOM and AI-BOM, the models you serve and declare, your agents, vendors, public addresses and container images. The intel store counts what it stored, what it could check and what matched, so an observable it cannot check is not mistaken for a clean result.

### What happens when a warning about a model arrives?

A person reviews it first. If it is judged affected and actionable, it can become a restriction on that model at the ColossalX gateway, alongside owned work and a risk entry. Because model weights have no curated public advisory source, intelligence about a model enters by import rather than from a feed.

### Which sources feed it, and what is not collected?

Known-exploited and exploit-likelihood feeds, public advisory data including malicious packages, public exploit archives, STIX ingest and a daily AI supply-chain watch, plus a feed of what your own controls detected. Dark web, NVD and national CERT feeds are not collected, and the product states that on the feeds panel.

## Related

- [AI bill of materials](https://colossalx.tech/platform/ai-bill-of-materials)
- [Red-teaming and validation](https://colossalx.tech/platform/red-teaming)
- [Exposure management](https://colossalx.tech/platform/exposure-management)

---

ColossalX is an AI security and governance platform from Quantexra Labs LLP, delivered as SaaS. Book a walkthrough: https://colossalx.tech/demo · client.success@quantexra.tech
