GCD AI RADAR

Methodology

GCD AI RADAR is an observatory, not a security product. It records, counts, categorizes and charts AI cybersecurity incidents and links to the original reporting. This page is what makes the numbers citable: it says exactly what is counted, how, and where the counts are weak.

What counts

An incident is in scope when it is one of two things, and the charts always keep them distinguishable:

Research papers and lab write-ups that demonstrate a working attack count (severity 1). CVEs and advisories for AI frameworks, model servers, agent tooling and AI products count once exploitation is confirmed (severity 3 or 4). Until then they are disclosed vulnerabilities: kept, shown and downloadable as their own series, but not counted as incidents.

What does not count

Taxonomy

An incident has exactly one type, one to four categories (the first is primary), exactly one severity, and one or more targets.

Categories

Prompt injection
Untrusted content (web pages, documents, emails, tool output) steers a model into ignoring its instructions.
Jailbreak
A user deliberately bypasses a model's safety or policy controls through crafted prompts.
Agent hijack
An AI agent is tricked into unauthorized actions: tool misuse, data exfiltration through the agent, or acting against its principal.
Data leak
Training data, chat logs, system prompts, model weights or other AI-system data exposed.
Model theft / extraction
Weights stolen, or model behaviour replicated through extraction or distillation attacks.
Supply chain
Malicious or backdoored models, poisoned packages, unsafe deserialization and other compromised AI dependencies.
Data poisoning
Training or retrieval data manipulated to change model behaviour.
Adversarial evasion
Inputs crafted to make a model misclassify or miss detections (perturbations, evasion of AI-based defences).
Infrastructure vulnerability
CVEs and advisories in AI frameworks, inference servers, MCP servers, AI developer tools and hosting stacks.
Deepfake fraud
Synthetic voice, video or images used to impersonate people for fraud, extortion or access.
AI-generated malware
Malware written, adapted or operated with meaningful help from AI models.
AI phishing / social engineering
Phishing, lures and social engineering produced or personalised at scale with AI.
AI-assisted intrusion
Threat actors using AI tooling in reconnaissance, exploitation, lateral movement or operations.
Other
In scope, but none of the categories above fits. Reviewed periodically for new categories.

Severity

1 Research / proof of concept
Demonstrated by researchers; no known real-world exploitation.
2 Disclosed vulnerability
CVE or vendor advisory, patched or patchable, no confirmed exploitation.
3 Confirmed exploitation
Used against real targets; limited or unclear impact.
4 Confirmed real-world loss
Financial loss, PHI/PII breach, safety impact or regulatory action.

Severity 3 and above is what the site calls real-world. The dashboard’s “real-world only” view excludes research findings and unexploited vulnerabilities.

Targets

Targets are normalised to a short controlled list; a free-text product field sits alongside. OpenAI · Anthropic · Google · Microsoft · Meta · Mistral · xAI · Amazon · Apple · Open-weight model · Framework / tooling · Enterprise deployment · Individuals · Not applicable.

Standards mapping

Every record is also expressed in two public frameworks, so security teams can filter and cite in the vocabulary they already use: the OWASP Top 10 for LLM Applications (2025 edition) and MITRE ATLAS techniques (data release 2026.09). OWASP names the weakness in an LLM application; ATLAS names what the adversary did.

The mapping is derived from the categories, not classified per record. Each category, and where the type changes its meaning a type and category pair, maps to fixed entries in the table below. A record carries the union over its categories. The same type and categories always give the same entries, and changing the table re-maps every record at the next build without re-classifying anything.

The rule for a row: an entry is listed only when the category, as defined above, falls within what the entry itself describes. A category that straddles several entries, or fits none, maps to nothing rather than to a stretch. A record with no entry is not evidence that no entry applies; it means the category alone cannot say which.

By category

Prompt injection

The same concept in both frameworks, direct and indirect.

Jailbreak

OWASP treats jailbreaking as a form of prompt injection; ATLAS gives it its own technique.

Agent hijack

