Cyber Threat Intelligence AI Agent: A Practical Guide
Build a cyber threat intelligence AI agent that connects CVEs, exploitation evidence, asset exposure, and cited findings in a reviewable workflow.
A cyber threat intelligence AI agent uses tools to gather security evidence, connect relevant entities, and prepare findings for a defender. Its useful output is a traceable answer to an operational question: what changed, which assets might be affected, and what evidence should an analyst review next?
For example, a supplier-risk team might ask whether a newly reported vulnerability affects a vendor supporting a critical facility. The agent needs external threat intelligence and the team's authorized asset context. A convincing summary of a vulnerability alone cannot establish that the organization is exposed.
What should a threat intelligence agent do?
Start with a bounded research assignment: investigate a particular CVE, vendor, incident, or time window. A useful workflow has five stages:
- Collect: retrieve vulnerability records, advisories, relevant incidents, and source links.
- Resolve: connect identifiers and aliases without assuming similar names mean the same entity.
- Assess relevance: compare affected products and versions with an authorized asset inventory.
- Explain: separate documented facts, analytical inferences, and unanswered questions.
- Deliver: prepare a cited brief with the next verification step and an accountable reviewer.
Treat patching, blocking traffic, and changing accounts as separate operational capabilities with their own authorization. Research access should be sufficient for the initial workflow.
CVSS, KEV, and EPSS answer different questions
These signals are complementary inputs, not interchangeable risk scores:
| Input | Question it helps answer | What it cannot establish alone |
|---|---|---|
| CVSS Base score and vector | How severe are the vulnerability's technical characteristics? | Whether your deployed asset is exposed |
| CISA Known Exploited Vulnerabilities catalog | Is there documented exploitation in the wild? | Whether your organization has been compromised |
| EPSS probability | How likely is a published CVE to be exploited in the next 30 days? | Whether exploitation has already happened on your systems |
| Internal asset and configuration evidence | Do affected versions or conditions exist here? | The full external threat picture |
FIRST explains the limits of CVSS Base scores and defines the prediction horizon for EPSS. CISA maintains the KEV catalog as an input to vulnerability prioritization. Record when each input was checked; missing values should remain unknown instead of becoming zero risk.
Query cyber intelligence with Y2
Y2's Intel API exposes CVEs, threat actors, cyber graphs, and categorized
incidents. A research integration can start with a workspace-bound key carrying intel:cyber:
curl --get "https://api.y2.dev/api/v2/incidents" \
--header "Authorization: Bearer $Y2_API_KEY" \
--data-urlencode "category=cyber" \
--data-urlencode "status=active" \
--data-urlencode "severity=high" \
--data-urlencode "limit=10"This example selects active incidents in the high severity category. It does not include
critical incidents; request that category separately when needed. Keep the category filter:
unfiltered incident access requires intel:explorer. The
incident reference defines the current contract.
Use the returned resource identities to inspect supporting observations. For a CVE investigation,
search /api/v2/cyber/cves, then pass a returned CVE entity ID to the cyber graph operation.
Y2 graph relationships are investigation leads; follow their evidence before asserting attribution
or exposure. This workflow does not imply that Y2 supplies EPSS for every CVE or knows your asset
inventory.
For a compatible agent client, the MCP server for threat intelligence guide shows how to discover and call the same operations through Y2's MCP package.
What should the final brief contain?
Use a consistent review format. Here is a suggested brief structure, not a Y2 response schema:
| Section | Required content |
|---|---|
| Finding | A specific change and the affected product or entity |
| Evidence | Source URLs, identifiers, and observation dates |
| Relevance | Confirmed asset matches, possible matches, and unknown versions |
| Assessment | Reasoning, contradictory evidence, and confidence limitations |
| Next step | A concrete verification or remediation task for its owner |
Measure whether citations support the claims and whether asset matches are correct. Also test an empty result, stale advisory, duplicate report, and vendor-name collision. A successful API request is only one part of a successful investigation.
Frequently asked questions
Can a cyber threat intelligence AI agent replace a SIEM?
A research agent can help interpret external intelligence and authorized telemetry. A SIEM has a different job: collecting and analyzing organizational security events. Decide which system owns detection, evidence retention, and response before connecting them.
Does an empty result mean there is no threat?
No. It can reflect filters, ingestion delays, source coverage, or missing evidence. State the sources and time window searched and identify gaps that affect the conclusion.
How do I keep the workflow read-only?
Use a key with only the required read scopes, limit available operations in the host, and keep response execution separate. See MCP scoped API keys and AI agent security best practices.
Start with the Cyber API reference and one investigation whose result an analyst can independently check.