🎯 European Parliament MCP Server — Threat Model

🛡️ Proactive Security Through Structured Threat Analysis
🔍 STRIDE • MITRE ATT&CK • MCP Protocol Security • Parliamentary Data Protection

📋 Document Owner: CEO | 📄 Version: 1.3 | 📅 Last Updated: 2026-04-28 (UTC)
🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-07-28
🏷️ Classification: Public (Open Source MCP Server)

📑 Table of Contents

ISMS Policy Alignment
Security Documentation Map
Purpose & Scope
Multi-Strategy Threat Modeling Integration
System Classification
💎 Critical Assets & Crown Jewel Analysis
STRIDE Threat Analysis
MITRE ATT&CK Coverage Analysis
🏗️ Architecture-Centric STRIDE Analysis
MITRE ATT&CK Mapping
Kill Chain Disruption Analysis
Threat Agent Classification
Current Threat Landscape
Scenario-Centric Threat Modeling
Continuous Validation & Assessment
Assessment Lifecycle
Security Maturity Framework
Quantitative Risk Assessment
Security Controls & Mitigations
Attack Tree Analysis
🔴 Priority Threat Scenarios
🛡️ STRIDE → Control Mapping
🏛️ Comprehensive Security Control Framework
🤖 OWASP LLM Top 10 (2025) — EP MCP Server Mapping
🔌 MCP-Protocol-Specific Threats
🏗️ Architecture-Aligned STRIDE — Per-Component Refresh
💰 Quantitative Risk Scoring — Top 7 Priority Scenarios
🔭 Detection Signatures — Per-Scenario Logging Indicators
🇪🇺 EU CRA Annex I Mapping
✍️ Residual-Risk Acceptance Log
Policy Alignment
Related Documents

🔐 ISMS Policy Alignment

Related ISMS Policies

Policy	Relevance	Link
Open Source Policy	Security transparency, vulnerability disclosure	View
Secure Development Policy	Secure coding practices, supply chain security	View
Risk Management Policy	Threat assessment, risk mitigation	View
Privacy Policy	GDPR compliance, data protection	View

Security Control Implementation Status

Control Area	Status	Evidence
Input Validation (Zod)	✅ Implemented	Mitigates E-1, D-4, E-3
Rate Limiting	✅ Implemented	Mitigates D-1, D-2
HTTPS/TLS	✅ Implemented	Default EP API base URL uses HTTPS; `EP_API_URL` must be configured with `https://` (Mitigates S-2, T-1)
SLSA Level 3	✅ Implemented	Mitigates T-3, S-4
Dependabot + npm audit	✅ Implemented	Mitigates T-2
Error Sanitization	⚠️ Partial	Mitigates I-1, I-2

Compliance Framework Mapping

Framework	Controls	Status
ISO 27001:2022	A.5.1, A.8.2, A.8.8, A.8.25, A.14.2, A.18.1	✅ Aligned
NIST CSF 2.0	ID.AM, ID.RA, PR.DS, PR.IP, DE.CM, RS.AN	✅ Aligned
CIS Controls v8.1	1.1, 2.7, 3.3, 6.2, 7.1, 16.7	✅ Aligned

See also: Policy Alignment below for the complete threat-specific ISMS policy mapping (Threat Modeling, Vulnerability Management, Network Security, Access Control, Cryptography, and Incident Response policies).

🗺️ Security Documentation Map

Document	Type	Description	Status
SECURITY_ARCHITECTURE.md	🛡️ Current	Implemented security design and controls	✅ Current
FUTURE_SECURITY_ARCHITECTURE.md	🚀 Future	Security roadmap and planned enhancements	✅ Current
THREAT_MODEL.md	🎯 Analysis	STRIDE threat analysis and risk assessment	✅ Current
FUTURE_THREAT_MODEL.md	🔮 Future	Threat analysis for planned architecture evolution	✅ Current
BCPPlan.md	🔄 Continuity	Business continuity and disaster recovery	✅ Current
CRA-ASSESSMENT.md	📋 Compliance	EU Cyber Resilience Act conformity assessment	✅ Current
SECURITY.md	📜 Policy	Security policy and vulnerability disclosure	✅ Current
SECURITY_HEADERS.md	🔒 Technical	API security headers implementation	✅ Current

🎯 Purpose & Scope

Establish a comprehensive threat model for the European Parliament MCP Server, a TypeScript/Node.js Model Context Protocol server providing AI assistants with structured access to European Parliament open datasets. This systematic threat analysis integrates multiple frameworks to ensure proactive security through structured analysis.

🌟 Transparency Commitment

This threat model demonstrates 🛡️ cybersecurity consulting expertise through public documentation of advanced threat assessment methodologies, showcasing our 🏆 competitive advantage via systematic risk management and 🤝 customer trust through transparent security practices.

— Based on Hack23 AB's commitment to security through transparency and excellence

📚 Framework Integration

🎭 STRIDE per architecture element: Systematic threat categorization
🎖️ MITRE ATT&CK mapping: Advanced threat intelligence integration
🏗️ Asset-centric analysis: Critical resource protection focus
🎯 Scenario-centric modeling: Real-world attack simulation
⚖️ Risk-centric assessment: Business impact quantification

🔍 Scope Definition

Included Systems:

🌐 TypeScript/Node.js MCP server application
🔌 MCP protocol implementation (stdio transport)
🏛️ European Parliament Open Data API integration
📦 npm package distribution (european-parliament-mcp-server)
🏭 CI/CD security pipeline (GitHub Actions, SLSA Level 3)
📦 Dependency supply chain (npm ecosystem)
✅ Input validation (Zod schemas)

Out of Scope:

European Parliament API infrastructure security
End-user AI assistant security (Claude, ChatGPT, etc.)
Third-party npm registry infrastructure
End-user operating system and network security

🔗 Policy Alignment

Integrated with 🎯 Hack23 AB Threat Modeling Policy methodology and frameworks.

🎯 Multi-Strategy Threat Modeling Integration

This threat model implements the five integrated threat modeling strategies mandated by Hack23 AB Threat Modeling Policy §4. Each strategy provides complementary perspectives to ensure comprehensive threat coverage for the European Parliament MCP Server.

mindmap
  root(("🎯 EP MCP Server<br/>Threat Modeling<br/>Strategies"))
    ("🎖️ Attacker-Centric")
      MITRE ATT&CK Mapping
      Kill Chain Analysis
      Threat Agent Classification
      Attack Tree Analysis
    ("🏗️ Asset-Centric")
      Crown Jewel Analysis
      Critical Asset Inventory
      Data Flow Threat Analysis
      GDPR Data Classification
    ("🏛️ Architecture-Centric")
      STRIDE per Component
      Trust Boundary Analysis
      Data Flow Diagrams
      Defense-in-Depth Layers
    ("🎯 Scenario-Centric")
      Parliamentary Data Manipulation
      MEP Personal Data Abuse
      Electoral Disinformation
      Supply Chain Compromise
      MCP Protocol Injection
    ("⚖️ Risk-Centric")
      Quantitative Risk Matrix
      Business Impact Analysis
      Likelihood Assessment
      Residual Risk Tracking

Strategy Integration Summary

Strategy	EP MCP Server Implementation	Key Sections
🎖️ Attacker-Centric	MITRE ATT&CK mapping (13 techniques), Kill Chain disruption, 5 threat agent profiles	ATT&CK Mapping, Kill Chain, Threat Agents
🏗️ Asset-Centric	6 critical assets, Crown Jewel analysis, protection strategies	Crown Jewels
🏛️ Architecture-Centric	STRIDE per 6 components (36 threat cells), trust boundary sequence diagram	Architecture STRIDE
🎯 Scenario-Centric	5 EP-specific attack scenarios with attack chains, detection, and response	Scenarios
⚖️ Risk-Centric	Quantitative risk matrix, priority risk ranking, residual risk assessment	Risk Assessment

📊 System Classification & Operating Profile

🏷️ Security Classification Matrix

Dimension	Level	Rationale	Business Impact
🔐 Confidentiality		Open source server processing public EP data
🔒 Integrity		Parliamentary data accuracy critical for democratic transparency
⚡ Availability		MCP server tolerates brief outages; AI clients retry

⚙️ Operating Profile

Property	Value
Runtime	Node.js 25+ (Current)
Language	TypeScript 6.0.2 (strict mode)
Transport	stdio (local process)
Data Source	European Parliament Open Data API
Distribution	npm registry
Authentication	None (public data, local stdio)
Users	AI assistants (Claude, ChatGPT, etc.)

💎 Critical Assets & Crown Jewel Analysis

🎯 Critical Asset Inventory

Asset	Description	Classification	Threat Impact
EP Parliamentary Data Integrity	Accuracy and trustworthiness of MEP data, voting records, plenary documents	🔒 Integrity: Moderate	Compromised democratic transparency, misinformation propagation
Source Code & Build Pipeline	TypeScript source, CI/CD workflows, GitHub Actions security	🔐 Confidentiality: Public 🔒 Integrity: High	Supply chain compromise, malicious code injection
Service Reputation & Trust	OpenSSF Scorecard rating, npm package legitimacy, security posture	⚡ Availability: Standard	User trust erosion, adoption reduction
EP API Access & Availability	Connection to European Parliament Open Data API	⚡ Availability: Moderate	Service disruption, rate limit exhaustion
npm Package Distribution	Package integrity, version control, download statistics	🔒 Integrity: Moderate	Malware distribution, user impact
Audit Trail & Logging	Structured logs, security event records	🔒 Integrity: Moderate	Non-repudiation loss, incident investigation failure

💎 Crown Jewel Analysis

mindmap
  root(("🏛️ EP MCP<br/>Crown Jewels"))
    🔒 EP Parliamentary<br/>Data Integrity
      Voting Records
      MEP Profiles
      Plenary Documents
      Committee Assignments
      GDPR Personal Data
    📦 Source Code &<br/>Build Pipeline
      TypeScript Source
      GitHub Actions
      SLSA L3 Provenance
      npm Publishing
      Dependency Chain
    🛡️ Service<br/>Reputation & Trust
      OpenSSF Score 9.4+
      Security Badges
      npm Download Stats
      Community Trust
      Transparent Security
    🌐 EP API Access &<br/>Availability
      Rate Limit Quota
      API Response Time
      Connection Integrity
      HTTPS/TLS Security
      Failover Strategy

🛡️ Crown Jewel Protection Strategies

Crown Jewel	Primary Threats	Protection Controls	Residual Risk
EP Parliamentary Data Integrity	T-1, T-2, S-2	HTTPS/TLS, response validation, Zod schemas, cache TTL	Low
Source Code & Build Pipeline	T-2, T-3, S-4	SLSA Level 3, branch protection, GPG signing, Dependabot	Low-Medium
Service Reputation & Trust	All categories	OpenSSF Scorecard monitoring, security badges, transparent documentation	Low
EP API Access & Availability	D-1, D-2, S-2	Rate limiting, retry logic, circuit breaker, HTTPS verification	Medium
npm Package Distribution	S-3, S-4, T-2	Official package name ownership, npm 2FA, SBOM, npm provenance	Low-Medium
Audit Trail & Logging	R-1, R-2, R-3	Structured stderr logging, immutable logs, timestamp integrity	Low

🎭 STRIDE Threat Analysis

S — Spoofing

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
S-1	Malicious MCP client impersonation	MCP Transport	Low	Medium	Low	stdio transport limits to local process
S-2	EP API response spoofing (MITM)	API Client	Low	High	Medium	HTTPS/TLS for all API communication
S-3	npm package name squatting	Distribution	Low	High	Medium	Official package name, npm 2FA publishing
S-4	Supply chain package substitution	Dependencies	Medium	High	High	SLSA Level 3 provenance, lockfile pinning

T — Tampering

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
T-1	API response manipulation	API Client	Low	High	Medium	HTTPS integrity, response validation
T-2	Dependency injection via compromised package	Supply Chain	Medium	Critical	High	Dependabot, npm audit, SBOM tracking
T-3	Build artifact tampering	CI/CD	Low	Critical	Medium	SLSA Level 3 attestations
T-4	Configuration manipulation	Runtime	Low	Medium	Low	Environment variable validation

R — Repudiation

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
R-1	Untracked tool invocations	MCP Server	Medium	Medium	Medium	Structured audit logging (stderr)
R-2	Unsigned commits in source	Source Code	Low	Medium	Low	GPG signing, branch protection
R-3	Unattributed data access	API Client	Low	Low	Low	Request logging with timestamps

I — Information Disclosure

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
I-1	Verbose error messages exposing internals	Error Handling	Medium	Medium	Medium	Sanitized error responses
I-2	Stack traces in production	Runtime	Medium	Low	Low	Production error handling
I-3	API keys in logs	Logging	Low	High	Medium	No API keys required (public API)
I-4	Sensitive data in cached responses	Caching	Low	Low	Low	Public data only, TTL-based cache

D — Denial of Service

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
D-1	EP API rate limit exhaustion	API Client	Medium	Medium	Medium	Client-side rate limiting
D-2	Memory exhaustion via large responses	Runtime	Low	High	Medium	Response size limits
D-3	Recursive/nested tool calls	MCP Server	Low	Medium	Low	Call depth limits
D-4	ReDoS via crafted input	Input Validation	Low	Medium	Low	Zod schema validation (no regex)

E — Elevation of Privilege

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
E-1	MCP tool parameter injection	Input Handling	Medium	Medium	Medium	Zod schema validation for all inputs
E-2	Prototype pollution via JSON parsing	Runtime	Low	High	Medium	Safe JSON parsing, TypeScript strict
E-3	Path traversal in document search	Tools	Low	Medium	Low	Input sanitization, no filesystem access
E-4	Command injection via tool parameters	MCP Server	Low	Critical	Medium	No shell execution, parameterized APIs

🤖 OWASP LLM Top 10 (2025) — EP MCP Server Mapping

This section maps the OWASP LLM Top 10 (2025) to the European Parliament MCP Server architecture, identifying applicable threats and gaps beyond traditional STRIDE analysis. Per the Hack23 OWASP LLM Security Policy, all MCP servers must assess LLM-specific attack vectors.

LLM Threat Matrix

LLM-ID	OWASP LLM Top 10 (2025)	Applicability to EP MCP	Threat IDs	Current Controls	Residual Risk
LLM01	Prompt Injection	⚠️ High Risk — Indirect prompt injection via EP API response payloads (e.g., malicious text in procedure titles, speech transcripts, committee reports that the host LLM treats as instructions: "Ignore previous instructions and...")	L-1 (new)	✅ Tool result schema documentation ℹ️ Zod validates structure only, NOT semantic content — injection payloads in valid string fields pass through unmodified ⚠️ Host-LLM responsibility (sanitize/sandbox tool-result text before treating as instructions) ⚠️ No server-side content sanitization (intentional: out-of-scope per MCP spec)	Medium (Host-LLM boundary defense required)
LLM02	Sensitive Information Disclosure	⚠️ Medium Risk — System-prompt or tool-schema leakage through verbose error messages, stack traces in production logs	I-1, I-2 (existing)	✅ Sanitized error responses ⚠️ Partial production log review ✅ No secrets in tool descriptions	Low (Partial mitigation via I-1/I-2)
LLM03	Supply Chain	⚠️ High Risk — Compromised npm dependencies containing LLM-targeted backdoors (e.g., AI-generated obfuscated malware)	T-2, S-4 (existing)	✅ Dependabot + SLSA Level 3 ✅ SBOM tracking ✅ npm audit + Snyk	Medium (Covered by existing T-2/S-4 controls)
LLM04	Data and Model Poisoning	❌ Not Applicable — EP MCP Server does not train or fine-tune models; consumes pre-trained host LLMs only	N/A	N/A	N/A
LLM05	Improper Output Handling	⚠️ Medium Risk — Host LLM rendering EP-sourced HTML/Markdown from tool results as instructions (e.g., malicious `<script>` in MEP bio, XSS in speech transcript)	L-2 (new)	⚠️ No server-side sanitization ✅ Public EP data only ⚠️ Host-LLM sanitization required	Low-Medium (Trust boundary at LLM client)
LLM06	Excessive Agency	⚠️ High Risk — Host LLM autonomously invoking high-volume tool chains (e.g., enumerating all 705 MEPs via `get_mep_details` in a loop) causing EP API quota exhaustion	L-3 (new)	✅ Token bucket rate limiter (100/min) ⚠️ No per-session limits ⚠️ No autonomous-agent detection	Medium (Rate limiting mitigates but not agent-aware)
LLM07	System Prompt Leakage	✅ Not Applicable — EP MCP Server has no system prompt; tool descriptions are public by design (open-source, MCP schema published)	N/A	N/A (intentional transparency)	N/A (Tool schemas are public API surface)
LLM08	Vector and Embedding Weaknesses	❌ Not Applicable — EP MCP Server does not implement vector databases, embeddings, or RAG pipelines	N/A	N/A	N/A
LLM09	Misinformation	⚠️ High Risk — Host LLM hallucinating around real EP data + cache staleness amplifying outdated voting records as "current" (e.g., 15-min cache TTL + EP API delay = stale plenary results presented as real-time)	L-4 (new)	✅ 15-min cache TTL ✅ EP API as source of truth ⚠️ No cache-age metadata in responses ⚠️ Host-LLM hallucination out of scope	Low-Medium (EP data accuracy trust boundary)
LLM10	Unbounded Consumption	⚠️ Medium Risk — Host LLM token-cost amplification (e.g., AI client invoking `get_all_generated_stats` returning 20k+ tokens → expensive LLM processing)	D-1, D-2 (existing) + L-5 (new, token-cost focus)	✅ Rate limiting (request-level) ⚠️ No response-size budgeting for LLM tokens ⚠️ No cost-estimation metadata	Low-Medium (Response-size limits mitigate but no token budgeting)

