gcdRadar

Methodology

gcdRadar is an observatory, not a security product. It records live security incidents across the web in four lanes, keeps an AI lens on them, counts each once 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

A record is one real-world event or flaw: a bug in software people run, something that happened to a named organisation or service, a malicious artefact with reach, or a research finding. It lands in one of four lanes:

Every record also carries an AI role, and the AI counts on the site (the Trends charts, the weekly briefing, summary.json and the chart images) cover the first two roles only:

A record with no AI role is published only when it clears the curation bar, so the live lanes stay readable: it names what was affected, says what happened, and is one of the kinds below. AI records keep the inclusion rule above and use the bar as guidance.

  1. It names the software, service or organisation affected.
  2. It says what happened or what the flaw allows.
  3. It is one of: exploitation in the wild, a critical rating with a fix or no fix stated, a confirmed breach or outage, or a malicious artefact with named reach.
  4. A follow-up to a known event becomes an update on that record, never a new one.
  5. Surveys, policy, product launches, roundups, opinion and "report finds" pieces are not incidents.

Research papers and lab write-ups that demonstrate a working attack count (severity 1, the Research lane). 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

Lanes and lifecycle

A record is live or closed, judged at every build from the record’s latest dated activity (a timeline entry, a source, or the first report; never an edit). The windows, in days:

Patch now
live for 14 days after the latest activity, or 60 days while the fix status is "no patch yet" or "partly patched" ("fix status unknown" does not extend it).
Breaches & attacks
live for 14 days after the latest activity; a new report reopens it.
Supply chain
live for 14 days after the latest activity, or 60 days while the fix status is "no patch yet" or "partly patched" ("fix status unknown" does not extend it).
Research
live for 14 days after the first report; updates do not extend it.

A disclosed vulnerability is always closed. A record the collector closed stays closed; a new report about it reopens it with a timeline entry. The fix status of a patch or supply-chain record is one of:

○ No patch yet
No fixed release exists; mitigate or disable the affected feature.
◐ Partly patched
Some versions or products have a fix, others are still waiting.
● Patched
A fixed release exists for everything affected; update and you are done.
— No fix needed
Nothing to patch: a breach, an attack or a campaign rather than a flaw.
? Fix status unknown
No source states whether a fix exists; check the linked advisory.

Records that predate the lanes were placed by fixed rules, in order; a record classified since then carries the lane the classifier gave it:

  1. Severity 1 (research or proof of concept) → Research.
  2. An AI-enabled attack (AI was the attacker's tool) → Breaches & attacks.
  3. A primary category of supply chain or data poisoning → Supply chain.
  4. A data leak with confirmed exploitation or loss (severity 3 or 4) → Breaches & attacks.
  5. Everything else, a flaw in an AI system or tool → Patch now.

Every record’s timeline starts with its reports, one entry per source; the collector appends an entry when a later report changes something. The newest entries across the site are in /changes.json.

Tags

The classifier writes short free-text tags; the site folds them into one spelling each (underscores, spaces and dots become dashes, 88 aliases such as “denial-of-service” → “dos” are merged, CVE ids and tags that only echo a category are left out) and files each under a group: attack types, stacks and products, vendors, threat actors and campaigns, sectors and channels, standards and catalogues, other. A tag with two records, or one live record, gets a page, an RSS feed and an llms.txt. 21 tags are dropped as echoes or outcomes; the lists live in the repository at lib/tags.ts.

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.
General security
No AI component: a general security incident or flaw, placed by its lane. The only category a record with no AI role carries.

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.

General security
owaspnone
atlasnone

No AI component, so neither AI framework applies.

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 gcdRadar’s own and is not endorsed by OWASP or MITRE.

How incidents are found and classified

  1. Fetch. On its schedule (the Sources page lists it per source) 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 a security term (or carry a CVE id) before any model sees them; an AI term only marks the item for the AI role. 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

The home page’s instruments

The home page is built from the same records and statistics files as the rest of the site; every rule below is stated in the code that applies it (lib/panel).

AI 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 Trends as a separate monthly series and in the Archive 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, over the AI records only (attacks on AI and AI-enabled attacks; the general lanes are not in it). 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 Trends page, 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