Excessive Agency is the weakness that lets manipulated or malfunctioning model output cause damaging actions, and AI Agent Tool Invocation is the act. Prompt injection is a common trigger but not the only one, so LLM01 is not added.

Data leak
atlasnone

Sensitive Information Disclosure is the closest OWASP entry; OWASP describes it mostly through model output, while some records here are storage misconfigurations. No ATLAS technique: the category mixes misconfigured storage, application bugs and prompt-induced leakage, and LLM Data Leakage (AML.T0057) covers only the last.

Model theft / extraction

The 2025 list folded model theft into Unbounded Consumption (model extraction through the API, functional replication). ATLAS AI Intellectual Property Theft covers stolen and extracted models alike; Extract AI Model (AML.T0024.002) is not added because some records are stolen weights.

Supply chain

The same concept in both frameworks: compromised models, packages and other AI dependencies.

Data poisoning
atlasnone

LLM04 covers pre-training, fine-tuning and embedding data. ATLAS separates training-data poisoning (AML.T0020) from RAG poisoning (AML.T0070) and the records do not say which, so neither is derived.

Adversarial evasion
owaspnone

Inputs crafted to make a model misclassify are Craft Adversarial Data used to Evade AI Model. The OWASP LLM list has no entry for classifier evasion; that lives in OWASP's separate Machine Learning Security Top 10.

Infrastructure vulnerability
atlasnone

LLM03 names vulnerable third-party packages as its first example, and a CVE in an AI framework, inference server or MCP server is that risk for the teams who deploy it. No ATLAS technique: ATLAS describes what attackers do, and a vulnerability record does not say how the flaw was or would be exploited.

Deepfake fraud
owaspnone

Generate Deepfakes, used for Impersonation. No OWASP entry: no LLM application is the vulnerable party.

AI-generated malware
owaspnone

ATLAS lists obtaining generative AI to write malware under Obtain Capabilities. No OWASP entry: the AI is the attacker's tool, not the vulnerable system.

AI phishing / social engineering
owaspnone

ATLAS Phishing, whose description covers generative AI scaling phishing campaigns. No OWASP entry: the AI is the attacker's tool, not the vulnerable system.

AI-assisted intrusion
owaspnone
atlasnone

ATLAS has techniques for single steps (autonomous reconnaissance, autonomous exploit development, generating malicious commands), but the category does not record which step AI helped with, so none is derived. No OWASP entry: the AI is the attacker's tool.

Other
owaspnone
atlasnone

No defined scope, so nothing to map.

Where the type changes the answer

AI-enabled attack + supply chain
owaspnone
atlasnone

When AI is the weapon, the supply chain attacked is ordinary software (npm and PyPI packages), so the AI supply-chain entries (LLM03, AML.T0010) do not follow.

OWASP entries never derived

No category isolates LLM05:2025 Improper Output Handling, LLM07:2025 System Prompt Leakage, LLM08:2025 Vector and Embedding Weaknesses or LLM09:2025 Misinformation, so no record is tagged with them, though some records involve them: a system prompt exposed in a data leak, or a package name an LLM hallucinated. The explorer’s OWASP filter lists only the entries the table can produce.

Limits

OWASP Top 10 for LLM Applications © OWASP Foundation, CC BY-SA 4.0. MITRE ATLAS © 2021-2026 The MITRE Corporation, Apache 2.0. Entry ids and names are used to reference them; the mapping is GCD AI RADAR’s own and is not endorsed by OWASP or MITRE.