New LLM-Class Threat Definitions

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
L-1	Indirect Prompt Injection via EP API	Tool Results	Medium	High	High	Document trust boundary: tool results are untrusted data for host LLM; no server-side content filtering (out of scope); host-LLM sanitization required per OWASP LLM01
L-2	Improper Output Handling (HTML/Markdown Injection)	Tool Results	Low	Medium	Low-Medium	Public EP data only; XSS risk on host-LLM client (browser-based); server documents Markdown/HTML pass-through; host-client sanitization required
L-3	Excessive Agency (Autonomous Agent Abuse)	Rate Limiter	Medium	Medium	Medium	Token bucket (100/min) limits request rate; no per-session or per-agent quotas; future: adaptive rate limiting + agent fingerprinting
L-4	Misinformation via Cache Staleness	Cache Layer	Low	Medium	Low-Medium	15-min TTL balances freshness vs. EP API load; no cache-age metadata in responses; future: add `cacheAge` field to tool results
L-5	Unbounded Token-Cost Consumption	API Client	Low	Medium	Low-Medium	Response-size limits (10MB) mitigate bandwidth DoS; no LLM token-cost budgeting; future: add token-count estimates to tool schemas

OWASP LLM → ISMS Policy Alignment

OWASP LLM Risk	Hack23 ISMS Policy	Compliance Status
LLM01 Prompt Injection	OWASP LLM Security Policy §4.1 — Tool description hardening	✅ Documented trust boundary
LLM02 Info Disclosure	Information Security Policy §3.2 — Data classification	✅ Public data only (C: Public)
LLM03 Supply Chain	Secure Development Policy §5 — SLSA Level 3	✅ Full compliance
LLM05 Output Handling	OWASP LLM Security Policy §4.3 — Safe output encoding	⚠️ Host-LLM responsibility
LLM06 Excessive Agency	Access Control Policy §4 — Rate limiting	✅ Token bucket enforced
LLM09 Misinformation	Data Classification Policy §3 — Integrity (Moderate)	✅ EP API as source of truth
LLM10 Unbounded Consumption	Secure Development Policy §6.2 — DoS prevention	✅ Response-size limits

🔌 MCP-Protocol-Specific Threats (2025–2026 Research)

This section catalogs threats specific to the Model Context Protocol (MCP) based on 2025–2026 security research, beyond generic web/API vulnerabilities. Per Hack23 AI Policy §5 and OWASP LLM Security Policy, MCP servers must assess protocol-level attack vectors.

MCP Threat Catalog

ID	Threat	Component	Likelihood	Impact	Risk	Mitigation
M-1	Tool Poisoning (Malicious Tool Descriptions)	MCP Tool Schema	❌ N/A (first-party server)	N/A (hypothetical: Critical)	N/A	Not applicable: EP MCP Server is first-party (not third-party/untrusted). Tool descriptions authored in-repo, code-reviewed, signed via SLSA Level 3 provenance. Host-LLM trust boundary documented. Hypothetical impact shown in italics to indicate exposure if the threat were applicable (e.g., if a third party forked and republished the package).
M-2	Indirect Prompt Injection via Tool Results	Tool Result Payloads	Medium	High	Medium-High	EP API returns text containing "ignore previous instructions…" patterns → host-LLM treats as commands. Mitigation: Zod validates structure (not content); host-LLM responsibility per OWASP LLM01; server documents trust boundary; no server-side text sanitization (out of scope).
M-3	Rug-Pull Tool Re-Definition (npm Package Update)	npm Distribution	Low	Critical	Medium	npm package update silently changes tool semantics (e.g., `get_meps` → exfiltration). Mitigation: SemVer contract enforcement, CHANGELOG.md mandatory, SLSA provenance attestations, npm 2FA publishing, signed Git tags (GPG), community review window.
M-4	Confused-Deputy via MCP Gateway	Multi-Server Gateway	❌ N/A (stdio, no gateway)	N/A (hypothetical: High)	N/A	When used behind multi-server MCP gateway, requests from Client A conflated with Client B. Mitigation: Stateless server design (no per-client identity assumed), audit logger captures `sessionId` (future), stdio isolation (single-process). Future: add session-isolation guidance for gateway deployments.
M-5	Cross-Tool Data Leakage (Cache Pollution)	LRU Cache	Low	Medium	Low	Tool A's cached output influencing Tool B via shared cache namespace. Mitigation: Per-tool cache namespacing (`cacheKey = toolName:params`), LRU eviction policy, 15-min TTL prevents long-lived pollution, immutable cache entries.
M-6	Resource URI Scheme Abuse (Path Traversal)	MCP Resources	Low	Medium	Low	`ep://` resource URIs used to traverse outside intended scope (e.g., `ep://../../etc/passwd`). Mitigation: Zod-validated URI patterns (`ep://{entity}/{id}`), no filesystem-backed resources (all HTTP-only), explicit resource schema constraints.
M-7	Transport/Session ID Confusion	stdio Transport	❌ N/A (single-process stdio)	N/A (hypothetical: Medium)	N/A	stdio is single-process → inherently isolated. Future risk: HTTP/SSE transport (planned for v2.0) introduces session-management attack surface. Mitigation: Explicitly N/A for v1.x stdio; deferred to `FUTURE_THREAT_MODEL.md` for multi-session HTTP/SSE mode.

MCP Protocol Attack Vectors

Attack Vector	Description	EP MCP Server Exposure	Current Mitigation	Residual Risk
Malicious Tool Schema Injection	Attacker publishes MCP server with tool descriptions containing prompt-injection payloads	❌ Not Exposed — First-party server, not third-party marketplace	N/A (first-party trust model)	N/A
Tool Result Content Injection	Tool results contain adversarial text interpreted as instructions by host-LLM	✅ Exposed — EP API returns user-generated content (speech transcripts, procedure titles)	⚠️ Documented trust boundary; no server-side sanitization; host-LLM responsibility	Medium
Semantic Tool Redefinition	Package update changes tool behavior without schema change (e.g., `get_meps` → spy logic)	✅ Exposed — npm distribution model allows silent updates	✅ SemVer, CHANGELOG, SLSA attestations, community review	Low-Medium
MCP Gateway Confused-Deputy	Multi-server gateway routes request from Client A using identity/quota of Client B	❌ Not Exposed — stdio transport (no gateway)	N/A (stdio isolation)	N/A (future: document gateway security)
Cache Namespace Collision	Attacker crafts Tool A params to pollute Tool B's cache namespace	⚠️ Partially Exposed — Shared LRU cache across tools	✅ Per-tool namespacing, immutable entries, 15-min TTL	Low
Resource URI Directory Traversal	`ep://../../../sensitive` path traversal in resource URIs	⚠️ Theoretically Exposed — 9 `ep://` resources defined	✅ Zod URI validation, no filesystem access, HTTP-only resources	Low
Session Hijacking (HTTP/SSE)	Attacker steals session token for HTTP-based MCP transport	❌ Not Exposed — stdio only (no network transport)	N/A (stdio design)	N/A (future: v2.0 HTTP mode)

MCP-Specific ISMS Policy Alignment

MCP Threat	Hack23 ISMS Policy	Compliance Status
M-2 Indirect Prompt Injection	OWASP LLM Security Policy §4.1 — Tool result trust boundary	✅ Documented trust model
M-3 Rug-Pull Tool Redefinition	Secure Development Policy §5.3 — Supply chain integrity	✅ SLSA Level 3, SemVer, CHANGELOG
M-4 Confused-Deputy	Access Control Policy §3 — Session isolation	✅ stdio isolation (N/A for v1.x)
M-5 Cross-Tool Data Leakage	Data Classification Policy §4 — Data segregation	✅ Per-tool cache namespacing
M-6 Resource URI Abuse	Secure Development Policy §6.1 — Input validation	✅ Zod URI validation

🎖️ MITRE ATT&CK Coverage Analysis

ATT&CK Coverage Heat Map by Tactic

This heat map shows the relevance and coverage of MITRE ATT&CK tactics for the European Parliament MCP Server context. Each tactic is assessed for applicability and current security posture.

Tactic	Coverage Status	Relevant Techniques	Priority	Notes
🎯 Initial Access	🟢 High Coverage	T1190, T1195.002	🔴 Critical	Supply chain & MCP protocol entry points
⚡ Execution	🟡 Medium Coverage	T1059	🟠 High	Limited - no direct shell execution
🔄 Persistence	🟢 N/A (Not Applicable)	—	🟢 Low	Stateless MCP server, no persistence
🔺 Privilege Escalation	🟡 Medium Coverage	T1068	🟠 Medium	Prototype pollution, injection risks
🛡️ Defense Evasion	🟢 High Coverage	T1027, T1562	🟠 High	Obfuscated dependencies, log suppression
🔑 Credential Access	🟢 N/A (Not Applicable)	—	🟢 Low	No credentials stored/managed
🔍 Discovery	🟡 Medium Coverage	T1592	🟡 Medium	Information disclosure via errors
↔️ Lateral Movement	🟢 N/A (Not Applicable)	—	🟢 Low	Single-process stdio transport
📦 Collection	🟢 High Coverage	T1530	🟠 Medium	Parliamentary data harvesting abuse
📡 Command & Control	🟡 Medium Coverage	T1071	🟡 Medium	MCP protocol as C2 channel
📤 Exfiltration	🟢 High Coverage	T1041	🟠 High	Parliamentary data exfiltration
💥 Impact	🟢 High Coverage	T1498, T1485	🔴 Critical	DoS via rate exhaustion, data manipulation

Coverage Legend:

🟢 High Coverage: Comprehensive mitigations implemented
🟡 Medium Coverage: Partial mitigations, monitoring in place
🔴 Low Coverage: Minimal mitigations, requires attention
🟢 N/A: Tactic not applicable to this architecture

🏗️ Architecture-Centric STRIDE Analysis

🌊 Data Flow Threat Surface

sequenceDiagram
    participant AI as 🤖 AI Assistant<br/>(Claude/ChatGPT)
    participant MCP as 🔌 MCP Server<br/>(stdio transport)
    participant Cache as 💾 Cache Layer<br/>(LRU in-memory)
    participant RL as ⏱️ Rate Limiter<br/>(Token bucket)
    participant API as 🏛️ EP API<br/>(HTTPS)
    participant Log as 📋 Audit Logger<br/>(stderr)

    Note over AI,MCP: 🎭 S-1: MCP client spoofing<br/>🛡️ Mitigation: stdio isolation
    AI->>MCP: Tool call request (JSON-RPC)
    Note over MCP: 🎭 E-1: Parameter injection<br/>🛡️ Mitigation: Zod validation
    
    MCP->>Log: Log request (structured)
    Note over Log: 🎭 R-1: Non-repudiation<br/>🛡️ Mitigation: Immutable stderr
    
    MCP->>Cache: Check cache
    alt Cache Hit
        Cache-->>MCP: Cached data
        Note over Cache: 🎭 I-4: Stale data exposure<br/>🛡️ Mitigation: TTL expiration
    else Cache Miss
        MCP->>RL: Check rate limit
        Note over RL: 🎭 D-1: Rate exhaustion<br/>🛡️ Mitigation: Token bucket
        alt Rate OK
            RL-->>MCP: Allow
            Note over MCP,API: 🎭 S-2: MITM attack<br/>🛡️ Mitigation: HTTPS/TLS 1.3
            MCP->>API: GET /meps (HTTPS)
            Note over API: 🎭 T-1: Response tampering<br/>🛡️ Mitigation: TLS integrity
            API-->>MCP: JSON response
            MCP->>MCP: Validate response (Zod)
            Note over MCP: 🎭 E-2: Prototype pollution<br/>🛡️ Mitigation: TypeScript strict
            MCP->>Cache: Store response
        else Rate Exceeded
            RL-->>MCP: Deny
            Note over MCP: 🎭 D-1: DoS protection<br/>✅ Request rejected
        end
    end
    
    Note over MCP: 🎭 I-1: Error info leak<br/>🛡️ Mitigation: Sanitized errors
    MCP-->>AI: Tool response
    MCP->>Log: Log response (structured)

🔍 STRIDE per Component Analysis

Component 1: MCP Server Core (Tool Dispatcher & Request Handler)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	Client impersonation through stdio hijacking	Malicious process capturing stdio streams	stdio transport limits to parent process	✅ Inherent
T	Tool invocation manipulation	Modified JSON-RPC request parameters	Zod schema validation on all inputs	✅ Active
R	Untracked tool calls	Missing audit trail for debugging	Structured stderr logging (JSON format)	✅ Active
I	Stack trace exposure in errors	Production error messages revealing code structure	Sanitized error responses to AI client	⚠️ Partial
D	Recursive tool calls causing OOM	AI assistant invoking tools in infinite loop	Call depth tracking, memory monitoring	⚠️ Future
E	JSON-RPC protocol exploitation	Crafted JSON-RPC bypassing validation	TypeScript strict mode, Zod schemas	✅ Active

Component 2: EP API Client (HTTP Client & Response Parser)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	EP API response spoofing	MITM attacker injecting false EP data	HTTPS/TLS 1.3 with certificate validation	✅ Active
T	API response manipulation	TLS downgrade or compromised proxy	Strict TLS configuration, no HTTP fallback	✅ Active
R	Unlogged API requests	Missing request/response audit trail	Structured logging for all API interactions	✅ Active
I	API error details in client logs	EP API returning sensitive error messages	Sanitize EP API errors before logging	⚠️ Partial
D	API rate limit exhaustion	Excessive requests overwhelming EP API	Client-side rate limiting (token bucket)	✅ Active
E	Malicious redirect exploitation	EP API sending redirect to attacker domain	No automatic redirects, validate URLs	✅ Active

Component 3: Cache Layer (In-Memory LRU Cache)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	Cache poisoning with fake data	Attacker injecting malicious cache entries	Cache only validated API responses	✅ Active
T	Cached data tampering	Memory corruption or external modification	Immutable cache entries, process isolation	✅ Inherent
R	Cache operations not logged	Missing visibility into cache hits/misses	Cache statistics in audit logs	⚠️ Future
I	Sensitive data in cache dumps	Memory dumps exposing cached MEP data	Public data only, no PII in cache keys	✅ Inherent
D	Memory exhaustion via cache growth	Unbounded cache causing OOM	LRU eviction policy, max size limit	✅ Active
E	Cache timing attacks	Inferring data presence via response time	Constant-time cache lookups (not security critical)	❌ Accepted

Component 4: Rate Limiter (Token Bucket Algorithm)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	Rate limit bypass	Attacker spoofing source to reset limits	Process-level rate limiting (stdio isolation)	✅ Inherent
T	Rate limit configuration tampering	Modified rate limits allowing excess requests	Immutable configuration, validated env vars	✅ Active
R	Rate limit violations unlogged	Missing audit trail for throttling events	Log all rate limit denials with timestamps	✅ Active
I	Rate limit details exposure	Attacker learning rate limits via probing	No rate limit details in error messages	✅ Active
D	Rate limiter resource exhaustion	Token bucket state consuming excessive memory	Fixed-size token bucket, constant memory	✅ Active
E	Race condition in rate checks	Concurrent requests bypassing rate limits	Atomic token bucket operations	✅ Active

Component 5: Audit Logger (Structured stderr Logging)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	Log injection attacks	Attacker injecting fake log entries via user input	Structured JSON logging, no string interpolation	✅ Active
T	Log tampering	Attacker modifying stderr logs post-facto	Immutable stderr stream, external log aggregation	✅ Recommended
R	Log repudiation	Attacker denying logged actions	Timestamps (ISO 8601), request IDs, immutable stderr	✅ Active
I	Sensitive data in logs	PII or credentials logged inadvertently	Sanitize user input, no API keys (public API)	✅ Active
D	Log flooding DoS	Excessive logging consuming disk/bandwidth	Rate limit log output, log level filtering	⚠️ Future
E	Log analysis exploitation	Attacker using logs to map system internals	Generic log messages, no internal implementation details	⚠️ Partial

Component 6: npm Package Distribution (package.json & dist/)

STRIDE	Threat	Attack Vector	Mitigation	Status
S	npm package name squatting	Attacker publishing `european-parliament-server` (typo)	Official `european-parliament-mcp-server` package name ownership, npm 2FA-protected publisher account	✅ Active
T	Build artifact injection	Malicious code in `dist/` not matching source	SLSA Level 3 provenance, reproducible builds	✅ Active
R	Unsigned package versions	Unverifiable package authorship	npm provenance attestations, 2FA publishing	✅ Active
I	Source code exposure (non-issue)	Full source code visible in npm package	Intentional: open source transparency	✅ Accepted
D	npm registry DoS	npm registry unavailable during installation	Use npm mirrors, cache dependencies locally	❌ External
E	Dependency confusion attack	Internal package name colliding with public npm	No private dependencies, unique public package names	✅ Inherent

🏗️ Architecture-Aligned STRIDE — Per-Component Refresh

This section provides a component-by-component STRIDE refresh aligned with the C4 Component Diagram in ARCHITECTURE.md. Each row represents a concrete architectural component from the src/ codebase, cross-referenced to existing STRIDE threat IDs.

