Paper deep dive
MCPThreatHive: Automated Threat Intelligence for Model Context Protocol Ecosystems
Yi Ting Shen, Kentaroh Toyoda, Alex Leung
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/18/2026, 1:30:40 AM
Summary
MCPThreatHive is an open-source platform designed to automate the end-to-end lifecycle of threat intelligence for Model Context Protocol (MCP) ecosystems. It features a four-stage pipelineâintelligence gathering, AI-driven threat analysis, structured knowledge graph storage, and interactive visualizationâto address critical security gaps in agentic systems, such as compositional attack modeling and the lack of unified multi-framework classification.
Entities (5)
Relation Signals (3)
MCPThreatHive â operationalizes â MCP-38
confidence 100% · The platform operationalizes the MCP-38 threat taxonomy
MCPThreatHive â mapsto â STRIDE
confidence 95% · MCP-38 threat patterns mapped to STRIDE
MCPThreatHive â uses â DREAD
confidence 95% · A composite risk scoring model adapted from DREAD provides quantitative prioritization
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:The rapid proliferation of Model Context Protocol (MCP)-based agentic systems has introduced a new category of security threats that existing frameworks are inadequately equipped to address. We present MCPThreatHive, an open-source platform that automates the end-to-end lifecycle of MCP threat intelligence: from continuous, multi-source data collection through AI-driven threat extraction and classification, to structured knowledge graph storage and interactive visualization. The platform operationalizes the MCP-38 threat taxonomy, a curated set of 38 MCP-specific threat patterns mapped to STRIDE, OWASP Top 10 for LLM Applications, and OWASP Top 10 for Agentic Applications. A composite risk scoring model provides quantitative prioritization. Through a comparative analysis of representative existing MCP security tools, we identify three critical coverage gaps that MCPThreatHive addresses: incomplete compositional attack modeling, absence of continuous threat intelligence, and lack of unified multi-framework classification.
Tags
Links
- Source: https://arxiv.org/abs/2604.13849v1
- Canonical: https://arxiv.org/abs/2604.13849v1
Trouble viewing inline? Open PDF directly â
Full Text
40,542 characters extracted from source content.
Expand or collapse full text
April 2026 MCPThreatHive: Automated Threat Intelligence for Model Context Protocol Ecosystems Vulcan Research, AIFT Yi Ting Shen, KentarohToyoda, and Alex Leung https://github.com/VulcanLab/MCPThreatHive Contents 1. Introduction.........................................................................................................2 2.Background and Related Work.......................................................................................2 3. Problem Statement..................................................................................................4 4.MCPThreatHive.....................................................................................................5 5.Evaluation..........................................................................................................8 6.Discussion..........................................................................................................9 7.Conclusion and Future Work.........................................................................................10 Abstract TherapidproliferationofModelContextProtocol(MCP)-basedagenticsystemshasintroducedanewcategoryofsecuritythreats that existing frameworks are inadequately equipped to address. We present MCPThreatHive, an open-source platform that auto- mates the end-to-end lifecycle of MCP threat intelligence: from continuous, multi-source data collection through AI-driven threat extraction and classification, to structured knowledge graph storage and interactive visualization. The platform operationalizes theMCP-38threattaxonomy,acuratedsetof38MCP-specificthreatpatternsmappedtoSTRIDE,OWASPTop10forLLMApplica- tions,andOWASPTop10forAgenticApplications. Acompositeriskscoringmodelprovidesquantitativeprioritization. Througha comparativeanalysisofrepresentativeexistingMCPsecuritytools,weidentifythreecriticalcoveragegapsthatMCPThreatHivead- dresses: incompletecompositionalattackmodeling,absenceofcontinuousthreatintelligence,andlackofunifiedmulti-framework classification. arXiv:2604.13849v1 [cs.CR] 15 Apr 2026 MCPThreatHive 1 Introduction The Model Context Protocol (MCP), introduced by Anthropic in late 2024 [1], has rapidly emerged as the de facto standard for connectinglargelanguagemodel(LLM)-basedagentstoexternaltoolsanddatasources. Byprovidingastandardized,bidirectional communication channel between AI host applications and tool servers, MCP has accelerated the development of autonomous agenticworkflowsspanningfilesystems,databases,webservices,andcodeexecutionenvironments. Asofearly2026,hundreds of open-source and commercial MCP servers are publicly available, and major AI platforms, including Claude, GitHub Copilot, and Cursor, haveadopted MCP as a first-class integrationmechanism. This rapid adoption has outpaced the security communityâs ability to characterize and mitigate the associated risks. Unlike tradi- tionalsoftwareinterfaces,MCPtoolselectionandinvocationaremediatedbynatural-languagedescriptionsinterpretedbyanLLM. Thissemanticmediationintroducesattackvectors(tooldescriptionpoisoning,indirectpromptinjectionviaexternaldata,parasitic tool chaining) with no direct analogues in classical threat models. Concurrently, agentic systems operate with significant auton- omy, accumulate rich contextual state across multi-turn interactions, and may invoke dozens of tools per session, dramatically increasingthe blast radiusof a successful compromise. Existing security frameworks and tools address fragments of this problem but leave critical gaps. A comparative analysis of representativeMCPsecuritytools(Section5.1)revealsthreerecurringshortcomings: incompletecompositionalattackmodeling, absence of continuous threatintelligence, and lack of unified multi-frameworkclassification. We present MCPThreatHive, an open-source platform that automates the end-to-end lifecycle of MCP threat intelligence: from continuous, multi-source data collection through AI-driven threat extraction and classification, to knowledge graph construction andinteractivevisualization. TheplatformoperationalizestheMCP-38threattaxonomy[ 2],acuratedsetof38MCP-specificthreat patternsmappedtoSTRIDE,OWASPTop10forLLMApplications[3,4],andOWASPTop10forAgenticApplications[5]. Acomposite risk scoring model adapted fromDREAD [6] providesquantitativeprioritization. The keycontributions of this paper are: 1.An automated four-stage pipeline for continuous MCP threat intelligence, covering collection, AI-powered analysis, knowl- edge graphstorage,and interactivevisualization. 2.Acompositeriskscoringmodelcombiningsecurityimpactseverity,attacksuccessrate,persistencescope,andexploitation ease, with MCP-specific priority multipliers. 3.AcomparativeanalysisofrepresentativeexistingMCPsecuritytools,identifyingthreecriticalcoveragegapsthatMCPThreatH- iveaddresses. 4.An open-sourceimplementation releasedfor community use and extension. The remainder of this paper is organized as follows. Section2surveys the MCP ecosystem and related work. Section3presents the problem statement and gap analysis. Section4describes the MCPThreatHive platform. Section5compares MCPThreatHive withexistingtoolsandevaluatesthepipelineagainstaknownincident. Section6discusseslimitations,andSection7concludes. 2 Background and Related Work This section surveys the MCP ecosystem, known attack classes, and the security frameworks and tools that have been proposed toaddressthem. Weidentify the specific limitations of each, which togethermotivate the design of MCPThreatHive. 2.1 The Model Context Protocol The Model Context Protocol (MCP) is an open standard that defines how AI host applications communicate with external tool servers [1]. The architecture comprises three roles: theHost(user-facing application with an embedded LLM), one or moreMCP Clients(protocol handlers that maintain stateful sessions), andMCP Servers(lightweight processes that expose tools, resources, and prompts via JSON-RPC 2.0). Communication occurs over either local stdiopipes or remote HTTP with Server-Sent Events (SSE). Figure1illustratesthis three-tierarchitecture. ThedefiningcharacteristicofMCPisthattoolselectionisdelegatedtotheLLMatinferencetime. TheLLMreadsnatural-language descriptionfieldsfromserver-providedtoolmanifestsanddecideswhichtooltoinvokeandwithwhichparameters. Thisdesign enablesflexible,context-sensitivetoolusebutsimultaneouslyintroducesasemantic attack surface: anyactorwhocanwritearbi- trary text into a field the LLM reads (tool descriptions, resource content, external documents) can influence the modelâs decisions without altering any executionlogic. 2 of11 MCPThreatHive User Host LLM MCP ClientMCP Client MCP ServerAMCP ServerB toolcalltoolcall JSON-RPCJSON-RPC Figure 1: MCP three-tier architecture. The Host embeds an LLM and one or more MCP Clients, each maintaining a stateful session with an MCP Server over JSON-RPC 2.0. Eachtoolmanifestcontainsname,description,inputSchema(aJSONSchema),andoptionalannotations. Sincethedescription fieldisunconstrainedfreetextinterpretedbytheLLM,itconstitutestheprimaryinjectionsurface. MCPcurrentlylacksmandatory cryptographic signing, content-addressing, or version pinning for tool manifests, meaning that a server audited at timet 0 may exhibit differentbehavior at timet 1 . 2.2 Known MCP Attack Classes Published research has identified several concrete attack classes since MCPâs introduction in late 2024. Shen et al. [2] systemat- ically catalog these into 38 protocol-specific threat patterns (MCP-01 through MCP-38) organized across five risk categories; we summarizethe most prominentclasses below. Indirect Prompt Injection (IPI)Attackers embed malicious instructions in external data consumed by MCP tools, such as web pages, documents, or emails, causing the agent to execute unintended commands. Greshake et al. [ 7] first demonstrated IPI in LLM-integrated applications; subsequent work shows that MCP-connected agents are significantly more susceptible due to their autonomoustool-invocationcapability and wider data exposuresurface [ 8,9]. ParasiticToolChains(MCP-UPD)Zhaoetal.[10]formalisetheMCPUnintendedPrivacyDisclosure(UPD)model,inwhichindividually benigntoolsarechainedtoexfiltratedataorescalateprivileges. Forexample,aweather_apicallreturnsoutputembeddedwith a malicious payload, which is then written to disk by afile_writetool. Each individual tool is legitimate; the attack emerges fromtheir composition under adversarialdirection. Preference Manipulation (MPMA)Wang et al. [11] demonstrate that crafting specific metadata fields, such as priority annotations orLLM-preferencesignalsintooldescriptions,canstatisticallybiastheLLMâstoolselectiontowardattacker-controlledtools,even when trusted alternativesareavailable. Tool Description PoisoningMalicious tool descriptions can embed hidden instructions using Unicode zero-width characters, ho- moglyphs, or strategically placed natural-language commands that are invisible to human reviewers but influence LLM decision- making. Full schema poisoning extends this technique to the JSON Schemadescriptionfields withininputSchema, affecting how the model generatesinvocationparameters[ 8]. Rug Pull / Dynamic MutationMCP server operators can update server behavior after users have established trust. Because MCP lacks cryptographic content-addressing or version pinning for tool descriptions, a server that was audited at timet 0 may exhibit entirelydifferentbehaviorat timet 1 , analogous toa supply chain attack operatingat the semantic layer. Real-world incidentsThese attack classes are not purely theoretical. The GitHub MCP vulnerability (2025) demonstrated indirect prompt injection via crafted repository content, enabling exfiltration of private data from other usersâ sessions [ 12]. CVE-2025- 6514 [13] exposed an OS command injection vulnerability in mcp-remote, a widely used MCP transport library, enabling remote code executionwhen connecting toa malicious server. 3 of11 MCPThreatHive 2.3 Existing Security Frameworks Several security frameworks provide partial coverage of MCP threats, but none was designed for the protocolâs specific charac- teristics. Classical frameworks such as STRIDE [6] and MITRE ATT&CK (including its AI supplement, ATLAS [14]) model threats in termsofdeterministicsystembehaviorandconcretesystemactions(e.g.,fileaccess,networkconnections). Theydonotnatively capture semantic attacks where the adversary influences modelreasoningrather than systemlogic. Nevertheless, STRIDEâs six categoriesremainusefulasaclassificationbackbone;theMCP-38taxonomy[2]mapsall38MCPthreatstotheirprimarySTRIDE categories, and MCPThreatHiveoperationalizesthis mapping for automated classification. The OWASP Top 10 for LLM Applications [3,4] and the OWASP Top 10 for Agentic Applications [5] advance coverage toward AI- specificriskssuchaspromptinjection(LLM01)andagentgoalhijacking(ASI01). However,bothoperateatahighabstractionlevel and do not address the compositionality of multi-tool MCP workflows or protocol-level threats such as transport tampering and manifestpoisoning. Theclosestexistingworktoaprotocol-specificframeworkisMCPSecBench[8],whichprovidesa4Ă17benchmarkmatrixcovering fourattacksurfacesagainst17attackcategories. TheMCP-38taxonomy[2]cross-mapsall38threatpatternstothismatrix. How- ever,MCPSecBenchisabenchmarkingtoolratherthanacontinuousthreatintelligenceplatformanddoesnotprovideautomated classification, knowledge graph construction, or risk scoring. Similarly, the Cloud Security Allianceâs MAESTRO framework [15] offers useful architectural decomposition across seven layers for agentic AI systems but operates at the system design level and lacks automatedthreatdetection. 2.4 Threat Intelligence Platforms and MCP Security Tools EstablishedthreatintelligenceplatformssuchasMISP[ 16]andOpenCTI[17]providecollaborativesharingandstructuredstorage for indicators of compromise (IoCs), but they are designed for network and endpoint threats. They lack native support for the semantic, inference-timethreat classes that characterizeMCP ecosystems. Within the MCP-specific tool ecosystem, several point solutions have emerged. MCP-Scan [18] performs static analysis of tool descriptions to detect known poisoning patterns. Other tools focus on runtime guardrails (e.g., Ramparts, MCP-Guardian), per- mission enforcement(e.g., PangeaMCP Proxy),or configurationauditing (e.g., Agentic Radar). While valuablefor their respective use cases, these tools share three limitations: (1) they operate on individual tool descriptions or invocations without modeling compositional attacks across tool chains, (2) they provide point-in-time scanning rather than continuous threat intelligence, and (3) theyclassify threatsagainst a single frameworkratherthan providingunified multi-frameworkcoverage. While the MCP-38 taxonomy [ 2] provides the definitional foundation for MCP-specific threats, no existing platform combines con- tinuous multi-source intelligence gathering, automated AI-driven threat classification, structured knowledge graph storage, and multi-frameworkmapping(STRIDE,OWASPLLM,OWASPAgentic,MCPSecBench,MAESTRO)intoanintegratedthreatintelligence pipelineforMCPecosystems. MCPThreatHivefillsthisgapbyoperationalisingMCP-38withinanend-to-endautomatedplatform. 3 Problem Statement The previous section established that MCP introduces a structurally distinct attack surface and that existing frameworks and tools provide only partial coverage. This section defines the specific gaps that MCPThreatHive addresses; a detailed capability comparison with existing toolsis presentedin Section5.1. Three critical gaps motivate this work. First, existing tools model threats in isolation and cannot detect compositional attacks where the risk emerges from the interaction between individually benign tools. Second, all reviewed tools operate in manual or point-in-time mode rather than continuously monitoring intelligence sources for newly emerging threats. Third, per-tool scanners classify threats against a single framework (e.g., STRIDE or OWASP LLM) and do not provide unified multi-framework coverage spanning STRIDE, OWASPLLM, OWASPAgentic, and MCP-38. MCPThreatHive addresses these gaps through an integrated platform that provides: (1) operationalisation of the MCP-38 threat taxonomy [ 2] with composite risk scoring and multi-framework cross-mapping, (2) continuous, automated intelligence gathering from diverse sources (CVE databases, security blogs, academic preprints, GitHub Security Advisories) with AI-driven threat ex- traction and classification, and (3) a neuro-symbolic knowledge graph that captures compositional relationships between threats, tools,attack chains, and mitigations. 4 of11 MCPThreatHive RSS Feeds Web Search NVD API GitHub API Intelligence Gathering AI Threat Analysis CoT classification Risk scoring Output repair Structured Storage SQL database Knowledge graph Visualization & Risk Planning Threat matrix 3D landscape Risk planner IntelItemsThreatcards Queries 12 3 4 Figure 2: MCPThreatHive four-stage pipeline architecture. Data flows left to right: intelligence sources feed into collection, items are classified by an LLM, results are stored in a relational database and knowledge graph, and exposed through interactive visualization and risk planning interfaces. 4 MCPThreatHive The gaps identified in the previous section call for a platform that goes beyond point-in-time scanning or single-framework clas- sification. MCPThreatHive is our response: an open-source, end-to-end threat intelligence platform that continuously monitors theMCPsecuritylandscape,automaticallyclassifiesemergingthreatsagainsttheMCP-38taxonomy[2]andmultipleestablished frameworks,constructsaknowledgegraphofthreatrelationships,andgeneratesactionableriskplans. Thissectiondescribesthe platformâsarchitecture,its coreprocessingstages, and the keydesign decisions behind each component. 4.1 System Architecture MCPThreatHiveisstructuredasafour-stagepipeline(Figure2): (1)intelligencegathering,(2)AI-poweredthreatanalysis,(3)struc- turedstoragein a relationaldatabase and knowledge graph,and (4) interactivevisualization and risk planning. 4.1.1 Intelligence Gathering Theplatformcollectsthreatintelligencefromfourcomplementarysourcetypes: websearchviaDuckDuckGo 1 ,aprivacy-preserving searchengine;RSSfeeds(ArXivCS.CR 2 ,ArXivCS.AI 3 ,KrebsonSecurity 4 ,TheHackerNews 5 ,andSchneieronSecurity 6 );theNIST NationalVulnerabilityDatabase(NVD)RESTAPI 7 ;andGitHubSecurityAdvisoriesviatheRESTAPI 8 .Allsourcesarenormalizedto a uniformIntelItemschema comprising: identifier, title, content, source URL, source type, collection timestamp, and AI-assigned relevancescore. This normalization allows all downstreamprocessingtobe source-agnostic. Query generation is itself LLM-driven. An AI Keyword Generator produces targeted search queries seeded with the MCP-38 threat taxonomy, at multiple specificity levels, from broad (e.g., âMCP security vulnerabilitiesâ) to narrow (e.g., âMCP tool description poisoninginClaudeDesktopâ). Aniterativerefinementloopautomaticallyrelaxesqueriesthatreturnfewerthanaminimumresult threshold,preventingcoveragegaps for low-frequencythreattopics. 4.1.2 AI Threat Analysis Intelligence items that pass a configurable relevance threshold (Ξ= 0.70by default) enter the threat analysis stage, which pro- cesses items in batches of three to five through a large language model via a provider-agnostic API [19]. To prevent context truncation during the extensive chain-of-thought reasoning required by frontier models, the platform allocates a fixed, generous outputbudgetofupto12,000tokensforbatchthreatclassification. Thisbudgetaddressesacriticaloperationalpropertyoffrontier reasoningmodels: thesemodelsperforminternalchain-of-thoughtdeliberationbeforeproducingoutput,consumingasubstantial fractionoftheallocatedbudgetinintermediatereasoningsteps. Allocatingfewertokenscausestruncationoftheoutputpayload. Thesystempromptenforcesachain-of-thought(CoT)analysissequencebeforethemodelemitsstructuredoutput: (1)classifythe MCP workflow phase (Task Planning, Tool Invocation, Response Handling, or Cross-Phase), (2) assign threat identifiers from the MCP-01 to MCP-38 taxonomy, (3) determine the primary STRIDE category, (4) assess DREAD-adapted risk factors, and (5) verify 1 https://duckduckgo.com 2 http://export.arxiv.org/rss/cs.CR 3 http://export.arxiv.org/rss/cs.AI 4 https://krebsonsecurity.com/feed/ 5 https://feeds.feedburner.com/TheHackersNews 6 https://w.schneier.com/feed/atom/ 7 https://services.nvd.nist.gov/rest/json/cves/2.0 8 https://api.github.com/advisories 5 of11 MCPThreatHive Table 1: Example composite risk scoring factors and weights. FactorSymbol Weight Definition Security Impact SeverityL norm 0.35 Normalized7-levelscale:L/7 AttackSuccess RateS0.30 Empirical exploitation probabilityâ[0,1] Persistence/ ScopeI0.20 Transient=0.5, Session=0.75, Long-term=1.0 Exploitation EaseD0.15 Insider-only=0.33, Moderate=0.66, Trivial=1.0 consistency between the textual risk level and the numeric risk score. Schema-aware prompting embeds semantic consistency constraints alongside the output JSON schema. For example, theCriticalrisk level may be assigned only when the numeric score exceeds9.0andthethreatinvolvesremotecodeexecution,dataexfiltration,orcriticalassetcompromise. Thisconstraintinjection reduces risk-level hallucination compared to unconstrained generation. Following this CoT classification, the system applies a deterministictaxonomybridge: alookuptablemapseachassignedMCP-38identifiertoitscorrespondingcategoriesintheOWASP LLMTop10andOWASPAgenticTop10frameworks. Thishybriddesignintentionallyseparatessemanticreasoning(LLM-assigned STRIDEandMCP-38labels)fromstructuredframeworkalignment(rule-basedOWASPmapping),eliminatingtheriskofhallucinated frameworkassignments. Because LLM-generated structured output may be syntactically malformed due to context-length truncation or grammar drift, the system applies a three-stage output repair pipeline: (1) strict JSON parsing for well-formed outputs, (2) a bracket-balancing character-stack algorithm that appends missing closing delimiters to recover truncated arrays or objects, and (3) pattern-based fieldextractionthatrecoversindividualthreatrecordsbymatchingknownschemafieldsequences,enablingpartialrecoveryeven when the model terminates mid-record. EachthreatcardisfurtherannotatedwithitsphasewithintheMCP-UPDparasitictoolchainmodel[ 10],whichdecomposesmulti- tool attacks into three phases: parasitic ingestion (adversary embeds malicious instructions in external data), privacy collection (the agent collects sensitive data via legitimate tools), and privacy disclosure (exfiltration of collected data). Following Zhao et al. [ 10], we label inter-tool transitions as T2T (tool-to-tool) and the final exfiltration step as UPD (unintended privacy disclosure). This annotation enables the knowledge graph torepresentmulti-hop attack paths as directededges between toolnodes. 4.1.3 Composite Risk Scoring To move beyond binary threat classification and support quantitative prioritization, MCPThreatHive includes a configurable com- posite risk scoring model. The platform ships with a default scoring formula adapted from the DREAD methodology [ 6], reinter- pretedforLLM-agenticcontexts. Organizationscanadjusttheweights,factors,orreplacetheformulaentirelytomatchtheirown risk appetite. To align with established cybersecurity conventions, we employ a CVSS-style scale of 0 to 10 for risk scoring. The formula below computes a base risk scoreRâ[0,1]bycombining four factors: R=w L ·L norm +w S ·S+w I ·I+w D ·D(1) wherethe factorsand default weights arelisted in Table1. A set of MCP-specific priority multipliers amplifies the score for threat classes that are unique to agentic systems: semantic or inference-timeattacks(Ă1.20),parasiticchainingormulti-toolamplification(Ă1.15),andlowruntimeobservability(Ă1.10). The finalcompositeriskscoreisR final =min(10.0,(RĂP)Ă10),classifiedasCritical(â„9.0),High(7.0â€R final <9.0),Medium (4.0â€R final <7.0), or Low (R final <4.0). As an illustration, MCP-19 (Direct Prompt Injection) receivesL=6(RCE possible;L norm = 6/7),S=0.85,I=0.75(session- scoped),D=1.0(trivially exploitable), yieldingR= 0.300 + 0.255 + 0.150 + 0.150 = 0.855. As a semantic attack, the inference-time multiplier (P= 1.20) applies, givingR final =min(10.0,(0.855Ă1.20)Ă10) = 10.0, classified asCritical. This alignswithempiricalevidencethatdirectpromptinjectionisthemostvalidatedanduniversallyexploitableMCPthreatclass[ 8,9]. 4.1.4 Knowledge Graph Construction Threat cards and their associated entities are persisted in both a relational database and aneuro-symbolic knowledge graph. The graphcombinestheprecisionofrule-basedextractionwiththesemanticgeneralityofLLMinference. Deterministicpatternmatch- 6 of11 MCPThreatHive ing extracts high-confidence entities such as CVE identifiers, CWE numbers, and known attack technique keywords. Probabilistic LLM extraction covers semantic entities that resist enumeration: Threat, Mitigation, Component, Technique, Asset, and Vulnera- bility concepts expressed in free-formprose. Thegraphstoressixnodetypes(IntelligenceItem,ThreatEntity,MCPThreatID,CVEIdentifier,Tool,Mitigation)andfiveedgetypes (DESCRIBES, INSTANCES_OF, EXPLOITS, CHAINS_INTO, MITIGATED_BY). The CHAINS_INTO relationship captures MCP-UPD parasitic tool chain paths, supporting queries such as âfind all toolsreachablefroma givenentry point via documented attack chains.â Topreventgraphfragmentation fromduplicate entities, athree-tier entity resolutionpipeline canonicalises incoming entities: 1.Exact match(case-insensitivestring equality,O(1)hash lookup). 2.Jaccard similarityon 3-gramcharactershingles. Givenentity stringsAandBwith shingle setsS A andS B : J(A, B) = |S A â©S B | |S A âȘS B | (2) Entities withJâ„0.75are automatically merged. This threshold handles pluralisation, minor typos, and hyphenation vari- ants. 3.LLM verificationfor ambiguous cases (0.50â€J <0.75). The LLM is prompted: âAre âE_newâ and âE_existingâ the same securityconcept? YESorNO.âThisresolvessemanticallyequivalentbutlexicallydistinctentities(e.g.,âpromptinjectionâvs. âPI attackâ). 4.1.5 Visualization and Risk Planning Theplatformexposesfourinteractiveviews. TheThreatMatrixprojectsthederived38MCPthreatpatternsontothestandardized 4Ă17MCPSecBenchattacksurfacegrid[8],renderingaunifiedheatmapwherecellintensityencodesthesumofriskscoresacross allthreatsmappedtothatcell. ThisgridhighlightsclusteredriskareasacrossthefourcoreMCPworkflowphases(TaskPlanning, Tool Invocation, Response Handling, and Cross-Phase), offering administrators an intuitive overview of security postures. The3D ThreatLandscapemapsthefourMCPSecBenchattacksurfacesasacity-skylinemetaphor: buildingheightencodesthemaximum riskscoreandbuildingcolorencodesoneoffourattacksurfacecategoriesderivedfromtheMCP-38taxonomy: ServerAPIs(blue â authentication and RCE threats), Tool Metadata (green â poisoning and supply-chain threats), Runtime Flow (red â prompt injection and privilege escalation threats), and Transport (amber â MitM, rebinding, and transport-layer threats). TheKnowledge Graph Viewerprovidesan interactiveexplorationof entity relationshipsand attack chains. TheAI Risk Plannergenerates structured, per-threat risk plans using a Batch-Aggregate-Refine (BAR) strategy. Threats are pro- cessed in small batches; per-batch plans are generated independently, then aggregated. Duplicate mitigations are merged using Jaccard similarity. A final refinement pass produces the output document, which includes detection method recommendations, mitigationstrategieswithimplementationpriority,cross-frameworkreferences,andimplementationeffortestimates. Decompos- ing the task into batch, aggregate, and refine stages prevents the model from producing repetitive output across a large threat set. 4.2 Implementation MCPThreatHive is implemented in Python and released as open-source software. 9 The backend exposes a REST API via Flask with CORS support. Threat data is persisted in SQLite or PostgreSQL through SQLAlchemy ORM, while the knowledge graph is stored in Neo4j. LLM inference is provider-agnostic via LiteLLM [ 19], supporting OpenAI, Anthropic, and local endpoints. The frontendusesJavaScriptwithThree.jsforthe3Dthreatlandscapevisualization. TheplatformcanbedeployedviaDockerCompose or run manually through an interactive setup wizard that configures LLM provider credentials and model selection. While the architecture is designed to support continuous threat intelligence monitoring, practical deployments initialise with a cold start phase: administratorsmanuallytriggertheintelligencegatheringinterfacetoingestthebaselinethreatcorpusandinstantiatethe foundational knowledge graph,after which subsequent updates can be processedincrementally. Figure 3presentstheplatformâskeyinterfaces. Theintelligencegatheringview(3a)displayscollecteditemswithrelevancescores andsourcemetadata. Thethreatmappingview( 3b)showscross-frameworkmappingstoOWASPLLMTop10andOWASPAgentic Top 10, while individual threat cards (3c) expose per-threat detail including domain, STRIDE classification, and linked intelligence items. Theknowledgegraph(3d)visualizesthreatrelationshipsinNeo4j,enablinganalyststotracemulti-hopattackpaths. Therisk planning dashboard ( 3e) presents prioritized threats with detection methods, tooling recommendations, and test cases. Finally, the 3D threat landscape (3f) renders all 38 MCP threats as a navigable cityscape where bar height encodes severity and color 9 https://github.com/VulcanLab/MCPThreatHive 7 of11 MCPThreatHive (a) Intelligence Items(b) Threat Mapping(c) MCP-38 Description (d) Threat Relationship Graph(e) Risk Planning Dashboard(f) 3D Threat Visualization Figure 3: MCPThreatHive system interfaces: (a) intelligence gathering with relevance scoring, (b) cross-framework threat mapping, (c) per-threat detail card, (d) knowledge graph visualization, (e) risk planning dashboard, and (f) 3D threat landscape. Table 2: Capability comparison of MCP security tools.â= supported, (âŒ) = partial, â = not supported. CapabilityMCP- Scan Ramparts Agentic Radar MCP- Guardian MCPSec- Bench MCPThreat- Hive MCP-38 taxonomycoverageââ Continuous threatintelligenceââ Knowledgegraphconstructionââ AI-generatedrisk plansââ Multi-frameworkmappingâ(âŒ)ââ MCP-UPD chain analysisââ Static manifestanalysisââ(âŒ) Runtime proxyinterceptionââââ Human-in-the-loop approvalâââ Attacksimulationâ(âŒ)âââ encodesattacksurface. ThedashboardadditionallyfeaturesadedicatedSTRIDEAnalysisview,renderingadistributionchartthat segmentsclassifiedthreatsacrossthesixSTRIDEcategories(Spoofing,Tampering,Repudiation,InformationDisclosure,Denialof Service,ElevationofPrivilege),enablingsecurityteamstorapidlyidentifywhichattackparadigmdominatesthecurrentintelligence corpus. 5 Evaluation 5.1 Comparison with Existing Tools Existing MCP security tools fall into three categories: manifest scanners (e.g., Ramparts, Agentic Radar), runtime proxies (e.g., MCP-Guardian, Pangea MCP Proxy), and attack simulation platforms (e.g., MCPSecBench [ 8], MCPSafetyScanner). Some tools spancategories;MCP-Scan[18]combinesstaticmanifestanalysiswithruntimeproxyinterception. Table2comparesMCPThreatH- ivewith representative toolsacrosskeycapability dimensions. The comparison reveals three gaps. First, existing tools model threats in isolation and cannot detect compositional attacks such as preference manipulation [ 11] and parasitic tool chains [10], where the risk emerges from the interaction between individually benign tools. Second, all reviewed tools operate in manual or point-in-time mode rather than continuously monitoring intelligence 8 of11 MCPThreatHive Table 3: Pipeline trace for the GitHub MCP prompt injection incident. Each row shows a pipeline stage, its processing action, and the output produced. StageProcessingOutput Intel CollectorQuery: âGitHub MCP promptinjection privaterepositoryâ fetchesCybernews article IntelItemwith relevance= 0.94 RelevanceFilterAI relevancescore0.94> Ξ= 0.70Item passed tothreatanalysis ThreatAnalyzerCoT: âexternalfile content acted as indirectinjection vector;second toolcall exfiltratedtokensâ MCP-20 (IndirectPromptInjection), MCP-24 (Data Exfiltration);STRIDE: Information Disclosure;OWASP LLM 2025: LLM01, LLM02; OWASPAgentic: ASI01, ASI02 MCP-UPD Analyzer Chain identified: GitHub readtool(T2T) âtokenexfiltrationtool(UPD) Parasiticchain: T2TâUPD KnowledgeGraph New nodes: Threat INSTANCES_OF ââMCP-20; Threat CHAINS_INTO ââMCP-24 4 nodes, 3 edges added sources. Third, per-tool scanners classify threats against a single framework (e.g., STRIDE or OWASP LLM) and do not provide unified multi-framework coverage spanning STRIDE, OWASP LLM, OWASP Agentic, and MCP-38. MCPThreatHive is the only tool thatprovidescontinuousthreatintelligence,knowledgegraphconstruction,AI-generatedriskplans,andMCP-UPDchainanalysis. Conversely,itdoesnotperformruntimeproxyinterceptionorattacksimulation,whichareaddressedbycomplementarytoolssuch as MCP-Scan [18] and MCPSecBench [8]. 5.2 Case Study: GitHub MCP Prompt Injection To validate that MCPThreatHive produces correct classifications, we test the pipeline against a publicly known, expert-labeled incident: the GitHub MCP prompt injection vulnerability disclosed in 2025 [ 12]. This is not a claim that the platform discovered the incident; rather, we use it as ground truth to verify that each pipeline stage produces the expected output when the incident is ingested as an intelligence item. IntheGitHubMCPincident,anattackerplacedacraftedfileinapublicrepositorycontaininghiddenpromptinjectioninstructions. WhenaClaudeagentusingtheGitHubMCPserverreadthefile,theinjectedinstructionsredirectedtheagenttoaccesstokensfrom a separate private repository and exfiltrate them through a subsequent tool call. Security researchers classified this as Indirect PromptInjection combined with Data Exfiltration[ 12]. We fed the corresponding Cybernews article into the MCPThreatHive pipeline and recorded the output at each stage. Table 3 summarizesthe trace. The AI-assigned primary classification MCP-20 (Indirect Prompt Injection) and secondary classification MCP-24 (Data Exfiltration viaToolOutput)matchtheexpert-assignedlabelsforthisincident. TheMCP-UPDchainannotation(T2TâUPD)correctlycaptures the two-phase attack structure: the agent first reads malicious content through a legitimate tool (parasitic ingestion), then exfil- tratesdatathroughasecondtoolcall(privacydisclosure). Thistracedemonstratesthatthepipelineâschain-of-thoughtprompting and schema-awareconstraintsproduceclassifications consistent with expert analysis on a known incident. 6 Discussion 6.1 Limitations MCPThreatHivereliesonLLM-basedclassification,whichintroduceslimitationstheplatformmitigatesbutcannoteliminate. First, hallucination: the self-verification chain-of-thought step and schema-aware consistency constraints (Section4.1.2) reduce but do not prevent incorrect risk-level assignments. Second, token budget sensitivity: frontier reasoning models require a minimum output budget (â„12,000 tokens) to avoid truncating their internal deliberation, a failure mode discovered during development and addressed by allocating a fixed output budget of 12,000 tokens (Section 4.1.2). Third, domain shift: non-English threat reports or 9 of11 MCPThreatHive non-standard terminology may be misclassified; multilingual prompting is a planned mitigation. Fourth, false positives and mis- classification: the classifier may flag legitimately described tools that use aggressive language (e.g., penetration-testing utilities) asmalicious,mislabelingthemasSandboxEscapeorDataExfiltrationthreats. MCPThreatHiveisintentionallydesignedasahigh- confidence indicator system rather than an automated remediation engine; its outputs should be reviewed by a qualified analyst beforeany restrictivecountermeasuresare applied todeployedMCP serverconfigurations. TheevaluationinSection5demonstratesclassificationfidelityonasingleknownincident. Aformalempiricalevaluationmeasuring precisionand recallacrossa larger labeled incident corpus is needed toquantify classification accuracyat scale. 6.2 Deployment Context MCPThreatHive is designed for three primary audiences: (1) security teams responsible for MCP-integrated AI products, using the threat matrix and risk planner to prioritize remediation; (2) researchers studying MCP security, using the knowledge graph to identify threat chains and coverage gaps; and (3) compliance teams using the cross-framework OWASP and STRIDE mappings to support security posturereporting. Theplatformisathreatintelligenceandmodelingtool,notaruntimeprotectionproxyorstaticmanifestscanner. Itcomplements runtime tools such as MCP-Scan [ 18] by providing the upstream intelligence layer: identifying and classifying threats that runtime scanners can then detect in deployedconfigurations. 6.3 Ethical Considerations The MCP-38 taxonomy and the threat cards generated by the platform describe attack techniques in sufficient detail to be useful fordefenders. Thisdual-useriskisinherenttothreatintelligence: thesameinformationthathelpsasecurityteambuilddetection rules could, in principle, inform an attacker. We mitigate this by focusing platform output on detection methods, mitigations, and risk prioritization rather than step-by-step exploitation procedures. The open-source release enables community review of the taxonomyand the AI classification logic, supporting transparencyand reproducibility. 7 Conclusion and Future Work We have presented MCPThreatHive, an open-source threat intelligence platform for Model Context Protocol agent ecosystems. The platform implements a four-stage pipeline (intelligence gathering, AI-powered threat analysis, knowledge graph construction, andinteractivevisualization)thatcontinuouslymonitorsmultiplesourcesandautomaticallyclassifiesemergingthreatsagainstthe MCP-38taxonomy[ 2],STRIDE,andtheOWASPLLMandAgenticTop10frameworks. Acompositeriskscoringmodeladaptedfrom DREADprovidesquantitativeprioritization,andabatch-aggregate-refineriskplannergeneratesactionablemitigationstrategies. A case study on the GitHub MCP prompt injection incident demonstrates that the pipeline produces classifications consistent with expert analysis. Several directions remain for future work. First, a formal empirical evaluation of classification precision and recall on a larger labeledincidentcorpuswouldstrengthenconfidenceinthepipelineâsaccuracy. Second,exportingplatformintelligenceasSemgrep or YARA rules would enable push-to-scanner threat feeds for runtime integration. Third, STIX/TAXII export would support cross- organisation threat intelligence sharing. Finally, continuous monitoring of MCP registries such as Smithery [ 20] and Glama [21] would enable automateddetection of new types of attacks in the wild. References [1]Anthropic,âModel Context Protocol Specification,âhttps://modelcontextprotocol.io, 2024, accessed: 2026-04-07. [2]Y.T.Shen,K.Toyoda,andA.Leung,âMCP-38: AComprehensiveThreatTaxonomyforModelContextProtocolSystems,âarXiv preprint arXiv:2603.18063, 2026. [Online]. Available:https://arxiv.org/abs/2603.18063 [3]OWASP Foundation, âOWASP Top 10 for Large Language Model Applications v1.1,âhttps://owasp.org/ w-project-top-10-for-large-language-model-applications/, 2023, accessed: 2026-04-08. [4]â, âOWASP Top 10 for Large Language Model Applications 2025,âhttps://genai.owasp.org/resource/ owasp-top-10-for-llm-applications-2025/, 2025, accessed: 2026-04-08. 10 of11 MCPThreatHive [5]â, âOWASP Top 10 for Agentic Applications for 2026,âhttps://genai.owasp.org/resource/ owasp-top-10-for-agentic-applications-for-2026, 2025, accessed: 2026-04-07. [6]A. Shostack,Threat Modeling: Designing for Security. Wiley,2014. [7]K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, âNot What Youâve Signed Up For: Compromising Real- WorldLLM-IntegratedApplications with IndirectPromptInjection,âarXiv preprint arXiv:2302.12173, 2023. [8]Y.Yang,Y.Wuetal.,âMCPSecBench: ASystematicSecurityBenchmarkandPlaygroundforTestingModelContextProtocols,â arXiv preprint arXiv:2508.13220, 2025. [Online]. Available:https://arxiv.org/abs/2508.13220 [9]D. Zhang, Z. Li, X. Luo, X. Liu, P. Li, and W. Xu, âMCP Security Bench (MSB): Benchmarking Attacks Against Model Context Protocolin LLM Agents,âarXiv preprint arXiv:2510.15994, 2025. [Online]. Available:https://arxiv.org/abs/2510.15994 [10]S. Zhao, Q. Hou, Z. Zhan, Y. Wang, Y. Xie, Y. Guo, L. Chen, S. Li, and Z. Xue, âMind Your Server: A Systematic Study of Parasitic Toolchain Attacks on the MCP Ecosystem,âarXiv preprint arXiv:2509.06572, 2025. [Online]. Available: https://arxiv.org/abs/2509.06572 [11]Z. Wang, R. Zhang, Y. Liu, W. Fan, W. Jiang, Q. Zhao, H. Li, and G. Xu, âMPMA: Preference Manipulation Attack against Model Context Protocol,âarXiv preprint arXiv:2505.11154, 2025. [Online]. Available:https://arxiv.org/abs/2505.11154 [12]Invariant Labs, âGitHub MCP Vulnerability: Prompt Injection via Repository Content,âhttps://invariantlabs.ai/blog/ mcp-github-vulnerability, 2025, accessed: 2026-04-07. [13]NIST, âCVE-2025-6514: mcp-remote OS Command Injection,âhttps://nvd.nist.gov/vuln/detail/CVE-2025-6514, 2025, ac- cessed: 2026-04-07. [14]MITRECorporation,âMITREATLAS:AdversarialThreatLandscapeforArtificial-IntelligenceSystems,âhttps://atlas.mitre.org/, 2024, accessed: 2026-04-07. [15]Cloud Security Alliance, âMAESTRO: Multi-Agent Environment, Security, Threat Risk, and Outcome Framework,âhttps:// cloudsecurityalliance.org/research/topics/maestro, 2025, accessed: 2026-04-07. [16]C.Wagner,A.Dulaunoy,G.Wagener,andA.Iklody,âMISP:TheDesignandImplementationofaCollaborativeThreatIntelligence Sharing Platform,â inProceedings of the 2016 ACM Workshop on Information Sharing and Collaborative Security. ACM, 2016, p. 49â56. [17]Filigran,âOpenCTI:Open Cyber ThreatIntelligence Platform,âhttps://w.opencti.io/, 2023, accessed: 2026-04-07. [18]InvariantLabs,âMCP-Scan: SecurityscannerforAIagents,MCPserversandagentskills,âhttps://github.com/invariantlabs-ai/ mcp-scan , 2025, accessed: 2026-04-07. [19]BerriAI, âLiteLLM: Call 100+ LLM APIs with OpenAI format,âhttps://github.com/BerriAI/litellm, 2023, accessed: 2026-04-07. [20]Smithery,âSmithery: MCP ServerRegistry,âhttps://smithery.ai, 2025, accessed: 2026-04-07. [21]Glama, âGlama: MCP ServerDirectory,âhttps://glama.ai/mcp/servers, 2025, accessed: 2026-04-07. 11 of11