How incidents are found and classified

  1. Fetch. Every six hours a collector reads RSS and Atom feeds, official APIs and public data exports: security press, vendor and research blogs, Hacker News (via Algolia), GDELT, arXiv cs.CR, NVD, the GitHub Advisory Database, CISA KEV, MITRE ATLAS and the AI Incident Database. Query-driven sources run a maintained list of 25 search phrases.
  2. Pre-filter. Press and vendor items must mention both an AI term and a security term before any model sees them; specialist AI-security blogs and structured databases skip this gate.
  3. Deduplicate. Links are canonicalised (tracking parameters, AMP variants and the like removed). A link already seen is skipped. A shared CVE id merges records. Titles are compared against recent incidents (token overlap plus edit distance): near-identical headlines merge automatically, reworded ones are put to a language model with the question “same incident?”, and records that carry different CVE ids never merge. Candidates in the same run are grouped the same way.
  4. Classify. A language model (Gemini, with Groq as fallback) reads the title, the feed description or page summary and any vulnerability metadata, and returns a strict JSON record: in scope or not, type, categories, severity, targets, products, incident date, a two-sentence summary in its own words, tags and a confidence score. The response is validated against the schema; invalid responses are retried once, then queued.
  5. Decide. In scope with confidence ≥ 0.8: published. In scope below 0.8: held for human review. Out of scope with confidence ≥ 0.8: rejected, with the reason logged for auditing. Out of scope below 0.8: held for review. Nothing is published unclassified; if every model is unavailable, candidates wait for the next run.

Only titles, links, dates and the site’s own summaries are stored. Article text is never kept. Page fetches for metadata respect robots.txt.

Counting rules

Vulnerability records

The collector reads CVEs and advisories for an allow-list of LLM and agent-era tooling from NVD, the GitHub Advisory Database and Microsoft’s Security Update Guide: inference servers such as vLLM and Ollama, app builders such as Open WebUI, Langflow and Flowise, frameworks such as LangChain, MCP SDKs, AI coding tools and AI products. They are classified like everything else, under infrastructure vulnerability.

A record with no confirmed exploitation is a disclosed vulnerability. It keeps severity 2 and its own page, appears on the dashboard as a separate monthly series and in the incidents explorer under “records”, but it is not counted as an incident. Vendors and CVE numbering authorities file advisories in batches, as many as 30 for one product on one day, and more than 99% of these records never see a confirmed attack: counting them made the incident trend a measure of CVE issuance. A CVE becomes an incident, at severity 3, when CISA lists it as exploited or the vendor confirms exploitation.

The exact rule: a record is a disclosed vulnerability when its severity is below 3 and it either comes from the NVD or GitHub advisory backfills or every one of its sources is a vulnerability database. Anything reported by the press or by researchers counts as an incident. Downloads keep every record; the CSV carries a record_kind column and the compact JSON a disclosed flag.

Classic deep-learning libraries (TensorFlow, Keras, PyTorch, ONNX) and generic automation tools (n8n) are deliberately excluded: their memory-safety and web CVEs are about the library, not about an AI system being attacked, and they would swamp the disclosed series (TensorFlow alone had 299). The allow-list has 80 packages across 5 ecosystems plus 39 NVD search terms; it lives in the repository at collector/config/packages.json. Pre-LLM ML platforms (MLflow, NVIDIA Triton Inference Server, Ray), classic cloud ML services (Azure AI Search, Face and Language, Vertex AI Workbench) and general apps whose CVE only touches an AI or MCP feature are excluded for the same reason.

The weekly briefing

This week in AI security is written every Monday at 06:17 UTC for the ISO week (Monday to Sunday, UTC) that has just ended. It has two parts, made differently:

Limits: the checks catch wrong numbers, not every wrong word, so a narrative can still misstate what a record says; the incident pages and their sources are the reference. A briefing is a snapshot taken on Monday. Records first reported in that week but collected later are not added, so the dashboard, which recounts on every build, can show more for the same week. A week with few incidents is described from few records, and its comparison with the week before can swing widely.

Sources we read, and sources we deliberately do not

The Sources page lists every feed, API and dataset with its licence and live health. Some well-known outlets are not polled: Google News RSS (robots.txt disallows it and the feed licence allows personal readers only), The Register (robots.txt denies all crawlers not explicitly allowed) and Condé Nast titles such as Wired and Ars Technica (their terms forbid automated access and storage). Their articles still appear as sources when another source surfaces them.

Limitations and biases

Change log