EP Sub-Clients (9 Components)

Component	Spoofing	Tampering	Repudiation	Info Disc	DoS	EoP	Linked IDs
`baseClient.ts`	Adequate (S-2: HTTPS/TLS)	Adequate (T-1: TLS integrity)	Adequate (R-3: logged)	Adequate (I-3: no keys)	Adequate (D-1: rate limited)	Adequate (E-1: Zod)	S-2, T-1, R-3, I-3, D-1, E-1
`mepClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Partial (I-1: MEP PII in errors)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-1, D-1, E-1
`plenaryClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4: public data)	Adequate (D-1, D-2: size limits)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, D-2, E-1
`documentClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-2: 10MB limit)	Adequate (E-1, E-3: no path traversal)	S-2, T-1, R-3, I-4, D-2, E-1, E-3
`legislativeClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, E-1
`committeeClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, E-1
`questionClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, E-1
`votingClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, E-1
`vocabularyClient.ts`	Adequate (S-2)	Adequate (T-1)	Adequate (R-3)	Adequate (I-4)	Adequate (D-1)	Adequate (E-1)	S-2, T-1, R-3, I-4, D-1, E-1

Core Infrastructure Components

Component	Spoofing	Tampering	Repudiation	Info Disc	DoS	EoP	Linked IDs
DI Container (`src/di/`)	N/A (internal)	Adequate (T-4: validated config)	N/A	Adequate (I-2: no secrets)	N/A	Adequate (E-2: TypeScript strict)	T-4, I-2, E-2
MetricResult Wrapper	N/A	N/A	Adequate (R-1: logged)	Adequate (I-1: sanitized)	N/A	N/A	R-1, I-1
Branded Types (Zod)	N/A	Adequate (T-1: validated)	N/A	N/A	Adequate (D-4: no ReDoS)	Adequate (E-1: strict schemas)	T-1, D-4, E-1
LruCache (`src/cache/`)	N/A	Adequate (immutable entries)	Partial (R-1: cache ops not logged)	Adequate (I-4: public data)	Adequate (D-2: max size)	N/A	R-1, I-4, D-2
RateLimiter (`src/utils/rateLimiter.ts`)	Adequate (S-1: stdio isolation)	Adequate (T-4: immutable config)	Adequate (R-1: violations logged)	Adequate (I-1: no details in errors)	Adequate (D-1: token bucket)	Adequate (E-1: atomic ops)	S-1, T-4, R-1, I-1, D-1, E-1
AuditSink (`src/utils/auditLogger.ts`)	Adequate (S-1: stderr isolation)	Adequate (immutable stderr)	Adequate (R-1: ISO 8601 timestamps)	Partial (I-1: PII sanitization)	Partial (future: log flooding)	Adequate (E-1: structured JSON)	S-1, R-1, I-1, E-1

Coverage Summary

STRIDE Category	Components w/ Adequate Coverage	Components w/ Partial Coverage	Components w/ N/A
Spoofing	11/15 (73%)	0	4 (internal-only)
Tampering	13/15 (87%)	0	2
Repudiation	11/15 (73%)	2 (cache ops, log flooding)	2
Info Disclosure	13/15 (87%)	2 (MEP PII in errors, PII sanitization)	0
DoS	12/15 (80%)	1 (log flooding)	2
EoP	13/15 (87%)	0	2

Key Gaps:

Repudiation (Partial): LRU cache operations (hits/misses) not logged → future MetricsService integration
Info Disclosure (Partial): MEP personal data in error messages (I-1) → enhanced error sanitization
DoS (Partial): No log-flooding protection → future rate limiting for audit events

🎖️ MITRE ATT&CK Mapping

ATT&CK → Security Control Mitigation Mapping

Comprehensive mapping of MITRE ATT&CK techniques to implemented security controls for the European Parliament MCP Server.

Technique ID	Technique Name	Security Control	Implementation	Effectiveness
T1195.002	Supply Chain Compromise: Software Supply Chain	Dependabot + SLSA Level 3 + SBOM	Automated vulnerability scanning, provenance attestations, CycloneDX SBOM generation	🟢 High (95%)
T1059	Command and Scripting Interpreter	No shell execution policy	TypeScript/Node.js without child_process, strict input validation	🟢 High (98%)
T1190	Exploit Public-Facing Application	Zod schema validation + rate limiting	Strict input validation for all MCP tool parameters, client-side rate limits	🟢 High (90%)
T1557	Adversary-in-the-Middle	HTTPS/TLS 1.3 for EP API	Enforced TLS for all EP API requests, certificate validation	🟢 High (95%)
T1498	Network Denial of Service	Rate limiting + response size limits	Client-side rate limiter, 10MB response cap, timeout controls	🟡 Medium (75%)
T1027	Obfuscated Files or Information	SLSA provenance + npm audit	Build attestations, integrity verification, transparency logs	🟢 High (85%)
T1071	Application Layer Protocol	stdio transport isolation	MCP protocol limited to stdio, no network exposure	🟢 High (90%)
T1592	Gather Victim Host Information	Error sanitization + structured logging	Production error handlers, no stack traces to clients	🟡 Medium (70%)
T1068	Exploitation for Privilege Escalation	TypeScript strict mode + safe JSON parsing	Prototype pollution prevention, type safety	🟢 High (85%)
T1562	Impair Defenses	Immutable logging + monitoring	Audit logs via stderr, OpenSSF Scorecard monitoring	🟢 High (80%)
T1530	Data from Cloud Storage Object	Rate limiting + usage analytics	Monitor bulk data requests, pattern-based anomaly detection	🟡 Medium (65%)
T1041	Exfiltration Over C2 Channel	stdio isolation + data flow monitoring	No outbound network from MCP server, logging all tool invocations	🟢 High (80%)
T1485	Data Destruction	Integrity validation + EP API trust	Response validation against expected schemas, EP API as source of truth	🟡 Medium (70%)

Effectiveness Scale:

🟢 High (>80%): Control effectively mitigates technique
🟡 Medium (60-80%): Partial mitigation, residual risk remains
🔴 Low (<60%): Limited mitigation, requires enhancement

ATT&CK Navigator Visualization

To visualize this threat landscape comprehensively, the European Parliament MCP Server team maintains an ATT&CK Navigator layer with:

Highlighted techniques: All 13 relevant techniques color-coded by coverage
Metadata annotations: Links to STRIDE threat IDs and security controls
Score-based heatmap: Effectiveness ratings (0-100) for each technique
Filter views: Supply Chain, MCP Protocol, API Layer, Runtime

📊 ATT&CK Navigator Layer JSON: The layer JSON is a planned deliverable and will be added in a future release under a docs/threat-model/ directory once the visualization is finalized; it is not yet available in this repository.

🔗 Online Visualization: Use MITRE ATT&CK Navigator to load the layer JSON for interactive exploration.

Recommendation: Review this mapping quarterly and after major architecture changes to ensure continued alignment with evolving threat intelligence.

🔗 Kill Chain Disruption Analysis

This section maps the Cyber Kill Chain phases to the EP MCP Server's defensive controls and detection capabilities, as required by Hack23 AB Threat Modeling Policy §4.1. Each phase identifies how an attacker progresses and where our controls disrupt the chain.

Kill Chain Phase → Defensive Control → Detection Mapping

Kill Chain Phase	Attack Activity (EP MCP Context)	Defensive Controls	Detection Mechanisms	Disruption Effectiveness
1️⃣ Reconnaissance	Attacker probes MCP tool schemas, EP API endpoints, npm package metadata, GitHub repo structure	• Public data only (no sensitive info to discover) • Generic error messages (I-1 mitigation) • No version info in runtime errors	• GitHub traffic analytics • npm download pattern monitoring • Unusual MCP tool enumeration logging	🟡 Medium — Public project limits reconnaissance value
2️⃣ Weaponization	Attacker crafts malicious npm package, prepares prototype pollution payload, or creates typosquatting package	• SLSA Level 3 provenance verification • Package-lock.json integrity • No private dependencies	• Dependabot new vulnerability alerts • npm audit CI/CD gate • OpenSSF Scorecard monitoring	🟢 High — Supply chain controls are comprehensive
3️⃣ Delivery	Attacker publishes compromised dependency, sends phishing to maintainer, or submits malicious PR	• npm 2FA required for publishing • Branch protection rules • CODEOWNERS enforcement • GPG commit signing	• GitHub security alerts • PR review requirements • npm provenance verification • Snyk continuous monitoring	🟢 High — Multi-layer delivery prevention
4️⃣ Exploitation	Attacker exploits Zod validation bypass, prototype pollution, or MCP parameter injection	• Zod schema validation on all inputs (E-1) • TypeScript strict mode (E-2) • No shell execution (E-4) • Safe JSON parsing	• Zod validation error logging • TypeScript type check failures • Runtime exception monitoring • stderr audit logs	🟢 High — Defense-in-depth input validation
5️⃣ Installation	Attacker attempts persistence via modified cache entries, altered build artifacts, or backdoored dependency	• Stateless MCP server (no persistence) • Immutable cache entries • SLSA build attestations • Process isolation (stdio)	• SLSA provenance signature mismatch • Build artifact hash verification • npm package content diff	🟢 High — Stateless architecture prevents installation
6️⃣ Command & Control	Attacker uses compromised MCP server to exfiltrate data or inject false responses to AI assistants	• stdio transport isolation (no network) • No outbound connections from MCP server • Rate limiting on all tool calls	• Audit logging of all tool invocations • Response size anomaly detection • Data flow monitoring	🟢 High — stdio isolation prevents C2 channels
7️⃣ Actions on Objectives	Attacker manipulates parliamentary data, harvests MEP data, or disrupts service availability	• EP API as source of truth (integrity) • Response validation via Zod • Rate limiting prevents bulk harvesting • GDPR-aware data minimization	• Data integrity checks against EP API • Bulk access pattern detection • Rate limit violation alerts • OpenSSF Scorecard degradation	🟡 Medium — Continuous monitoring required

Kill Chain Disruption Visualization

graph LR
    R["1️⃣ Recon"] -->|Public project| W["2️⃣ Weaponize"]
    W -->|Supply chain| D["3️⃣ Deliver"]
    D -->|Malicious code| E["4️⃣ Exploit"]
    E -->|Code execution| I["5️⃣ Install"]
    I -->|Persistence| C["6️⃣ C2"]
    C -->|Control| A["7️⃣ Actions"]

    R -.->|🛡️ Generic errors| RD[Disrupted]
    W -.->|🛡️ SLSA + Dependabot| WD[Disrupted]
    D -.->|🛡️ 2FA + Branch protection| DD[Disrupted]
    E -.->|🛡️ Zod + TypeScript strict| ED[Disrupted]
    I -.->|🛡️ Stateless architecture| ID[Disrupted]
    C -.->|🛡️ stdio isolation| CD[Disrupted]
    A -.->|🛡️ EP API integrity| AD[Monitored]

    style RD fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style WD fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style DD fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ED fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ID fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style CD fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style AD fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f

Key Insight: The EP MCP Server's stateless stdio architecture provides inherent disruption at Kill Chain phases 5 (Installation) and 6 (C2), while SLSA Level 3 + Dependabot provide strong disruption at phases 2-3. The primary residual risk is at phase 7 (Actions on Objectives) where continuous monitoring is essential.

👥 Threat Agent Classification

Understanding potential adversaries is critical for proportionate security investment. This section profiles threat actors relevant to the European Parliament MCP Server based on motivation, capability, and likely attack vectors.

Nation-State Actors

Profile:

🎯 Motivation: Intelligence gathering on European parliamentary activities, electoral interference, political influence operations
💪 Capability Level: 🔴 Advanced (Nation-State Resources)
- Sophisticated supply chain attacks (e.g., SolarWinds-style compromise)
- Zero-day exploits in Node.js/TypeScript ecosystem
- Advanced persistent threats (APT) with long-term objectives
🎭 Likely Tactics:
- T1195.002: Supply chain compromise of npm dependencies
- T1557: MITM attacks on EP API communications
- T1530: Systematic harvesting of MEP voting patterns and committee data
🔴 Priority: High — Due to potential for sophisticated, persistent attacks
🛡️ Mitigation Focus: SLSA Level 3 provenance, dependency integrity, EP API transport security

Hacktivist Groups

Profile:

🎯 Motivation: Political activism, transparency advocacy, anti-establishment campaigns, public disclosure of parliamentary data
💪 Capability Level: 🟡 Intermediate (Skilled Individuals/Small Teams)
- Script-based attacks, publicly available exploit tools
- Social engineering of developers and contributors
- Website defacement, data leaks for publicity
🎭 Likely Tactics:
- T1190: Exploit MCP tool parameter injection vulnerabilities
- T1498: DDoS via API rate exhaustion
- T1485: Data manipulation to spread disinformation
🟠 Priority: Medium — Capable of opportunistic attacks but limited persistence
🛡️ Mitigation Focus: Input validation (Zod schemas), rate limiting, public vulnerability disclosure program

Insider Threats (Supply Chain)

Profile:

🎯 Motivation: Compromised developer account, malicious open-source contributor, disgruntled maintainer
💪 Capability Level: 🟠 High (Trusted Access)
- Direct commit access or pull request approval
- Knowledge of codebase internals and security controls
- Ability to introduce subtle vulnerabilities
🎭 Likely Tactics:
- T1195.002: Malicious dependency substitution or backdoor insertion
- T1027: Obfuscated malicious code in commits
- T1562: Disabling security controls (e.g., test bypasses)
🔴 Priority: High — Trusted position enables high-impact attacks
🛡️ Mitigation Focus: Branch protection, mandatory code review, GPG commit signing, SLSA attestations

Automated Threat Actors (Bots/Scrapers)

Profile:

🎯 Motivation: Bulk data harvesting, API abuse for commercial purposes, training dataset collection for AI models
💪 Capability Level: 🟢 Low (Automated Scripts)
- Mass automated requests via compromised MCP clients
- Simple evasion techniques (rotating IPs, user agents)
- No sophisticated exploit capability
🎭 Likely Tactics:
- T1498: API rate limit exhaustion via distributed requests
- T1530: Bulk collection of parliamentary datasets
- T1071: Abuse of MCP protocol for unauthorized access
🟡 Priority: Medium — High volume but low sophistication
🛡️ Mitigation Focus: Client-side rate limiting, usage analytics, anomaly detection

Competitor/Espionage Actors

Profile:

🎯 Motivation: Commercial intelligence gathering, competitive advantage in political consulting, lobbying intelligence
💪 Capability Level: 🟡 Intermediate to High
- Funded operations with technical capabilities
- Targeted attacks on specific MEP data or committee information
- Long-term systematic data collection
🎭 Likely Tactics:
- T1530: Systematic harvesting of EP voting records and attendance data
- T1592: Reconnaissance via error message analysis
- T1041: Exfiltration of aggregated parliamentary intelligence
🟠 Priority: Medium — Targeted but not infrastructure-destructive
🛡️ Mitigation Focus: Audit logging, data access pattern monitoring, request attribution

Threat Actor Priority Matrix

%%{init: {
  "theme": "dark",
  "themeVariables": {
    "quadrant1Fill": "#d32f2f",
    "quadrant2Fill": "#ff9800",
    "quadrant3Fill": "#4caf50",
    "quadrant4Fill": "#1565c0",
    "quadrantTitleFill": "#ffffff",
    "quadrantPointFill": "#ffffff",
    "quadrantPointTextFill": "#ffffff",
    "quadrantXAxisTextFill": "#ffffff",
    "quadrantYAxisTextFill": "#ffffff"
  },
  "quadrantChart": {
    "chartWidth": 700,
    "chartHeight": 700,
    "pointLabelFontSize": 12,
    "titleFontSize": 20,
    "quadrantLabelFontSize": 16,
    "xAxisLabelFontSize": 14,
    "yAxisLabelFontSize": 14
  }
}}%%
quadrantChart
    title 🎯 Threat Actor Assessment — Capability vs Motivation
    x-axis Low Motivation --> High Motivation
    y-axis Low Capability --> High Capability
    quadrant-1 CRITICAL THREATS
    quadrant-2 HIGH-RISK ACTORS
    quadrant-3 OPPORTUNISTIC
    quadrant-4 PERSISTENT
    "🏴 Nation-State APT": [0.9, 0.95]
    "👤 Insider Threat": [0.7, 0.85]
    "💻 Hacktivist Groups": [0.8, 0.5]
    "🕵️ Competitor Espionage": [0.65, 0.6]
    "🤖 Automated Bots": [0.4, 0.2]

Action Items by Actor:

Nation-State: Focus on supply chain integrity (SLSA Level 3, SBOM)
Hacktivist: Strengthen input validation and public-facing security
Insider Threat: Enforce code review, branch protection, audit trails
Automated Bots: Implement robust rate limiting and anomaly detection
Competitor: Monitor data access patterns, enhance logging

🌐 Current Threat Landscape

The European Parliament MCP Server operates within a dynamic threat environment shaped by geopolitical tensions, evolving attack techniques, and the strategic importance of parliamentary data. This section integrates ENISA Threat Landscape 2024 findings with EP-specific context.

ENISA Threat Landscape 2024 — Top Threats Mapped to EP MCP Server

ENISA Threat	Relevance to EP MCP Server	Current Posture	Priority
🔒 Ransomware	Low direct risk (no data persistence), but supply chain ransomware targeting npm dependencies could encrypt developer workstations	🟢 Mitigated via SLSA Level 3, no critical data storage	🟡 Medium
🦠 Malware	High risk: Malicious npm packages in dependency tree (e.g., typosquatting, compromised maintainer accounts)	🟢 Mitigated via Dependabot, npm audit, OpenSSF Scorecard	🔴 High
🎣 Social Engineering	Developer phishing/account takeover to inject malicious code or publish compromised npm versions	🟡 Partial mitigation via 2FA, GPG signing	🔴 High
💾 Data Breaches	Parliamentary data integrity breach: Manipulation of EP voting records, MEP personal data exposure (GDPR violation)	🟡 Partial mitigation via HTTPS, response validation	🟠 Medium-High
☁️ DDoS	API exhaustion attacks targeting EP Open Data API via MCP server abuse	🟢 Mitigated via client-side rate limiting	🟡 Medium
📰 Disinformation	Data manipulation via compromised MCP server: False parliamentary data fed to AI assistants, influencing political analysis	🟡 Partial mitigation via integrity checks	🔴 High
⛓️ Supply Chain Attacks	Primary threat vector: Compromised npm packages, malicious CI/CD pipeline modifications, SLSA bypass attempts	🟢 Strong mitigation via SLSA Level 3, SBOM, Dependabot	🔴 Critical

EU Cyber Resilience Act (CRA) Context

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) imposes mandatory cybersecurity requirements for products with digital elements. The EP MCP Server, as an open-source component with parliamentary data access, falls under CRA scope:

📋 Vulnerability Disclosure: Mandatory 24-hour reporting of actively exploited vulnerabilities to ENISA
📦 SBOM Requirements: CycloneDX SBOM generation already implemented
🔄 Security Updates: Commitment to timely patching (currently: critical <7 days, high <30 days)
🛡️ Default Security: Secure-by-default configuration (no hardcoded credentials, HTTPS enforcement)

CRA Compliance Status: ✅ Conforming — See CRA-ASSESSMENT.md for detailed analysis

Parliamentary Data Threat Context

The strategic value of European Parliament data creates unique threat scenarios:

Electoral Interference (Nation-State):
- Threat: Manipulation of MEP voting records before elections to influence public perception
- Attack Vector: Compromised MCP server returning altered roll-call vote data
- Impact: Democratic integrity, electoral outcomes
- Mitigation: EP API as single source of truth, response integrity validation
GDPR-Protected MEP Data (Privacy Activists/Competitors):
- Threat: Bulk harvesting of MEP personal contact data, office locations, parliamentary group affiliations
- Attack Vector: Automated MCP tool invocations to systematically collect MEP biographical data
- Impact: GDPR Article 6 violation, privacy breach, potential harassment campaigns
- Mitigation: Rate limiting, usage pattern monitoring, public data scope limitation
Policy Intelligence (Lobbying/Espionage):
- Threat: Systematic collection of committee votes, amendments, and parliamentary questions for competitive intelligence
- Attack Vector: Long-term MCP server abuse by competitor AI assistants
- Impact: Unfair commercial advantage, policy prediction, lobbying strategy
- Mitigation: Audit logging, anomaly detection, transparency about data sources

Emerging Threat Vectors (2024-2025)

Threat	Description	Likelihood	Impact
AI-Powered Supply Chain Attacks	LLMs used to generate sophisticated obfuscated malware in npm packages	🟡 Medium	🔴 Critical
MCP Protocol Exploitation	Novel attacks targeting MCP stdio transport or tool parameter parsing	🟡 Medium	🟠 High
Dependency Confusion 2.0	Advanced typosquatting using AI-generated package names similar to `european-parliament-mcp-server`	🟡 Medium	🟠 High
Deepfake Parliamentary Data	AI-generated false EP datasets indistinguishable from legitimate data	🟢 Low	🔴 Critical
Quantum-Resistant Cryptography Pressure	Future requirement to migrate TLS to post-quantum algorithms	🟢 Low (2025+)	🟠 Medium

🎬 Scenario-Centric Threat Modeling (EP-Specific)

This section applies scenario-based threat modeling to European Parliament-specific attack chains, providing actionable detection and response strategies.

Scenario 1: Parliamentary Data Manipulation Attack

🎯 Attack Objective: Manipulate voting record data returned by MCP server to influence AI-assisted political analysis

🎭 Threat Actor: Nation-state actor or hacktivist group

📊 Attack Chain:

graph LR
    A["1️⃣ Compromise npm dependency"] --> B["2️⃣ Inject response manipulation code"]
    B --> C["3️⃣ MCP server returns altered vote data"]
    C --> D["4️⃣ AI assistant provides false analysis"]
    D --> E["5️⃣ Political decisions based on false data"]
    
    style A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style D fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

Attack Steps:

Initial Compromise: Attacker exploits vulnerability in transitive npm dependency (e.g., malicious lodash substitute)
Code Injection: Malicious code intercepts the get_voting_records MCP tool
Data Manipulation: Alters vote outcomes (e.g., changes "Against" to "For" for specific MEPs)
Propagation: AI assistant uses corrupted data to generate policy analysis
Impact: Political decisions, news articles, or research based on false parliamentary data

🔍 Detection Indicators:

✅ SLSA provenance verification failure
✅ npm audit alerts on compromised dependency
✅ Anomalous response size or schema validation errors
✅ OpenSSF Scorecard supply chain score degradation

🛡️ Response Actions:

Immediate: Quarantine affected npm package version
Containment: Revert to last known-good dependency lockfile
Investigation: Audit all tool invocations during compromise window
Recovery: Publish security advisory, coordinate with npm security team
Prevention: Enhance SBOM monitoring, implement runtime integrity checks

📉 Risk Score: 🔴 Critical (9.0/10) — High impact on democratic integrity

Scenario 2: MEP Personal Data Abuse (GDPR Violation)

🎯 Attack Objective: Unauthorized bulk harvesting of MEP contact and personal data for commercial or political purposes

🎭 Threat Actor: Competitor intelligence firm or automated bot network

📊 Attack Chain:

graph LR
    A["1️⃣ Automated MCP client"] --> B["2️⃣ Systematic MEP data queries"]
    B --> C["3️⃣ Bulk export of GDPR-protected data"]
    C --> D["4️⃣ Commercial database sale"]
    D --> E["5️⃣ GDPR Article 6 violation"]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style C fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

Attack Steps:

Reconnaissance: Attacker identifies MCP tools get_meps and get_mep_details for biographical data (using get_meps to enumerate MEPs and get_mep_details to retrieve full profiles)
Automation: Script iterates through all 705 MEPs to harvest contact details, office locations, party affiliations
Exfiltration: Bulk collection of GDPR Article 9 special category data (political opinions)
Monetization: Sells MEP database to lobbying firms or political campaigns
Legal Impact: GDPR fine up to €20M or 4% of global turnover

🔍 Detection Indicators:

✅ Rate limiting threshold exceeded (>100 requests/hour)
✅ Sequential MEP ID enumeration pattern detected
✅ Bulk data access from single IP/client
✅ Unusual off-hours usage patterns

🛡️ Response Actions:

Immediate: Throttle client rate limits to 10 requests/minute
Containment: Implement CAPTCHA-style challenge for bulk requests
Investigation: Audit logs to identify compromised client identity
Recovery: Notify EP data protection officer, potential GDPR Article 33 notification
Prevention: Implement data minimization (limit biographical data scope)

📉 Risk Score: 🟠 High (7.5/10) — GDPR violation with significant financial penalties

Scenario 3: Electoral Influence via AI-Assisted Disinformation

🎯 Attack Objective: Compromise MCP server to feed false parliamentary data to AI assistants used by journalists and researchers

🎭 Threat Actor: Nation-state APT targeting EU elections

📊 Attack Chain:

graph LR
    A["1️⃣ Supply chain compromise"] --> B["2️⃣ Inject disinformation logic"]
    B --> C["3️⃣ AI assistants use false data"]
    C --> D["4️⃣ News articles published"]
    D --> E["5️⃣ Electoral influence achieved"]
    
    style A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

Attack Steps:

Pre-Election Timing: 3 months before EU parliamentary elections, attacker compromises MCP server
Targeted Manipulation: Alters voting records for specific MEPs in swing districts
AI Propagation: Journalists using AI assistants (Claude, ChatGPT) cite false data
Media Amplification: News articles report fabricated voting patterns
Electoral Impact: Public perception shift influences voting behavior

🔍 Detection Indicators:

✅ Discrepancy between EP official portal and MCP server responses
✅ SLSA provenance verification failures
✅ Community reports of data inconsistencies
✅ Anomalous build artifacts in npm package

🛡️ Response Actions:

Immediate: Emergency npm package deprecation + public security advisory
Containment: Direct users to EP official API as alternative
Investigation: Forensic analysis of compromised build pipeline
Recovery: Restore from verified clean state, republish with enhanced attestations
Prevention: Implement EP API response checksums, real-time integrity monitoring

📉 Risk Score: 🔴 Critical (9.5/10) — Democratic process integrity threat

Scenario 4: Supply Chain Compromise of npm Package

🎯 Attack Objective: Publish malicious version of european-parliament-mcp-server to npm registry

🎭 Threat Actor: Insider threat (compromised maintainer account)

📊 Attack Chain:

graph LR
    A["1️⃣ Maintainer account phishing"] --> B["2️⃣ 2FA bypass via session hijacking"]
    B --> C["3️⃣ Malicious npm publish"]
    C --> D["4️⃣ Automatic updates infect users"]
    D --> E["5️⃣ Widespread MCP server compromise"]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

Attack Steps:

Social Engineering: Attacker sends targeted phishing email to npm package maintainer
Account Takeover: Bypasses 2FA via browser session cookie theft
Malicious Publish: Publishes european-parliament-mcp-server@3.1.4 with backdoor
Auto-Update: Users with ^3.1.0 in package.json automatically pull malicious version
Backdoor Activation: Malware exfiltrates API keys or injects false data

🔍 Detection Indicators:

✅ SLSA provenance signature mismatch
✅ npm package version published without corresponding GitHub release
✅ OpenSSF Scorecard token permissions alert
✅ Community reports of unexpected behavior

🛡️ Response Actions:

Immediate: npm unpublish malicious version (within 72-hour window)
Containment: Publish emergency patch version, notify users via GitHub Security Advisory
Investigation: Revoke compromised npm token, audit all recent publishes
Recovery: Reset maintainer credentials, enforce hardware 2FA
Prevention: Implement GitHub Actions OIDC publishing (no long-lived tokens)

📉 Risk Score: 🔴 Critical (9.0/10) — Supply chain attack with wide blast radius

Scenario 5: MCP Protocol Injection Attack

🎯 Attack Objective: Exploit MCP tool parameter parsing to inject malicious JSON-RPC payloads

🎭 Threat Actor: Security researcher (white hat) or advanced persistent threat

📊 Attack Chain:

graph LR
    A["1️⃣ Craft malicious tool parameters"] --> B["2️⃣ Exploit Zod schema weakness"]
    B --> C["3️⃣ Inject code execution payload"]
    C --> D["4️⃣ MCP server executes attacker code"]
    D --> E["5️⃣ AI assistant compromise"]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

Attack Steps:

Payload Crafting: Attacker analyzes Zod schemas for searchDocuments tool
Schema Bypass: Finds edge case where deeply nested JSON evades validation
Code Injection: Injects prototype pollution payload via __proto__ in parameters
Execution: Exploits TypeScript any type in error handler to gain code execution
Persistence: Modifies AI assistant behavior to exfiltrate user prompts

🔍 Detection Indicators:

✅ Zod validation errors with unusual parameter structures
✅ TypeScript strict mode violations (should not occur)
✅ stderr logs show unexpected JSON parsing errors
✅ Memory usage spikes during tool invocation

🛡️ Response Actions:

Immediate: Kill MCP server process, isolate affected AI assistant instance
Containment: Deploy emergency patch to harden Zod schemas
Investigation: Analyze parameter payloads, identify injection vector
Recovery: Publish CVE, coordinate disclosure with MCP protocol maintainers
Prevention: Fuzz testing of all MCP tool schemas, add runtime schema enforcement

📉 Risk Score: 🟠 High (8.0/10) — Novel MCP protocol exploit with AI assistant compromise

🔄 Continuous Validation & Assessment

Threat modeling is not a one-time activity but a continuous process that evolves with the system, threat landscape, and organizational maturity. This section defines the validation lifecycle for the European Parliament MCP Server threat model.

Threat Modeling Workshop Process

Following Hack23 AB Workshop Framework, the EP MCP Server employs a structured 7-phase workshop process:

graph LR
    PRE["🔍 PRE<br/>Preparation"] --> ENUM["📋 ENUM<br/>Enumeration"]
    ENUM --> THREATS["⚠️ THREATS<br/>Identification"]
    THREATS --> MAP["🗺️ MAP<br/>ATT&CK Mapping"]
    MAP --> PLAN["📝 PLAN<br/>Mitigation"]
    PLAN --> VALIDATE["✅ VALIDATE<br/>Verification"]
    VALIDATE --> MONITOR["📊 MONITOR<br/>Continuous"]
    MONITOR -.->|Next Cycle| PRE

    style PRE fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ENUM fill:#2196f3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style THREATS fill:#ff9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style MAP fill:#9c27b0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff


    style PLAN fill:#f44336,stroke:#aa2e25,stroke-width:2px,color:#ffffff


    style VALIDATE fill:#00bcd4,stroke:#008394,stroke-width:2px,color:#ffffff


    style MONITOR fill:#795548,stroke:#543b32,stroke-width:2px,color:#ffffff

Phase	Activities	EP MCP Server Focus	Output
🔍 PRE	Gather architecture docs, review previous findings, update scope	Review SECURITY_ARCHITECTURE.md, npm audit, Dependabot alerts	Updated scope definition, pre-read materials
📋 ENUM	Enumerate assets, trust boundaries, data flows	Map MCP tools, EP API endpoints, cache layer, stdio transport	Asset inventory, data flow diagrams
⚠️ THREATS	Apply STRIDE per component, identify new threats	Analyze 6 components × 6 STRIDE categories	Updated STRIDE threat tables
🗺️ MAP	Map threats to MITRE ATT&CK, ENISA TL 2024, Kill Chain	Update 13 ATT&CK technique mappings, kill chain disruption table	ATT&CK coverage heat map, kill chain analysis
📝 PLAN	Design mitigations, assign owners, set deadlines	Prioritize controls for supply chain, input validation, data integrity	Mitigation action items with owners
✅ VALIDATE	Test controls, verify SLSA attestations, review OpenSSF score	Run security tests, verify rate limiting, check SBOM	Validation report, control effectiveness metrics
📊 MONITOR	Track KPIs, review threat intelligence, schedule next cycle	Monitor OpenSSF Scorecard, Dependabot, npm audit, audit logs	KPI dashboard, next review date

🗓️ Cadence:

Monthly: Quick threat landscape review (30 minutes)
Quarterly: Full threat model workshop (2-3 hours)
Annually: Comprehensive threat model revision (full-day session)

👥 Workshop Participants:

Role	Responsibility	Mandatory?
Security Architect (CEO)	Workshop facilitator, threat prioritization	✅ Yes
Lead Developer	Technical feasibility of mitigations	✅ Yes
Product Owner	Business impact assessment	✅ Yes
DevOps Engineer	CI/CD security controls	🟡 Recommended
External Security Expert	Independent threat assessment	🟢 Annually

Ad-Hoc Review Triggers

The threat model must be reviewed immediately when any of the following events occur:

Trigger Event	Review Scope	Timeline
🚨 Security Incident	Full STRIDE re-analysis of affected component	Within 48 hours
🆕 Major Feature Release	Threat analysis of new attack surface	Before release
📊 Significant Threat Landscape Change	Update threat actor profiles, MITRE ATT&CK mapping	Within 1 week
🔧 Architecture Change	Re-assess STRIDE for modified components	Before deployment
📜 New Regulatory Requirement	Compliance gap analysis (e.g., CRA update)	Within 30 days
🔓 Zero-Day in Dependency	Risk assessment and mitigation strategy	Within 24 hours

Workshop Activities Checklist

Quarterly Threat Modeling Workshop Agenda:

Review Previous Action Items (15 min)
- Status of mitigations from last workshop
- Effectiveness metrics for deployed controls
Threat Landscape Update (30 min)
- ENISA Threat Landscape review
- Recent vulnerabilities in Node.js/TypeScript ecosystem
- New MITRE ATT&CK techniques
STRIDE Re-Assessment (45 min)
- Walk through each threat category
- Identify new threats since last review
- Re-assess likelihood and impact scores
Attack Tree Review (30 min)
- Update attack tree with new threat vectors
- Re-evaluate mitigation effectiveness
Security Control Validation (30 min)
- Test SLSA attestations, Dependabot alerts
- Review OpenSSF Scorecard metrics
- Verify rate limiting and input validation
Risk Prioritization (20 min)
- Update risk matrix based on new findings
- Assign action items with owners and deadlines
Documentation Update (10 min)
- Update this THREAT_MODEL.md
- Sync with SECURITY_ARCHITECTURE.md

📝 Workshop Output: Updated threat model, prioritized action items, risk register

Continuous Validation Cycle

graph LR
    A["🔍 Monitor Threat<br/>Landscape"] --> B["📊 Identify New<br/>Threats"]
    B --> C["🎯 Assess Impact &<br/>Likelihood"]
    C --> D["🛡️ Design/Update<br/>Mitigations"]
    D --> E["✅ Implement<br/>Controls"]
    E --> F["📈 Measure<br/>Effectiveness"]
    F --> A
    
    style A fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style B fill:#2196f3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style C fill:#ff9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style D fill:#9c27b0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff


    style E fill:#f44336,stroke:#aa2e25,stroke-width:2px,color:#ffffff


    style F fill:#00bcd4,stroke:#008394,stroke-width:2px,color:#ffffff

Key Performance Indicators (KPIs) for Threat Model Health:

KPI	Target	Current	Status
OpenSSF Scorecard Score	≥8.0/10	9.2/10	✅ Excellent
High/Critical Vulnerabilities	0	0	✅ Excellent
SLSA Provenance Coverage	100%	100%	✅ Excellent
Threat Model Staleness	<90 days	15 days	✅ Current
Security Control Test Coverage	≥80%	85%	✅ Good
Incident Response Drill Success	100%	N/A	⚠️ Not tested

Improvement Actions:

Schedule annual incident response tabletop exercise
Implement automated threat intelligence feed integration
Develop threat model dashboard for real-time monitoring

📅 Assessment Lifecycle

This section defines the structured cadence for threat model reviews, ensuring systematic and timely updates aligned with the evolving threat landscape and project lifecycle.

Scheduled Review Cadence

Frequency	Activity	Owner	Duration	Deliverables
📆 Monthly	Dependency vulnerability scan review	Lead Developer	30 min	Updated dependency lockfile, npm audit report
📆 Quarterly	Full threat model review workshop	Security Architect	2-3 hours	Updated THREAT_MODEL.md, risk register, action items
📆 Semi-Annually	MITRE ATT&CK mapping update	Security Architect	1 hour	Updated ATT&CK Navigator layer, coverage gaps identified
📆 Annually	Complete threat model revision	Security Architect + External Expert	1 day	Comprehensive threat model v2.0, new attack scenarios
🔴 Ad-Hoc	Triggered by events (see below)	Security Architect	Variable	Incident-specific threat assessment

Ad-Hoc Review Triggers (Detailed)

Immediate Review Required (<48 hours):

🚨 Security Incident: Active compromise or exploitation detected
🔓 Zero-Day Vulnerability: Critical CVE in Node.js, npm, or direct dependencies
📰 Public Disclosure: Security researcher publishes vulnerability in MCP protocol

Expedited Review (Within 1 Week):

🆕 Major Feature Release: New MCP tool added, API integration change
📊 Threat Intelligence Alert: ENISA/CISA advisory relevant to Node.js/TypeScript ecosystem
🏛️ EP API Breaking Change: European Parliament API schema or security model update

Scheduled Review (Within 30 Days):

📜 Regulatory Update: EU CRA amendment, GDPR guidance update
🔧 Architecture Refactor: Migration to new framework, protocol upgrade
🎖️ Compliance Audit Finding: ISO 27001 audit identifies threat modeling gap

Review Process Workflow

graph TD
    A["📅 Scheduled Review<br/>or Trigger Event"] --> B{Review Type?}
    B -->|Monthly| C[Dependency Scan<br/>Review]
    B -->|Quarterly| D[Full Threat Model<br/>Workshop]
    B -->|Annual| E[Comprehensive<br/>Revision]
    B -->|Ad-Hoc| F[Incident-Specific<br/>Assessment]
    
    C --> G[Update Lockfile]
    D --> H[Update STRIDE Tables]
    E --> I[New Attack Scenarios]
    F --> J[Incident Report]
    
    G --> K[Document Changes]
    H --> K
    I --> K
    J --> K
    
    K --> L[Commit to GitHub]
    L --> M["📢 Communicate Updates"]
    M --> N["✅ Review Complete"]
    
    style A fill:#4caf50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style B fill:#2196f3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style K fill:#ff9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style N fill:#9c27b0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff

Review Deliverables by Type

Monthly Dependency Review:

✅ Updated package-lock.json with patched dependencies
✅ npm audit report with 0 high/critical vulnerabilities
✅ Dependabot PR merge/rejection justifications
✅ Updated SBOM (CycloneDX) published to GitHub Releases

Quarterly Threat Model Workshop:

✅ Updated THREAT_MODEL.md with new threats
✅ Risk matrix with re-assessed likelihood/impact scores
✅ Action item register with assigned owners and deadlines
✅ Security control effectiveness validation report

Annual Comprehensive Revision:

✅ Threat Model v2.0 with new attack scenarios
✅ Updated MITRE ATT&CK Navigator layer JSON
✅ External security expert assessment report
✅ Alignment with latest ENISA Threat Landscape
✅ Security maturity level progression plan

Ad-Hoc Incident Assessment:

✅ Root cause analysis with STRIDE classification
✅ Lessons learned document
✅ Updated threat actor profiles (if new TTPs identified)
✅ Enhanced mitigations roadmap

Version Control & Change Tracking

All threat model updates are tracked via Git commits with the following conventions:

# Commit message format
threat-model: [Review Type] - Brief description

# Examples
git commit -m "threat-model: Quarterly Review Q1 2025 - Added MCP injection scenario"
git commit -m "threat-model: Ad-Hoc - CVE-2025-12345 in ws dependency assessment"
git commit -m "threat-model: Annual Revision - MITRE ATT&CK coverage expansion"

📊 Threat Model Changelog: Maintained via Git commit history using the threat-model: commit-message convention described above.

🎯 Security Maturity Framework

The European Parliament MCP Server's security posture is assessed using a 5-level maturity model adapted from NIST Cybersecurity Framework and ISO 27001 maturity scales. This framework guides continuous improvement toward optimized security practices.

Maturity Level Definitions

Level 1: 🔴 Initial (Ad-Hoc Security Practices)

Characteristics:

❌ No formal threat modeling process
❌ Security controls implemented reactively after incidents
❌ No security testing in CI/CD pipeline
❌ Dependency vulnerabilities addressed sporadically
❌ No security documentation or policies

Typical Indicators:

Multiple high/critical vulnerabilities in production
No SBOM or supply chain visibility
Manual security testing (if any)
No incident response plan

Improvement Path: Establish basic security controls (SAST, dependency scanning)

Level 2: 🟡 Developing (Basic Controls Implemented)

Characteristics:

✅ Basic threat identification (STRIDE threats documented)
✅ Essential security controls deployed (HTTPS, input validation)
✅ Dependency scanning with Dependabot
⚠️ Inconsistent security testing
⚠️ No quantitative risk assessment

Typical Indicators:

Dependabot alerts reviewed weekly
Some SAST tools integrated in CI/CD
SECURITY.md and basic vulnerability disclosure process
Reactive incident response

Improvement Path: Systematize threat modeling, implement SLSA Level 2

Level 3: 🟢 Defined (Systematic Threat Modeling)

Characteristics:

✅ Formal threat model with STRIDE per element
✅ MITRE ATT&CK mapping to threats
✅ Quarterly threat model reviews
✅ Comprehensive security testing (SAST, DAST, SCA)
✅ SLSA Level 3 provenance
✅ Security architecture documentation

Typical Indicators:

OpenSSF Scorecard ≥8.0/10
THREAT_MODEL.md and SECURITY_ARCHITECTURE.md maintained
Automated security gates in CI/CD
Proactive vulnerability management with SLAs

Current Level: 🟢 The European Parliament MCP Server is at Level 3

Improvement Path: Implement security metrics, threat intelligence integration

Level 4: 🔵 Managed (Metrics-Driven Security)

Characteristics:

✅ Quantitative risk assessment with business impact
✅ Security metrics dashboard (MTTR, vulnerability density, control effectiveness)
✅ Threat intelligence feeds integrated
✅ Continuous security testing (shift-left + shift-right)
✅ Automated incident response playbooks
✅ Security budget aligned with risk

Typical Indicators:

Mean Time To Remediation (MTTR) tracked and improving
Security KPIs reported to leadership quarterly
Threat model updated automatically from threat intelligence
Bug bounty program operational

Improvement Path: Predictive security analytics, AI-driven threat hunting

Level 5: ⭐ Optimizing (Continuous Improvement)

Characteristics:

✅ Real-time threat model updates via automation
✅ Predictive threat analytics using ML/AI
✅ Self-healing security controls
✅ Zero Trust Architecture fully implemented
✅ Security innovation through R&D
✅ Industry-leading security posture

Typical Indicators:

OpenSSF Scorecard 10.0/10
Autonomous security validation and remediation
Published security research and threat intelligence
Recognized as security exemplar in open-source community

Improvement Path: Maintain excellence, contribute to security standards

European Parliament MCP Server — Current Maturity Assessment

📊 Overall Maturity Level: 🟢 Level 3: Defined (Systematic Threat Modeling)

Security Domain	Current Level	Target (2025)	Gap Analysis
Threat Modeling	🟢 Level 3	🔵 Level 4	Implement threat intelligence integration
Supply Chain Security	🟢 Level 3	🟢 Level 3	Maintain SLSA Level 3, monitor npm ecosystem
Vulnerability Management	🟢 Level 3	🔵 Level 4	Add MTTR metrics, automate patching
Security Testing	🟢 Level 3	🔵 Level 4	Add DAST, penetration testing
Incident Response	🟡 Level 2	🟢 Level 3	Conduct tabletop exercises, automate runbooks
Security Monitoring	🟡 Level 2	🟢 Level 3	Implement security metrics dashboard
Documentation	🟢 Level 3	🟢 Level 3	Maintain current excellence

Maturity Progression Roadmap (2025-2026)

gantt
    title Security Maturity Roadmap
    dateFormat YYYY-MM
    section Threat Modeling
    Threat Intelligence Integration   :2025-03, 3M
    Automated MITRE ATT&CK Updates   :2025-06, 2M
    section Vulnerability Management
    MTTR Metrics Dashboard           :2025-02, 2M
    Automated Patch Deployment       :2025-08, 3M
    section Security Testing
    DAST Integration (OWASP ZAP)     :2025-04, 2M
    Annual Penetration Test          :2025-09, 1M
    section Incident Response
    Tabletop Exercise                :2025-05, 1M
    Automated IR Playbooks           :2025-10, 3M
    section Monitoring
    Security Metrics Dashboard       :2025-03, 3M
    Anomaly Detection System         :2025-11, 4M

🎯 2025 Target: Achieve Level 4 (Managed) maturity in Threat Modeling and Vulnerability Management domains.

Maturity Assessment Criteria

To objectively measure progression, the following criteria are used for annual maturity assessments:

Criterion	Weight	Level 3 Threshold	Level 4 Threshold
OpenSSF Scorecard	20%	≥8.0/10	≥9.0/10
SLSA Level	15%	Level 3	Level 3 + Enhanced Monitoring
Threat Model Freshness	10%	<90 days	<30 days (automated)
Vulnerability MTTR	15%	Critical <7d, High <30d	Critical <24h, High <7d
Security Test Coverage	15%	≥80%	≥90% with mutation testing
Incident Response Readiness	10%	Plan documented	Drills quarterly, automation
Security Metrics	10%	Manual reporting	Real-time dashboard
Threat Intelligence	5%	Manual review	Automated integration

Assessment Method: Annual third-party security audit with maturity scorecard

📊 Quantitative Risk Assessment

Risk Matrix

%%{init: {
  "theme": "dark",
  "themeVariables": {
    "quadrant1Fill": "#d32f2f",
    "quadrant2Fill": "#4caf50",
    "quadrant3Fill": "#2e7d32",
    "quadrant4Fill": "#ff9800",
    "quadrantTitleFill": "#ffffff",
    "quadrantPointFill": "#ffffff",
    "quadrantPointTextFill": "#ffffff",
    "quadrantXAxisTextFill": "#ffffff",
    "quadrantYAxisTextFill": "#ffffff"
  },
  "quadrantChart": {
    "chartWidth": 700,
    "chartHeight": 700,
    "pointLabelFontSize": 12,
    "titleFontSize": 20,
    "quadrantLabelFontSize": 16,
    "xAxisLabelFontSize": 14,
    "yAxisLabelFontSize": 14
  }
}}%%
quadrantChart
    title 🎯 Threat Risk Assessment Matrix
    x-axis Low Likelihood --> High Likelihood
    y-axis Low Impact --> High Impact
    quadrant-1 CRITICAL PRIORITY
    quadrant-2 MONITOR
    quadrant-3 ACCEPT
    quadrant-4 MITIGATE
    "📦 Supply Chain Attack": [0.5, 0.9]
    "⚡ API Rate Exhaustion": [0.6, 0.5]
    "💉 Input Injection": [0.4, 0.6]
    "🔍 Error Info Leak": [0.5, 0.4]
    "📛 Package Squatting": [0.3, 0.7]
    "🧬 Prototype Pollution": [0.2, 0.7]
    "🕵️ MITM Attack": [0.2, 0.6]
    "🏗️ Build Tampering": [0.2, 0.8]

Top Priority Risks

Priority	Risk	Current Status	Action Required
🔴 P1	Supply chain compromise (T-2, S-4)	✅ Mitigated	Maintain Dependabot, SLSA attestations
🟠 P2	Input validation bypass (E-1)	✅ Mitigated	Zod schemas for all tool inputs
🟡 P3	API rate limit exhaustion (D-1)	✅ Mitigated	Client-side rate limiting implemented
🟡 P4	Error information disclosure (I-1)	⚠️ Partial	Improve error sanitization
🟢 P5	Build artifact tampering (T-3)	✅ Mitigated	SLSA Level 3 provenance

💰 Quantitative Risk Scoring — Top 7 Priority Scenarios

This section provides quantitative risk estimates for the 7 priority threat scenarios using Single Loss Expectancy (SLE), Annual Rate of Occurrence (ARO), and Annualized Loss Expectancy (ALE) metrics. Per Hack23 Risk Management Policy §4.2, quantitative risk scoring enables risk-prioritized security investment.

⚠️ Disclaimer: These figures are order-of-magnitude estimates for risk prioritization, not insurance-grade quantification. Actual losses may vary significantly based on threat landscape evolution, control effectiveness, and business context. Estimates are grounded in publicly available data for open-source npm-distributed servers with no revenue.

Quantitative Risk Matrix

#	Scenario	SLE (€)	ARO (per year)	ALE (€/year)	Confidence	Calculation Basis
1	Supply Chain Compromise (T1195.002, T1059.007)	€5,000 – €10,000	0.1 – 0.2	€500 – €2,000	Medium	SLE: OpenSSF Scorecard drop (9.4→7.0) → estimated 20–30% user-loss × €500 replacement cost per user (developer time to find alternative); npm package removal cost €2k–5k (republishing, reputation recovery). ARO: npm ecosystem avg. supply-chain incident rate 0.1–0.2/year (1 incident per 5–10 years) for packages with SLSA Level 3 + Dependabot.
2	Parliamentary Data Manipulation (T1557, T1565.002)	€1,000 – €3,000	0.05 – 0.1	€50 – €300	Low	SLE: Reputational damage if false EP data propagates (news article retractions, community trust loss) → €1k–3k in brand recovery, user communication. ARO: HTTPS/TLS 1.3 + certificate validation makes MITM highly unlikely (0.05–0.1/year, ca. 1 per 10–20 years for well-configured TLS).
3	MCP Protocol Abuse (AI Jailbreak) (T1059, T1480)	€500 – €2,000	0.2 – 0.5	€100 – €1,000	Medium	SLE: Service disruption (rate-limit exhaustion) + incident-response time (8–16 hours × €50/hour contractor rate) + minor reputational impact. ARO: AI jailbreak attempts growing (0.2–0.5/year, ca. 1 per 2–5 years) as LLM capabilities advance; Zod validation provides strong defense.
4	GDPR Personal Data Exposure (T1213)	€10,000 – €10,000,000	0.01 – 0.05	€100 – €500,000	Low	SLE: GDPR Article 83 fines: €10M or 2% turnover (Article 83(4)(a) for security-of-processing violations); worst-case €20M or 4% turnover (Article 83(5) if personal data breach under Articles 33/34). For a €0-revenue open-source project, realistic fine €0–10k (administrative fine for non-compliance); reputational damage €5k–10k. ARO: Very low (0.01–0.05/year, ca. 1 per 20–100 years) due to public data focus + sanitized error handling; requires verbose error misconfiguration + regulatory audit.
5	EP API Denial of Service (T1499.004)	€500 – €1,500	0.1 – 0.3	€50 – €450	Medium	SLE: Service downtime (4–8 hours) × user frustration + EP API quota reset cost (€0 for public API, but reputational impact €500–1.5k). ARO: Rate limiting (100/min) mitigates but not adaptive; 0.1–0.3/year (ca. 1 per 3–10 years) for sustained DoS attempts.
6	Build Artifact Tampering (T1554, T1195.002)	€10,000 – €50,000	0.02 – 0.05	€200 – €2,500	Medium	SLE: Complete service compromise → npm package removal + user notifications + emergency patching + OpenSSF Scorecard drop → €10k–50k (developer time + reputation recovery + potential legal costs if malware spread). ARO: Very low (0.02–0.05/year, ca. 1 per 20–50 years) with SLSA Level 3 + branch protection + npm 2FA.
7	Reputation Attack via Security Metrics (T1591, T1588.005)	€1,000 – €5,000	0.1 – 0.2	€100 – €1,000	Medium	SLE: OpenSSF Scorecard drop (9.4→8.5) → 10–15% user-loss × €500 replacement cost; FUD campaign response (blog posts, CVE triage, community communication) €1k–5k. ARO: Competitive FUD campaigns or minor-CVE exploitation (0.1–0.2/year, ca. 1 per 5–10 years); transparent security posture mitigates.

Aggregated Annual Risk Exposure

Metric	Value	Notes
Total ALE (Sum)	€1,200 – €505,250	Sum of all 7 scenarios; dominated by GDPR worst-case
Realistic ALE (Excluding Worst-Case GDPR)	€1,100 – €5,250	Excluding scenario 4 worst-case (€10M GDPR fine unlikely for €0-revenue OSS)
Mean ALE (Realistic)	€3,175/year	Average across 7 scenarios (realistic range)
Risk-Adjusted Budget Recommendation	€5,000 – €10,000/year	Security investment = 1.5–3× mean ALE (industry standard risk-adjusted budget)

Confidence Levels Explained

Confidence	Meaning	Basis
High	75–90% confidence in SLE/ARO estimates	Industry benchmarks, historical npm data
Medium	50–75% confidence	Expert judgment, limited historical data
Low	25–50% confidence	Worst-case scenarios, regulatory uncertainty

Data Sources:

SLE (Reputation): OpenSSF Scorecard user-adoption impact studies (2024)
SLE (GDPR): GDPR enforcement tracker (2018–2024 fines database)
ARO (Supply Chain): npm ecosystem incident reports (Snyk, Sonatype, GitHub Advisory Database)
ARO (MITM): TLS 1.3 vulnerability disclosures (2020–2024)
Cost (Developer Time): €50/hour contractor rate (EU market average, 2024)

🛡️ Security Controls & Mitigations

Control Architecture

graph TB
    subgraph "🔒 Defense in Depth"
        subgraph "Layer 1: Input Validation"
            ZOD[Zod Schema Validation]
            PARAM[Parameter Sanitization]
        end
        subgraph "Layer 2: Rate Limiting"
            RL[Request Rate Limiter]
            QUOTA[API Quota Management]
        end
        subgraph "Layer 3: Transport Security"
            HTTPS[HTTPS/TLS 1.3]
            STDIO[stdio Isolation]
        end
        subgraph "Layer 4: Supply Chain"
            SLSA[SLSA Level 3]
            SBOM[CycloneDX SBOM]
            DEP[Dependabot]
        end
        subgraph "Layer 5: Monitoring"
            AUDIT[Audit Logging]
            SCORE[OpenSSF Scorecard]
        end
    end

    ZOD --> RL --> HTTPS --> SLSA --> AUDIT

Security Controls Matrix

Control	Category	Threats Mitigated	Status
Zod input validation	Preventive	E-1, D-4, E-3	✅ Active
Rate limiting	Preventive	D-1, D-2	✅ Active
HTTPS/TLS for EP API	Preventive	S-2, T-1	✅ Active
SLSA Level 3 provenance	Detective	T-3, S-4	✅ Active
Dependabot alerts	Detective	T-2	✅ Active
npm audit	Detective	T-2, S-4	✅ Active
OpenSSF Scorecard	Detective	Multiple	✅ Active
CycloneDX SBOM	Transparency	T-2	✅ Active
TypeScript strict mode	Preventive	E-2, I-1	✅ Active
Environment variable validation	Preventive	T-4	✅ Active
Structured error handling	Preventive	I-1, I-2	✅ Active
Branch protection	Preventive	R-2	✅ Active
Code review requirements	Detective	Multiple	✅ Active
Security headers	Preventive	Multiple	✅ Active

🌳 Attack Tree Analysis

Attack Tree 1: Supply Chain Compromise (Detailed)

graph TD
    ROOT["🎯 Compromise EP MCP<br/>via Supply Chain"]
    
    ROOT --> A["📦 Malicious Dependency<br/>Injection"]
    ROOT --> B["🏭 Build Pipeline<br/>Compromise"]
    ROOT --> C["📤 npm Package<br/>Substitution"]
    ROOT --> D["🔧 Developer<br/>Environment Attack"]
    
    A --> A1["Compromised npm package"]
    A --> A2["Typosquatting dependency"]
    A --> A3["Dependency confusion"]
    A1 --> A1a["Install backdoored package"]
    A1 --> A1b["Exploit known CVE"]
    A1a --> A1M["✅ Dependabot alerts"]
    A1b --> A1M2["✅ npm audit + Snyk"]
    A2 --> A2M["✅ package-lock.json pinning"]
    A3 --> A3M["✅ No private scope overlap"]
    
    B --> B1["GitHub Actions compromise"]
    B --> B2["Build artifact tampering"]
    B --> B3["Stolen publish credentials"]
    B1 --> B1a["Malicious workflow change"]
    B1 --> B1b["Environment secret theft"]
    B1a --> B1M["✅ Branch protection + CODEOWNERS"]
    B1b --> B1M2["✅ OIDC token auth (no secrets)"]
    B2 --> B2M["✅ SLSA Level 3 provenance"]
    B3 --> B3M["✅ npm 2FA required"]
    
    C --> C1["Package name squatting"]
    C --> C2["Account takeover"]
    C --> C3["npm registry compromise"]
    C1 --> C1M["✅ Official package ownership verified: european-parliament-mcp-server"]
    C2 --> C2M["✅ npm 2FA + strong passwords"]
    C3 --> C3M["❌ Out of scope (npm responsibility)"]
    
    D --> D1["Developer laptop malware"]
    D --> D2["SSH/GPG key theft"]
    D --> D3["Social engineering"]
    D1 --> D1M["⚠️ Developer responsibility"]
    D2 --> D2M["✅ GPG commit signing required"]
    D3 --> D3M["⚠️ Security awareness training"]

Attack Tree 2: Unauthorized Data Manipulation (T-1, T-2)

graph TD
    ROOT2["🎯 Manipulate EP<br/>Parliamentary Data"]
    
    ROOT2 --> E["🌐 API Response<br/>Tampering"]
    ROOT2 --> F["💾 Cache<br/>Poisoning"]
    ROOT2 --> G["📦 Dependency<br/>Injection"]
    ROOT2 --> H["🔧 Build Artifact<br/>Tampering"]
    
    E --> E1["MITM TLS interception"]
    E --> E2["Compromised EP API"]
    E --> E3["DNS hijacking"]
    E1 --> E1a["TLS downgrade attack"]
    E1 --> E1b["Rogue CA certificate"]
    E1a --> E1M["✅ TLS 1.3 minimum, no fallback"]
    E1b --> E1M2["✅ Certificate pinning (future)"]
    E2 --> E2M["❌ Out of scope (EP infrastructure)"]
    E3 --> E3M["⚠️ DNSSEC (ISP/user responsibility)"]
    
    F --> F1["Inject malicious response"]
    F --> F2["Memory corruption"]
    F --> F3["Race condition exploitation"]
    F1 --> F1M["✅ Cache only validated responses"]
    F2 --> F2M["✅ TypeScript + process isolation"]
    F3 --> F3M["✅ Atomic cache operations"]
    
    G --> G1["Install backdoored package"]
    G --> G2["Exploit known CVE"]
    G --> G3["Prototype pollution"]
    G1 --> G1M["✅ Dependabot + SLSA"]
    G2 --> G2M["✅ npm audit + Snyk"]
    G3 --> G3M["✅ TypeScript strict mode"]
    
    H --> H1["Modify dist/ artifacts"]
    H --> H2["CI/CD pipeline injection"]
    H --> H3["Release process bypass"]
    H1 --> H1M["✅ SLSA Level 3 attestations"]
    H2 --> H2M["✅ Branch protection + required checks"]
    H3 --> H3M["✅ npm provenance + 2FA"]

Attack Tree 3: Service Disruption / DoS (D-1, D-2, D-3)

graph TD
    ROOT3["🎯 Disrupt EP MCP<br/>Service Availability"]
    
    ROOT3 --> I["⏱️ Rate Limit<br/>Exhaustion"]
    ROOT3 --> J["💻 Resource<br/>Exhaustion"]
    ROOT3 --> K["🌐 EP API<br/>Overload"]
    ROOT3 --> L["📦 Supply Chain<br/>DoS"]
    
    I --> I1["AI client excessive requests"]
    I --> I2["Bypass rate limiter"]
    I --> I3["Distributed request flood"]
    I1 --> I1M["✅ Token bucket rate limiting"]
    I2 --> I2M["✅ Atomic rate limit checks"]
    I3 --> I3M["⚠️ stdio isolation limits multi-client"]
    
    J --> J1["Memory exhaustion (large responses)"]
    J --> J2["CPU exhaustion (regex DoS)"]
    J --> J3["Cache memory overflow"]
    J1 --> J1M["✅ Response size limits"]
    J2 --> J2M["✅ Zod validation (no regex)"]
    J3 --> J3M["✅ LRU cache with max size"]
    
    K --> K1["Excessive API requests"]
    K --> K2["Concurrent request flood"]
    K --> K3["Long-polling attacks"]
    K1 --> K1M["✅ Client-side rate limiting"]
    K2 --> K2M["✅ Concurrency limits (future)"]
    K3 --> K3M["✅ HTTP timeout configuration"]
    
    L --> L1["npm registry unavailable"]
    L --> L2["Compromised dependency unavailable"]
    L --> L3["GitHub Actions outage"]
    L1 --> L1M["⚠️ npm mirrors (user responsibility)"]
    L2 --> L2M["✅ package-lock.json ensures reproducibility"]
    L3 --> L3M["❌ Out of scope (GitHub SLA)"]

Attack Tree 4: MCP Protocol Exploit (Original - Preserved)

graph TD
    ROOT["🎯 Compromise MCP Server"]
    ROOT --> A["📦 Supply Chain Attack"]
    ROOT --> B["🔌 MCP Protocol Exploit"]
    ROOT --> C["🌐 API Layer Attack"]
    ROOT --> D["💻 Runtime Exploit"]

    A --> A1["Malicious dependency"]
    A --> A2["Build pipeline compromise"]
    A --> A3["npm package substitution"]
    A1 --> A1M["✅ Dependabot + npm audit"]
    A2 --> A2M["✅ SLSA Level 3"]
    A3 --> A3M["✅ Official package, 2FA"]

    B --> B1["Parameter injection"]
    B --> B2["Tool abuse"]
    B --> B3["Resource exhaustion"]
    B1 --> B1M["✅ Zod validation"]
    B2 --> B2M["✅ Rate limiting"]
    B3 --> B3M["✅ Memory limits"]

    C --> C1["API MITM"]
    C --> C2["Rate limit exhaustion"]
    C --> C3["Response manipulation"]
    C1 --> C1M["✅ HTTPS/TLS"]
    C2 --> C2M["✅ Client rate limiting"]
    C3 --> C3M["✅ Response validation"]

    D --> D1["Prototype pollution"]
    D --> D2["Memory exhaustion"]
    D --> D3["Error info leakage"]
    D1 --> D1M["✅ TypeScript strict"]
    D2 --> D2M["✅ Response limits"]
    D3 --> D3M["⚠️ Improve sanitization"]

🔴 Priority Threat Scenarios

Detailed narrative scenarios prioritized by likelihood and business impact for the European Parliament MCP Server.

#	Scenario	Actor	Method	Impact	Current Controls	Residual Risk
1	Supply Chain Compromise (T1195.002 Compromise Software Supply Chain, T1059.007 JavaScript)	🎭 Nation-State APT 💰 Cybercriminal	Backdoored npm dependency injected via compromised maintainer account → malicious code in `node_modules/` → data exfiltration or sabotage during MCP tool execution	Critical: Loss of service reputation, potential data manipulation, user trust erosion, OpenSSF Scorecard degradation	✅ Dependabot alerts ✅ npm audit + Snyk ✅ SLSA Level 3 ✅ SBOM (CycloneDX) ✅ package-lock.json pinning	Medium (Continuous monitoring required)
2	Parliamentary Data Manipulation (T1557 Adversary-in-the-Middle, T1565.002 Transmitted Data Manipulation)	🏛️ Disinformation APT 🎯 Political Actor	MITM attack on EP API connection → inject false MEP voting records or manipulated plenary transcripts → AI assistant provides incorrect democratic transparency data → misinformation spread	High: Democratic process undermined, service credibility damaged, regulatory scrutiny (GDPR/NIS2)	✅ HTTPS/TLS 1.3 ✅ Certificate validation ✅ Response validation (Zod) ⚠️ Certificate pinning (future)	Low-Medium (TLS provides strong protection)
3	MCP Protocol Abuse (AI Jailbreak) (T1059 Command and Scripting Interpreter, T1480 Execution Guardrails Bypass)	🤖 Malicious AI User 🔬 Security Researcher	Crafted prompts causing AI assistant to invoke MCP tools with malicious parameters → bypass Zod validation via edge cases → unauthorized data access or service abuse	Medium: Data exposure, rate limit exhaustion, service disruption, reputational risk	✅ Zod schema validation ✅ TypeScript strict mode ✅ No shell execution ✅ Input sanitization	Low (Defense-in-depth architecture)
4	GDPR Personal Data Exposure (T1213 Data from Information Repositories)	🔍 Privacy Researcher 🎯 Regulatory Auditor	Verbose error messages or debug logs expose MEP personal data (addresses, contact info, personal declarations) → GDPR Article 32 violation → regulatory fines and reputational damage	Medium: GDPR Article 32 security-of-processing fines (typically up to €10M or 2% of worldwide annual turnover under Article 83(4)(a); potential escalation to €20M or 4% under Article 83(5) if a reportable personal data breach under Articles 33/34 occurs), reputational damage, user trust loss, mandatory breach notification	✅ Sanitized error handling ⚠️ Production log review ⚠️ PII detection in logs ✅ Public data focus	Low-Medium (Requires log sanitization review)
5	EP API Denial of Service (T1499.004 Application or System Exploitation Flood)	💼 Competitive Adversary 🎯 Disruptive Actor	Automated script or compromised AI client floods EP MCP Server with requests → client-side rate limiter bypassed or overwhelmed → EP API rate limits exhausted → service unavailable for legitimate users	Medium: Service unavailability, user frustration, EP API access suspended, reputational damage	✅ Token bucket rate limiter ✅ Concurrency limits ✅ Request logging ⚠️ Adaptive rate limiting (future)	Low-Medium (Rate limiting effective but not adaptive)
6	Build Artifact Tampering (T1554 Compromise Host Software Binary, T1195.002 Compromise Software Supply Chain)	🏭 CI/CD Attacker 🔓 Compromised GitHub Actions	Attacker modifies GitHub Actions workflow or injects malicious code during build → tampered `dist/` artifacts published to npm → users install compromised package → backdoor execution	Critical: Widespread malware distribution, npm package removal, OpenSSF Scorecard failure, complete service compromise	✅ SLSA Level 3 provenance ✅ Branch protection ✅ Required status checks ✅ CODEOWNERS enforcement ✅ npm 2FA	Low (Strong supply chain security)
7	Reputation Attack via Security Metrics (T1591 Gather Victim Org Information, T1588.005 Exploits)	🎯 Competitive Adversary 📉 FUD Campaign	Attacker exploits minor vulnerability or submits CVE against EP MCP Server → OpenSSF Scorecard drops below 9.0 → negative publicity and user migration to competitors	Medium: Market share loss, user trust erosion, competitive disadvantage, reduced adoption rate	✅ OpenSSF Scorecard 9.4+ ✅ Security badges (up-to-date) ✅ Transparent security docs ✅ Rapid vulnerability response	Low (Strong security posture)

🔭 Detection Signatures — Per-Scenario Logging Indicators

This section defines concrete detection signatures for each of the 7 priority threat scenarios, enabling automated threat detection and incident response. Per Hack23 Incident Response Plan §3, detection signatures must be actionable and tied to response playbooks.

Audit Event Schema: Based on src/utils/auditLogger.ts — AuditLogEntry { action: string; params?: Record<string, unknown>; result?: { count?: number; success: boolean; error?: string }; duration?: number; timestamp: Date }

Scenario 1: Supply Chain Compromise

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	Dependabot alerts, npm audit, OpenSSF Scorecard, SLSA provenance verification	Critical/high severity CVE in direct dependency	IR-SUPPLY-CHAIN
Signature 1	Dependabot alert severity `in ("critical", "high")` AND `package.scope === "direct"`	1 alert	Immediate patch or dependency replacement
Signature 2	OpenSSF Scorecard drop: `(previousScore - currentScore) >= 1.0` AND `currentScore < 9.0`	Score drop ≥1.0	Investigate scorecard degradation cause
Signature 3	npm audit: `vulnerabilities.high > 0 OR vulnerabilities.critical > 0`	Any high/critical vuln	CI/CD gate: block merge/publish
Signature 4	SLSA provenance signature mismatch: `slsa.verified === false`	Any mismatch	Quarantine build artifact, investigate tampering

Scenario 2: Parliamentary Data Manipulation

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	TLS certificate validation errors, Zod response validation failures, EP API response anomalies	TLS handshake failure or schema validation error spike	IR-DATA-INTEGRITY
Signature 1	auditEvent: `action === "tool_call" AND result.success === false AND result.error.includes("certificate")`	>3 TLS errors/hour	Potential MITM attack or cert expiry
Signature 2	auditEvent: `action === "tool_call" AND result.success === false AND result.error.includes("ZodError")`	>10 validation errors/hour	EP API schema change or response tampering
Signature 3	auditEvent: `action === "tool_call" AND params.tool.includes("vot") AND result.count === 0` (unexpected empty voting records)	>5 empty results/day	EP API outage or data manipulation

Scenario 3: MCP Protocol Abuse (AI Jailbreak)

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	Zod validation errors, rate limiter denials, unusual tool invocation patterns	Repeated Zod failures or rate-limit violations from single client	IR-ABUSE
Signature 1	auditEvent: `action === "tool_call" AND result.success === false AND result.error.includes("ZodError")`	>20 Zod errors/hour from same tool	Jailbreak attempt or malformed client
Signature 2	Rate limiter: `rateLimitDenials > 10/minute` (requires future rate-limit logging enhancement)	>10 denials/min	Automated abuse or compromised client
Signature 3	Tool invocation depth: `toolCallChain.length > 5` (future: track recursive tool calls)	Depth >5	Potential infinite-loop AI agent

Scenario 4: GDPR Personal Data Exposure

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	Error logs, audit logs, PII-detection regex (future enhancement)	PII keywords in error messages or logs	IR-GDPR-BREACH
Signature 1	auditEvent: `result.error` contains PII regex: `/\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z]{2,}\b/` (email)	Any match	Sanitize error handling immediately
Signature 2	auditEvent: `action === "get_mep_details" AND params.id` logged with full MEP bio in `result`	Requires log-content analysis	Ensure PII sanitization in audit logs
Signature 3	Production error stack trace: `error.stack !== undefined` in logged errors	Any stack trace in prod	Fix error sanitization (I-1/I-2)

Scenario 5: EP API Denial of Service

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	Rate limiter logs, EP API 429 responses, request throughput monitoring	Sustained rate-limit denials or EP API quota exhaustion	IR-DOS
Signature 1	auditEvent: `action === "rate_limit_exceeded"` (requires future enhancement: log rate-limit events)	>100 denials/minute	Potential DoS attack
Signature 2	EP API response: `statusCode === 429` (Too Many Requests)	>5 consecutive 429s	EP API quota exhausted, throttle client
Signature 3	Request throughput: `toolCallsPerMinute > 150` (exceeds 100/min rate limit + 50% burst)	>150 calls/min	Burst traffic, investigate client behavior

Scenario 6: Build Artifact Tampering

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	SLSA provenance verification, GitHub Actions audit logs, npm publish logs	Provenance signature mismatch or unauthorized publish	IR-SUPPLY-CHAIN
Signature 1	SLSA: `provenance.signature.verified === false` OR `provenance.builder !== "https://github.com/slsa-framework/slsa-github-generator"`	Any mismatch	Quarantine npm package version
Signature 2	GitHub Actions: `workflow.modified === true` AND `approver !== CODEOWNERS`	Workflow change w/o approval	Investigate unauthorized workflow modification
Signature 3	npm publish: `publisher.twoFactorAuth === false` OR `publisher !== "authorized-maintainer"`	Any unauthorized publish	Revoke npm token, audit recent publishes

Scenario 7: Reputation Attack via Security Metrics

Detection Attribute	Signature	Alert Threshold	Response Playbook
Detection Source	OpenSSF Scorecard monitoring, GitHub Security Advisories, CVE database alerts	Scorecard drop or new CVE assigned	IR-REPUTATION
Signature 1	OpenSSF Scorecard: `currentScore < 9.0` AND `previousScore >= 9.0`	Score drops below 9.0	Investigate scorecard check failures
Signature 2	CVE assigned: `cve.severity in ("high", "critical")` AND `cve.packageName === "european-parliament-mcp-server"`	Any high/critical CVE	Emergency patch, security advisory
Signature 3	GitHub Security Advisory: `advisory.state === "published"` AND `advisory.severity in ("high", "critical")`	Any published advisory	Public communication, rapid response

Detection Infrastructure Requirements

Requirement	Current Status	Future Enhancement
Audit log aggregation	⚠️ stderr only (no centralized SIEM)	Integrate with CloudWatch Logs / Elasticsearch
Rate-limit event logging	⚠️ Denials not logged (future: add to auditLogger)	Add `rate_limit_exceeded` event to audit log schema
SLSA provenance verification	✅ Automated in CI/CD	Add provenance-verification alerts to Slack/email
OpenSSF Scorecard monitoring	⚠️ Manual weekly check	Automate daily Scorecard API polling + alerting
PII detection in logs	❌ No automated PII scanning	Implement regex-based PII detector for audit logs

🛡️ STRIDE → Control Mapping

Comprehensive mapping of each STRIDE threat category to preventive, detective, and corrective security controls.

STRIDE Category	Threat Definition	Primary Controls	Secondary Controls	Detection Controls	Monitoring & Response
🎭 Spoofing (S)	Impersonating a legitimate entity	• stdio transport isolation (S-1) • HTTPS/TLS 1.3 (S-2) • Official npm package name ownership (S-3) • npm 2FA (S-3)	• Certificate validation • Package provenance • GitHub Actions OIDC	• Audit logging (all requests) • npm download anomaly detection • TLS handshake monitoring	• OpenSSF Scorecard • npm package monitoring • Security badge alerts
🔧 Tampering (T)	Unauthorized modification of data or code	• HTTPS integrity checks (T-1) • SLSA Level 3 provenance (T-2, T-3) • Zod response validation (T-1) • Dependabot + npm audit (T-2)	• Branch protection • GPG commit signing • Immutable cache entries • Environment variable validation	• Dependabot alerts • npm audit (CI/CD) • SBOM vulnerability scanning • GitHub Advanced Security	• Snyk monitoring • Supply chain security alerts • Build artifact verification
🚫 Repudiation (R)	Denying actions or events	• Structured stderr logging (R-1) • ISO 8601 timestamps (R-1) • Immutable log streams (R-1) • GPG commit signing (R-2)	• Request ID correlation • GitHub Actions audit logs • npm publish logs	• Log aggregation (future) • Audit trail completeness checks • GitHub audit log API	• Log retention policy • Incident response procedures • Forensic analysis capability
📢 Information Disclosure (I)	Exposure of confidential information	• Sanitized error messages (I-1, I-2) • No API keys required (I-3) • Public data only (I-4) • TypeScript strict mode	• Production error handling • Generic log messages • No PII in cache keys • Environment variable masking	• Log content review • Error message monitoring • Stack trace detection	• Privacy impact assessment • GDPR compliance monitoring • Security code review
🚨 Denial of Service (D)	Degrading or preventing service availability	• Token bucket rate limiting (D-1) • Response size limits (D-2) • LRU cache max size (D-2) • Zod validation (no ReDoS) (D-4)	• HTTP timeout configuration • Memory monitoring • Concurrency limits • Call depth tracking	• Rate limit violation logs • Memory usage monitoring • API response time tracking	• Incident response procedures • Failover strategy • EP API health monitoring
⚡ Elevation of Privilege (E)	Gaining unauthorized capabilities	• Zod schema validation (E-1) • TypeScript strict mode (E-2) • No shell execution (E-4) • Input sanitization (E-3)	• Parameterized API calls • Process isolation (stdio) • Safe JSON parsing • No filesystem access	• Input validation failures • Unexpected tool invocations • Privilege escalation attempts	• Security testing (SAST/DAST) • Penetration testing • Bug bounty program (future)

🏛️ Comprehensive Security Control Framework

🛡️ Defense-in-Depth Architecture

graph TB
    subgraph "🏰 Layer 1: Perimeter Security"
        L1A["🌐 HTTPS/TLS 1.3"]
        L1B["⏱️ Rate Limiting"]
        L1C["🔒 Certificate Validation"]
        L1D["🚫 No HTTP Fallback"]
    end
    
    subgraph "🏗️ Layer 2: Application Security"
        L2A["✅ Zod Input Validation"]
        L2B["📝 TypeScript Strict Mode"]
        L2C["🛡️ Parameter Sanitization"]
        L2D["🚫 No Shell Execution"]
        L2E["🔍 Response Validation"]
    end
    
    subgraph "💾 Layer 3: Data Security"
        L3A["✅ Public Data Only"]
        L3B["⏳ TTL-Based Caching"]
        L3C["🔒 Immutable Cache Entries"]
        L3D["🧹 Sanitized Error Messages"]
        L3E["📊 Structured Logging"]
    end
    
    subgraph "📦 Layer 4: Supply Chain Security"
        L4A["🏅 SLSA Level 3"]
        L4B["🤖 Dependabot Alerts"]
        L4C["📋 SBOM CycloneDX"]
        L4D["🔐 npm 2FA Publishing"]
        L4E["🔒 package-lock.json"]
        L4F["🎯 npm Provenance"]
    end
    
    subgraph "🔍 Layer 5: Operational Security"
        L5A["📊 OpenSSF Scorecard"]
        L5B["📋 Audit Logging stderr"]
        L5C["🎖️ Security Badges"]
        L5D["🔄 Automated Testing"]
        L5E["🛡️ CodeQL SAST"]
        L5F["🔍 Snyk Scanning"]
    end
    
    L1A --> L2A
    L1B --> L2A
    L2A --> L3A
    L2B --> L3A
    L3A --> L4A
    L3E --> L4A
    L4A --> L5A
    L4B --> L5A
    
    style L1A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style L2A fill:#feca57,stroke:#b18d3c,stroke-width:2px,color:#000000


    style L3A fill:#48dbfb,stroke:#3299af,stroke-width:2px,color:#000000


    style L4A fill:#1dd1a1,stroke:#149270,stroke-width:2px,color:#000000


    style L5A fill:#9b59b6,stroke:#6c3e7f,stroke-width:2px,color:#ffffff

🎯 Control Effectiveness Matrix

Layer	Control	Type	NIST CSF 2.0 Function	Threats Addressed	Effectiveness	Status
1: Perimeter	HTTPS/TLS 1.3	Preventive	PR.DS-2, PR.DS-5	S-2, T-1, I-3	⭐⭐⭐⭐⭐ High	✅ Active
1: Perimeter	Token bucket rate limiting	Preventive	PR.IP-12, DE.CM-1	D-1, D-2, D-3	⭐⭐⭐⭐ High	✅ Active
1: Perimeter	Certificate validation	Detective	PR.DS-2	S-2, T-1	⭐⭐⭐⭐⭐ High	✅ Active
2: Application	Zod schema validation	Preventive	PR.DS-1, PR.IP-1	E-1, D-4, E-3	⭐⭐⭐⭐⭐ High	✅ Active
2: Application	TypeScript strict mode	Preventive	PR.IP-1	E-2, I-1	⭐⭐⭐⭐ High	✅ Active
2: Application	No shell execution	Preventive	PR.AC-4, PR.IP-1	E-4	⭐⭐⭐⭐⭐ High	✅ Active
3: Data	Response validation	Preventive	PR.DS-1	T-1, E-2	⭐⭐⭐⭐ High	✅ Active
3: Data	TTL-based caching	Preventive	PR.DS-3	I-4, T-1	⭐⭐⭐ Medium	✅ Active
3: Data	Sanitized error messages	Preventive	PR.DS-5	I-1, I-2	⭐⭐⭐ Medium	⚠️ Partial
3: Data	Structured logging (stderr)	Detective	DE.AE-3, DE.CM-1	R-1, R-3	⭐⭐⭐⭐ High	✅ Active
4: Supply Chain	SLSA Level 3 provenance	Detective	PR.DS-6, ID.SC-2	T-2, T-3, S-4	⭐⭐⭐⭐⭐ High	✅ Active
4: Supply Chain	Dependabot + npm audit	Detective	ID.RA-1, DE.CM-4	T-2, S-4	⭐⭐⭐⭐ High	✅ Active
4: Supply Chain	SBOM (CycloneDX)	Transparency	ID.AM-4, ID.SC-5	T-2	⭐⭐⭐ Medium	✅ Active
4: Supply Chain	npm 2FA publishing	Preventive	PR.AC-1	S-3, T-2	⭐⭐⭐⭐⭐ High	✅ Active
4: Supply Chain	package-lock.json pinning	Preventive	ID.SC-2	T-2, S-4	⭐⭐⭐⭐ High	✅ Active
5: Operations	OpenSSF Scorecard 9.4+	Detective	ID.IM-1, PR.IP-1	All categories	⭐⭐⭐⭐⭐ High	✅ Active
5: Operations	Audit logging (stderr)	Detective	DE.AE-3, RS.AN-1	R-1, R-2, R-3	⭐⭐⭐⭐ High	✅ Active
5: Operations	CodeQL SAST scanning	Detective	ID.RA-1, DE.CM-4	E-1, E-2, E-4, I-1	⭐⭐⭐⭐ High	✅ Active
5: Operations	Snyk vulnerability scanning	Detective	ID.RA-1, DE.CM-4	T-2, S-4	⭐⭐⭐⭐ High	✅ Active

📊 NIST CSF 2.0 Function Mapping

Function	Description	EP MCP Server Controls
🔍 IDENTIFY (ID)	Understand risks to systems and assets	• OpenSSF Scorecard monitoring • SBOM generation (CycloneDX) • Threat modeling (this document) • Security architecture documentation
🛡️ PROTECT (PR)	Implement safeguards for critical services	• Zod input validation • HTTPS/TLS 1.3 • TypeScript strict mode • Rate limiting • No shell execution • npm 2FA publishing
🔎 DETECT (DE)	Identify occurrence of cybersecurity events	• Dependabot alerts • npm audit • CodeQL SAST • Snyk scanning • Audit logging (stderr) • OpenSSF Scorecard
🚨 RESPOND (RS)	Take action regarding detected incidents	• Incident response procedures • Security advisory publication • Rapid patch deployment • Coordinated vulnerability disclosure
♻️ RECOVER (RC)	Restore capabilities or services	• npm package rollback • Version pinning (package-lock.json) • GitHub release rollback • Incident post-mortem

🔗 Policy Alignment

ISMS Policy	Relevance	Link
🎯 Threat Modeling	Primary methodology	Threat_Modeling.md
🔒 Secure Development	Development security requirements	Secure_Development_Policy.md
🔍 Vulnerability Management	Vulnerability handling SLAs	Vulnerability_Management.md
🌐 Network Security	Transport security requirements	Network_Security_Policy.md
🔑 Access Control	Authentication/authorization	Access_Control_Policy.md
🔐 Cryptography	TLS and encryption standards	Cryptography_Policy.md
🚨 Incident Response	Security incident procedures	Incident_Response_Plan.md
🏷️ Classification	Data classification framework	CLASSIFICATION.md

Compliance Framework Mapping

Framework	Controls Addressed
ISO 27001:2022	A.5.7, A.8.8, A.8.9, A.8.25, A.8.26, A.8.28
NIST CSF 2.0	ID.RA, PR.DS, PR.IP, DE.CM, RS.AN
CIS Controls v8.1	2.7, 7.1, 7.4, 16.1, 16.9

📋 CIA Triad and AAA Framework Application

CIA Triad Assessment

Principle	Application to EP MCP Server	Key Controls	Threat Categories
🔐 Confidentiality	MEP personal data protected from unauthorized access; API responses contain only publicly available parliamentary data	GDPR data minimization, PII stripping in audit logs, no persistent storage	Information disclosure (I-1 through I-4)
🔒 Integrity	Parliamentary data accuracy maintained from EP API source to MCP client response	TLS transport integrity, Zod schema validation, SLSA Level 3 provenance	Tampering (T-1 through T-4), Supply chain attacks
⚡ Availability	Continuous access to EP parliamentary data within rate limits	Rate limiting (100 req/min), LRU cache (15-min TTL), graceful degradation	Denial of service (D-1 through D-3)

AAA Framework Integration

Component	EP MCP Server Implementation	Scope
🔐 Authentication	OS process isolation (stdio transport) — client identity is the spawning process	Process-level identity
📋 Authorization	All 62 tools available to any authenticated client; no role-based restrictions in v1.1	Flat access model
📊 Accounting	AuditLogger tracks every tool invocation with timestamp, tool name, sanitized parameters, duration	Full audit trail

📊 Threat Catalog

Threat Documentation Standard

Each threat in this model follows the structured documentation format defined in Hack23 Threat Modeling Policy:

Field	Description	Example
Threat ID	Unique identifier (STRIDE category + sequence)	S-1, T-2, I-3
Category	STRIDE classification	Spoofing, Tampering, etc.
Description	Detailed threat narrative	"Malicious MCP client sends crafted tool arguments"
Attack Vector	MITRE ATT&CK technique mapping	T1059 (Command and Scripting)
Likelihood	Probability assessment (Low/Medium/High)	Medium
Impact	Business impact assessment (Low/Medium/High/Critical)	High
Risk Score	Likelihood × Impact	Medium-High
Controls	Existing mitigations	SC-001 (Zod validation)
Residual Risk	Risk after controls	Low
Owner	Responsible party	Development team

Threat Count Summary

STRIDE Category	Total Threats	High	Medium	Low
Spoofing	2	0	1	1
Tampering	4	1	2	1
Repudiation	2	0	2	0
Information Disclosure	4	1	2	1
Denial of Service	3	1	1	1
Elevation of Privilege	3	0	2	1
Supply Chain	3	2	1	0
Total	21	5	11	5

📈 AI Model Evolution — Threat Landscape Perspective

🔴 Evolving AI-Enabled Threat Vectors

As AI capabilities advance, the threat landscape for MCP servers evolves:

Timeline	AI Threat Vector	Impact on EP MCP Server	Mitigation Strategy
2025–2026	AI-generated social engineering targeting MCP tool arguments	Medium — crafted inputs designed to extract maximum data	Zod schema validation, rate limiting, data minimization
2026–2027	AI-powered dependency poisoning (LLM-generated malware in npm)	High — sophisticated supply chain attacks	SLSA Level 3, Dependabot, lockfile pinning, minimal deps
2027–2028	Autonomous AI agents attempting data exfiltration via MCP	Medium — automated abuse of MCP protocol	Rate limiting, anomaly detection, audit logging
2028–2030	AI-assisted API manipulation (adversarial ML against data pipelines)	Medium — attempted manipulation of parliamentary data flows	Source validation (EP API only), integrity checks
2030+	Quantum computing threats to TLS encryption	Low (current) — future risk to transport security	Monitor NIST post-quantum cryptography standards

🛡️ AI-Powered Defense Progression

Phase	Defense Capability	Implementation
Current (v1.1)	Static schema validation, rule-based rate limiting	Zod schemas, token bucket algorithm
Near-term (v1.2)	Enhanced anomaly detection in request patterns	MetricsService pattern analysis
Medium-term (v2.0)	AI-assisted threat detection for MCP protocol abuse	ML-based request classification
Long-term (v3.0+)	Predictive security analytics, automated threat response	Self-learning security controls

MCP Protocol-Specific AI Threats

Threat	Description	Current Control	Future Control
Prompt injection via tool args	AI client generates tool arguments containing injection payloads	Zod schema validation (strict types)	Semantic input analysis
Data harvesting automation	AI agent systematically extracts all available EP data	Rate limiting (100/min)	Usage pattern detection
Cross-tool correlation attacks	AI combines outputs from multiple tools to infer sensitive information	Data minimization per tool	Cross-tool correlation monitoring
Model poisoning via cached data	Compromised EP API responses cached and served to AI models	15-min cache TTL, EP API as single source	Response integrity validation

🇪🇺 EU Cyber Resilience Act — Annex I Mapping

This section maps the European Parliament MCP Server's security controls to the EU Cyber Resilience Act (CRA) Annex I Essential Cybersecurity Requirements. Per CRA-ASSESSMENT.md, this threat model provides evidence for CRA conformity assessment.

Part I — Product Design & Development Requirements

CRA Annex I Clause	Requirement (Paraphrased)	EP MCP Implementation	Linked Threat IDs	Status
1(a) — Secure by Default	Products shall be designed, developed, and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks	✅ Security-by-design architecture: 4-layer defense (Zod validation → rate limiting → audit logging → GDPR compliance); threat modeling integrated into SDLC; STRIDE analysis per component	S-1 through E-4, L-1 through L-5, M-1 through M-7	✅ Compliant
1(b) — No Known Exploitable Vulnerabilities	Products shall be delivered without any known exploitable vulnerabilities	✅ Dependabot + npm audit + Snyk continuous scanning; SLSA Level 3 provenance; CodeQL SAST on every PR; OpenSSF Scorecard 9.4+	T-2, S-4, T-3	✅ Compliant
1(c) — Secure Data Processing	Products shall be delivered with a secure by default configuration, including the possibility to reset the product to its original state	✅ Default configuration uses HTTPS-only (no HTTP fallback); no persistent state (stateless stdio MCP server); environment-variable validation; reset via `npm install` (reinstall)	T-4, S-2, T-1	✅ Compliant
1(d) — Confidentiality Protection	Products shall protect the confidentiality of stored, transmitted, or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms	✅ HTTPS/TLS 1.3 for all EP API communications; no secrets stored (public API only); stdio transport isolation (local process); public data classification (C: Public per ISMS)	S-2, T-1, I-3, I-4	✅ Compliant
1(e) — Integrity Protection	Products shall protect the integrity of stored, transmitted, or otherwise processed data, commands, programs, and configuration against any manipulation or modification not authorized by the user, as well as report on corruptions	✅ TLS integrity checks (S-2, T-1); Zod response validation against EP API schema; SLSA provenance for build artifacts; immutable cache entries; no user-writable configuration (env vars only)	T-1, T-2, T-3, E-2	✅ Compliant
1(f) — Availability & Minimal Impact	Products shall process only data that are adequate, relevant, and limited to what is necessary in relation to the intended use of the product (minimize attack surface)	✅ Data minimization: only public EP data accessed; no PII storage; no credentials required; minimal npm dependencies (26 direct, audited); no shell execution; no filesystem access	E-1, E-3, E-4, I-3, I-4	✅ Compliant
1(g) — Exploitation Mitigation	Products shall minimize their own negative impact on the availability of services provided by other devices or networks	✅ Client-side rate limiting (100 tokens/min); response-size limits (10MB); timeout controls (30s); LRU cache max-size (500 entries); no resource exhaustion (stateless design)	D-1, D-2, D-3, D-4	✅ Compliant
1(h) — Security Event Monitoring	Products shall be designed, developed, and produced to limit attack surfaces, including external interfaces	✅ Minimal attack surface: stdio transport (no network exposure); Zod schema validation (strict input surface); TypeScript strict mode; no eval/exec; public MCP protocol (62 tools, 9 resources, 7 prompts)	E-1, E-2, E-3, E-4, S-1	✅ Compliant
1(i) — Secure Default Configuration	Products shall be resilient against outages of external dependencies, e.g., power, cooling, information and communication technology infrastructure	✅ Stateless design (no persistent dependencies); EP API as single external dependency (fail-fast if unavailable); retry logic + circuit breaker (future); npm package self-contained (all deps bundled in `node_modules/`)	D-1, D-2	✅ Compliant
1(j) — Secure Update Mechanisms	Products shall be designed to facilitate the secure execution and maintenance of software updates and patches	✅ Structured stderr audit logging (R-1, R-3); ISO 8601 timestamps; request/response logging; GDPR-compliant PII sanitization; future: centralized log aggregation (CloudWatch/SIEM)	R-1, R-2, R-3, I-1	✅ Compliant

Part II — Vulnerability Handling Requirements

CRA Annex I Clause	Requirement (Paraphrased)	EP MCP Implementation	Linked Threat IDs	Status
2(1) — Vulnerability Identification	Manufacturers shall identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format	✅ CycloneDX SBOM generated on every release via GitHub Actions (`anchore/sbom-action`); SBOM quality ≥7.0/10 (NTIA/BSI validation); published to npm package + GitHub releases; SBOM includes all direct + transitive dependencies	T-2, S-4	✅ Compliant
2(2) — Address Vulnerabilities Without Delay	Manufacturers shall address and remediate vulnerabilities without delay, including by providing security updates	✅ MTTR SLA: Critical <7d, High <30d (per Vulnerability Management Policy); Dependabot auto-PRs; npm audit CI/CD gate; rapid security-patch process (SemVer PATCH release)	T-2, S-4	✅ Compliant
2(3) — Security Policy	Manufacturers shall apply effective and regular tests and reviews to ensure the cybersecurity of the product	✅ SECURITY.md vulnerability reporting policy; security@hack23.org contact; coordinated disclosure process (90-day embargo); responsible disclosure guidelines per Open Source Policy	R-1, R-2, I-1	✅ Compliant
2(4) — Vulnerability Disclosure	Manufacturers shall publicly disclose information about fixed vulnerabilities and security updates, including in a machine-readable format	✅ Automated testing: Vitest unit tests (80%+ coverage); E2E integration tests; CodeQL SAST (every PR); mutation testing (future); quarterly penetration testing (planned 2026)	T-1, T-2, E-1, E-2	✅ Compliant
2(5) — Coordinated Vulnerability Disclosure	Manufacturers shall facilitate the sharing of information about potential vulnerabilities in their products and associated upstream third-party components	✅ GitHub Security Advisories (GHSA) for all CVEs; npm advisory database; CHANGELOG.md for all releases; Security section in README.md; CVE publication via MITRE/NVD	T-2, S-4	✅ Compliant
2(6) — Information Sharing	Manufacturers shall establish and enforce policies and procedures for coordinated vulnerability disclosure	✅ Active participation in npm/GitHub security ecosystems; SBOM + SLSA provenance shared publicly; contribution to OWASP LLM Top 10 / MCP security research; OpenSSF Best Practices badge (public evidence)	T-2, S-4, L-1, M-2	✅ Compliant
2(7) — Security Update Distribution	Manufacturers shall remediate vulnerabilities by providing security updates that can be applied easily, minimizing disruption	✅ Coordinated disclosure via SECURITY.md; 90-day embargo for responsible disclosure; GitHub Security Advisories for coordination; CVSS scoring per Vulnerability Management Policy	T-2, R-2	✅ Compliant
2(8) — Vulnerability Information to Users	Manufacturers shall ensure that vulnerabilities are remediated in a timely manner and made available to users	✅ npm package updates (`npm install european-parliament-mcp-server@latest`); SemVer PATCH for security fixes; CHANGELOG.md documents all fixes; automated Dependabot notifications for downstream users	T-2, S-4	✅ Compliant

CRA Compliance Summary

Compliance Area	Total Clauses	Compliant (✅)	Compliance Rate
Part I: Product Design (1a–1j)	10	10	100%
Part II: Vulnerability Handling (2.1–2.8)	8	8	100%
Overall CRA Annex I	18	18	100%

Cross-Reference: For complete CRA conformity assessment including Article 10 (EU Declaration of Conformity), Article 20 (Technical Documentation), and Annex V (Conformity Assessment Process), see CRA-ASSESSMENT.md.

✍️ Residual-Risk Acceptance Log

This section documents accepted residual risks where mitigation costs exceed risk impact, per Hack23 Risk Management Policy §4.3. All residual risks are formally accepted by the CEO with scheduled quarterly review.

Residual Risk Register

Risk ID	Description	Residual Risk Level	Accepted By	Date	Review Date	Rationale
Scenario-4-GDPR	GDPR personal data exposure via verbose error messages or debug logs containing MEP PII (addresses, contact info, declarations)	Low-Medium (I-1, I-2 partially mitigated)	CEO / Hack23 AB	2026-04-28	2026-07-28	Risk: €100–€500k ALE (worst-case €10M GDPR fine, realistic €0–10k for OSS project with no revenue). Mitigation: ✅ Sanitized error handling implemented; ⚠️ Production log review ongoing; ✅ Public data focus (C: Public classification). Acceptance Criteria: Residual risk acceptable given (1) public EP data only (no GDPR Article 9 special-category data processed), (2) error sanitization controls in place (I-1), (3) realistic GDPR fine for €0-revenue OSS is €0–10k (administrative, not €10M), (4) cost of 100% PII elimination (€15k–25k for ML-based log scanning) exceeds realistic ALE. Compensating Controls: Quarterly production log audits for PII leakage; automated PII-detection regex (overdue since 2025 Q3).
Scenario-1-Supply-Chain	Supply chain compromise via backdoored npm dependency or compromised maintainer account	Medium (T-2, S-4 mitigated but non-zero residual)	CEO / Hack23 AB	2026-04-28	2026-07-28	Risk: €500–€2k ALE (ARO 0.1–0.2/year, SLE €5k–10k). Mitigation: ✅ Dependabot alerts; ✅ SLSA Level 3; ✅ npm audit + Snyk; ✅ SBOM (CycloneDX); ✅ package-lock.json pinning. Acceptance Criteria: Residual risk acceptable given (1) comprehensive supply-chain controls (SLSA L3 + Dependabot + SBOM), (2) ARO very low (0.1–0.2/year = 1 incident per 5–10 years for well-protected packages), (3) cost of additional controls (hardware security modules for signing, €10k–20k/year) exceeds ALE (€500–2k/year). Compensating Controls: Continuous OpenSSF Scorecard monitoring (target ≥9.0); community review of all dependency updates; npm 2FA + OIDC publishing.
L-3-Excessive-Agency	Autonomous AI agent invoking high-volume tool chains causing EP API quota exhaustion (LLM06 Excessive Agency)	Medium (D-1 mitigated but agent-unaware)	CEO / Hack23 AB	2026-04-28	2026-07-28	Risk: €50–€450 ALE (ARO 0.1–0.3/year, SLE €500–1.5k). Mitigation: ✅ Token bucket rate limiter (100/min); ⚠️ No per-session limits; ⚠️ No autonomous-agent detection. Acceptance Criteria: Residual risk acceptable given (1) rate limiting provides baseline DoS protection, (2) stdio transport limits abuse to single-process (no multi-client amplification), (3) cost of agent-fingerprinting + adaptive rate limiting (€8k–12k development effort) exceeds current ALE, (4) EP API has own rate limits (upstream protection). Compensating Controls: Monitor for sustained rate-limit denials (future: add `rate_limit_exceeded` audit event); future v2.0: per-session quotas for HTTP/SSE transport.

Risk Acceptance Governance

Governance Requirement	Implementation	Status
Acceptance Authority	CEO / Hack23 AB (per Risk Management Policy §4.3)	✅ Documented
Review Frequency	Quarterly (aligned with threat model review cycle)	✅ Scheduled 2026-07-28
Acceptance Criteria	(1) Mitigation cost > ALE, (2) Compensating controls in place, (3) Business justification documented	✅ Applied to all 3 risks
Re-Evaluation Triggers	(1) Control failure, (2) Threat landscape change, (3) New vulnerability disclosure, (4) Regulatory update	✅ Documented in Incident Response Plan

Next Scheduled Review: 2026-07-28 (quarterly review aligned with threat model refresh cycle per Hack23 Threat Modeling Policy §5).

📚 Related Documents

Document	Description	Link
🛡️ Security Architecture	Current security design and controls	SECURITY_ARCHITECTURE.md
🚀 Future Security Architecture	Planned security enhancements	FUTURE_SECURITY_ARCHITECTURE.md
🔮 Future Threat Model	Threat analysis for planned architecture evolution	FUTURE_THREAT_MODEL.md
🔄 Business Continuity Plan	Recovery objectives and procedures	BCPPlan.md
🛡️ CRA Assessment	EU Cyber Resilience Act conformity	CRA-ASSESSMENT.md
🏛️ Architecture	System architecture overview	ARCHITECTURE.md
📊 Data Model	Data structures and relationships	DATA_MODEL.md
🔒 Security Policy	Security reporting and disclosure	SECURITY.md

This threat model is maintained as part of the Hack23 AB ISMS framework.
Licensed under Apache-2.0

Uh oh!

FilesExpand file tree

THREAT_MODEL.md

Latest commit

History

THREAT_MODEL.md

File metadata and controls

🎯 European Parliament MCP Server — Threat Model

📑 Table of Contents

🔐 ISMS Policy Alignment

Related ISMS Policies

Security Control Implementation Status

Compliance Framework Mapping

🗺️ Security Documentation Map

🎯 Purpose & Scope

🌟 Transparency Commitment

📚 Framework Integration

🔍 Scope Definition

🔗 Policy Alignment

🎯 Multi-Strategy Threat Modeling Integration

Strategy Integration Summary

📊 System Classification & Operating Profile

🏷️ Security Classification Matrix

⚙️ Operating Profile

💎 Critical Assets & Crown Jewel Analysis

🎯 Critical Asset Inventory

💎 Crown Jewel Analysis

🛡️ Crown Jewel Protection Strategies

🎭 STRIDE Threat Analysis

S — Spoofing

T — Tampering

R — Repudiation

I — Information Disclosure

D — Denial of Service

E — Elevation of Privilege

🤖 OWASP LLM Top 10 (2025) — EP MCP Server Mapping

LLM Threat Matrix

New LLM-Class Threat Definitions

OWASP LLM → ISMS Policy Alignment

🔌 MCP-Protocol-Specific Threats (2025–2026 Research)

MCP Threat Catalog

MCP Protocol Attack Vectors

MCP-Specific ISMS Policy Alignment

🎖️ MITRE ATT&CK Coverage Analysis

ATT&CK Coverage Heat Map by Tactic

🏗️ Architecture-Centric STRIDE Analysis

🌊 Data Flow Threat Surface

🔍 STRIDE per Component Analysis

Component 1: MCP Server Core (Tool Dispatcher & Request Handler)

Component 2: EP API Client (HTTP Client & Response Parser)

Component 3: Cache Layer (In-Memory LRU Cache)

Component 4: Rate Limiter (Token Bucket Algorithm)

Component 5: Audit Logger (Structured stderr Logging)

Component 6: npm Package Distribution (package.json & dist/)

🏗️ Architecture-Aligned STRIDE — Per-Component Refresh

EP Sub-Clients (9 Components)

Core Infrastructure Components

Coverage Summary

🎖️ MITRE ATT&CK Mapping

ATT&CK → Security Control Mitigation Mapping

ATT&CK Navigator Visualization

🔗 Kill Chain Disruption Analysis

Kill Chain Phase → Defensive Control → Detection Mapping

Kill Chain Disruption Visualization

👥 Threat Agent Classification

Nation-State Actors

Hacktivist Groups

Insider Threats (Supply Chain)

Automated Threat Actors (Bots/Scrapers)

Competitor/Espionage Actors

Threat Actor Priority Matrix

🌐 Current Threat Landscape

ENISA Threat Landscape 2024 — Top Threats Mapped to EP MCP Server

EU Cyber Resilience Act (CRA) Context

Parliamentary Data Threat Context

Emerging Threat Vectors (2024-2025)

🎬 Scenario-Centric Threat Modeling (EP-Specific)

Scenario 1: Parliamentary Data Manipulation Attack

Scenario 2: MEP Personal Data Abuse (GDPR Violation)

Scenario 3: Electoral Influence via AI-Assisted Disinformation