European Parliament MCP Server API - v1.1.26
    Preparing search index...

    Hack23 AB Logo

    πŸ” Hack23 AB β€” European Parliament MCP Server Security Policy

    πŸ›‘οΈ Security Through Transparency and Excellence
    🎯 Security-first API development with verifiable compliance

    Owner Version Effective Date Review Cycle OpenSSF Best Practices

    πŸ“‹ Document Owner: CEO | πŸ“„ Version: 1.0 | πŸ“… Last Updated: 2026-02-26 (UTC)
    πŸ”„ Review Cycle: Quarterly | ⏰ Next Review: 2026-05-26


    Current security state as of 2026-02-26:

    Metric Status Value
    πŸ§ͺ Test Suite βœ… Passing 1396 tests across 54 test files (docs/test-results/results.json)
    πŸ”’ npm audit βœ… Clean 0 vulnerabilities
    πŸ“œ License compliance βœ… Passing All MIT/ISC/Apache-2.0
    πŸ›οΈ SLSA Level 3 βœ… Achieved Cryptographic provenance on all releases
    πŸ” SAST (CodeQL) βœ… Enabled Automated on every PR and push
    πŸ”‘ Secret scanning βœ… Enabled GitHub native secret detection
    πŸ“¦ SBOM βœ… Published SPDX + CycloneDX on every release
    πŸ” Sigstore βœ… Enabled npm package and GitHub release artifacts

    At Hack23 AB, we are committed to maintaining the highest standards of security in all our projects. The European Parliament MCP Server implements comprehensive security measures aligned with our Information Security Management System (ISMS), providing verifiable transparency and demonstrating security excellence for sensitive European Parliament data access.

    This MCP server provides access to European Parliament datasets, including:

    • Parliamentary proceedings - Legislative activities, debates, votes
    • Member information - MEP profiles, committee memberships
    • Legislative documents - Proposals, amendments, reports
    • Historical data - Archive access to parliamentary records

    As such, this server implements enhanced security controls to ensure:

    • πŸ”’ GDPR Compliance - Personal data protection for MEP information
    • πŸ‡ͺπŸ‡Ί EU Data Sovereignty - Appropriate handling of EU institutional data
    • πŸ” Data Integrity - Immutable audit trails for all API access
    • πŸ“Š Transparency - Public accountability for institutional data access

    All security practices in this repository are governed by our publicly available ISMS policies:

    Policy Purpose Link
    πŸ” Information Security Policy Overarching security governance and principles View Policy
    πŸ› οΈ Secure Development Policy SDLC, testing, deployment, and CI/CD requirements View Policy
    πŸ“¦ Open Source Policy Open source usage, license compliance, supply chain security View Policy
    🏷️ Data Classification Policy Data sensitivity levels, handling requirements View Policy
    πŸ”’ Privacy Policy Personal data protection, GDPR compliance View Policy
    πŸ”‘ Access Control Policy Authentication, authorization, identity management View Policy

    This project is under active development, and we provide security updates for the latest version only. Please ensure you're using the latest version of the project to receive security updates.

    Version Supported Node.js Compatibility
    latest :white_check_mark: Node.js 25.x

    This MCP server implements comprehensive security measures aligned with our Secure Development Policy and Open Source Policy:

    • πŸ›‘οΈ Static Analysis (SAST) - CodeQL scanning for vulnerabilities

    • πŸ•·οΈ Dynamic Analysis (DAST) - OWASP ZAP security testing

    • πŸ“‹ Code Quality - ESLint with TypeScript rules

    • πŸ† OSSF Scorecard - Supply chain security assessment

    • πŸ” Dependency Review - Automated dependency vulnerability checks

    • πŸ“œ License Compliance - Automated license checking

      • Policy: Open Source Policy
      • Approved Licenses: MIT, Apache-2.0, BSD variants, ISC, CC0-1.0, Unlicense
    • πŸ“„ SBOM Generation - Software Bill of Materials in SPDX format

    • πŸ“Š SBOM Quality Validation - Automated quality scoring with SBOMQS

    • 🏷️ Pinned Dependencies - All GitHub Actions pinned to SHA hashes

    • πŸ” SLSA Provenance - Build attestations for artifact verification

    • πŸ›‘οΈ Immutable Releases - Release artifacts cannot be tampered with

    • πŸ” Artifact Signing - Cryptographic proof of build integrity

    • πŸ“¦ npm Provenance - Build transparency for npm packages

      • Policy: Open Source Policy
      • Package: european-parliament-mcp-server
      • Verification: npm audit signatures
      • Documentation: NPM_PUBLISHING.md
      • Features:
        • βœ… Cryptographic provenance for every published version
        • βœ… Transparent build process via GitHub Actions
        • βœ… SLSA Level 3 compliance for npm packages
        • βœ… Verifiable with npm audit signatures
      • Algorithm: SHA-256 cryptographic hashing
    • βœ… Unit Testing - Comprehensive test coverage

      • Policy: Secure Development Policy
      • Minimum Coverage: 80% line coverage, 70% branch coverage
      • Framework: Jest, Vitest, or Node.js test runner
    • 🌐 Integration Testing - API endpoint testing

      • Policy: Secure Development Policy
      • Focus: MCP protocol compliance, European Parliament API integration
      • Tools: Supertest, API testing frameworks
    • πŸ”’ Security Testing - Dedicated security test suites

      • Authentication/authorization tests
      • Input validation and sanitization tests
      • Rate limiting and DoS protection tests
      • GDPR compliance tests (data minimization, right to erasure)
    • πŸ”’ Rate Limiting - Protection against abuse and DoS attacks

      • Policy: Information Security Policy
      • Implementation: Express rate-limit or similar middleware
      • Thresholds: Configurable per-endpoint limits
    • πŸ›‘οΈ Input Validation - Comprehensive request validation

      • Policy: Secure Development Policy
      • Tools: Joi, Yup, or Zod schema validation
      • Protection: SQL injection, XSS, command injection prevention
    • πŸ” Authentication & Authorization - MCP protocol security

      • Policy: Access Control Policy
      • Implementation: OAuth2/OIDC support for client authentication
      • Principle: Least privilege access to European Parliament data
    • πŸ“ Audit Logging - Comprehensive API access logging

      • Policy: Information Security Policy
      • Coverage: All API requests, authentication events, errors
      • Retention: Compliant with EU data retention requirements
    • πŸ”’ Runner Hardening - All CI/CD runners hardened with audit logging

    • 🚨 Security Advisories - Private vulnerability disclosure

    • πŸ” Data Minimization - Only collect necessary European Parliament data

      • Policy: Privacy Policy
      • Implementation: API endpoints filter unnecessary personal data
    • πŸ—‘οΈ Right to Erasure - Support for data deletion requests

      • Policy: Privacy Policy
      • Process: AuditLogger.eraseByUser(userId, authToken) removes all in-memory entries for a data subject (GDPR Art. 17). Entries flushed to durable sinks must be erased separately via those sinks.
    • πŸ”’ Data Protection by Design - Privacy-enhancing technologies

      • Policy: Privacy Policy
      • Implementation: Encryption at rest and in transit, anonymization where applicable
    • πŸ“‹ GDPR Compliance Documentation

      • Data Protection Impact Assessment (DPIA) for high-risk processing
      • Records of processing activities (ROPA)
      • Data breach notification procedures

    ISMS Policy AU-002 (Audit Logging and Monitoring) β€” all MCP tool invocations and EP API data-access events are recorded in a structured, GDPR-compliant audit trail.

    Component Description
    AuditLogger Central logger; writes to an always-on MemoryAuditSink plus zero or more extra sinks
    MemoryAuditSink In-process buffer; supports query(filter) and eraseByUser(userId)
    StderrAuditSink Default extra sink; emits [AUDIT] <json> to stderr (MCP-compatible)
    FileAuditSink Appends NDJSON to a file; rotates when the file reaches maxSizeBytes
    StructuredJsonSink Passes serialised JSON to a caller-supplied writer (CloudWatch, Elastic, …)
    RetentionPolicy Filters entries older than maxAgeMs on every getLogs() / queryLogs() call
    Control Mechanism
    PII Protection sanitizeParams() redacts top-level keys in DEFAULT_SENSITIVE_KEYS (name, email, fullName, address, firstName, lastName, phone) before any entry is stored
    Access Control requiredAuthToken constructor option gates getLogs(), queryLogs(), eraseByUser(), and clear() behind an authorization token; unauthorized calls throw immediately
    Data Retention retentionMs constructor option enforces a configurable maximum age; expired entries are excluded from all query results
    Right to Erasure eraseByUser(userId, authToken) removes all in-memory entries for a given data subject (GDPR Art. 17)
    Append-only sinks FileAuditSink appends using async fs.appendFile (append-only writes); MemoryAuditSink.clear() is publicly exposed but is intended to be used via AuditLogger.clear(), which enforces authorization via checkAuthorization
    No stdout pollution All sinks write to stderr or external systems; stdout is reserved for the MCP protocol
    import { AuditLogger, FileAuditSink } from 'european-parliament-mcp-server';

    const requiredAuthToken = process.env['AUDIT_READ_TOKEN'];

    if (!requiredAuthToken) {
    throw new Error('AUDIT_READ_TOKEN environment variable must be set to enable secure audit log access.');
    }

    const logger = new AuditLogger({
    // Persist to file with automatic log rotation at 50 MiB
    sinks: [new FileAuditSink({ filePath: '/var/log/ep-mcp-audit.ndjson', maxSizeBytes: 50 * 1024 * 1024 })],
    // Enforce 90-day data retention (GDPR Art. 5(1)(e))
    retentionMs: 90 * 24 * 60 * 60 * 1000,
    // Require an auth token to read or erase audit logs
    requiredAuthToken,
    // Extend the default set of redacted keys
    sensitiveKeys: ['name', 'email', 'fullName', 'address', 'mepPrivateEmail'],
    });

    The audit logging subsystem is security-critical and maintains 100% statement, branch, function, and line coverage (src/utils/auditLogger.ts and src/utils/auditSink.ts).


    We take the security of the European Parliament MCP Server project seriously. If you have found a potential security vulnerability, we kindly ask you to report it privately, so that we can assess and address the issue before it becomes publicly known.

    Our vulnerability management process is governed by our Information Security Policy and follows industry best practices for responsible disclosure.

    A vulnerability is a weakness or flaw in the project that can be exploited to compromise the security, integrity, or availability of the system or its data. Examples of vulnerabilities include, but are not limited to:

    • πŸ”“ Unauthenticated access to sensitive European Parliament data
    • πŸ’‰ Injection attacks (SQL injection, NoSQL injection, command injection)
    • πŸ” Authentication/authorization bypass in MCP protocol implementation
    • 🌐 API security issues (rate limit bypass, parameter manipulation)
    • πŸ”’ Cryptographic weaknesses (weak algorithms, improper key management)
    • πŸ“Š GDPR violations (unauthorized data exposure, insufficient data protection)
    • ⚑ Denial of service vulnerabilities in API endpoints
    • πŸ”— Supply chain attacks through compromised dependencies

    Please follow these steps to privately report a security vulnerability:

    1. On GitHub.com, navigate to the main page of the European-Parliament-MCP-Server repository.
    2. Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
    3. In the left sidebar, under "Reporting", click Advisories.
    4. Click Report a vulnerability to open the advisory form.
    5. Fill in the advisory details form. Provide as much information as possible to help us understand and reproduce the issue:
      • Title: Brief description of the vulnerability
      • Description: Detailed explanation including:
        • Affected components (API endpoints, authentication, etc.)
        • Steps to reproduce
        • Potential impact (especially GDPR/data protection concerns)
        • Suggested mitigation (if any)
      • Severity: Your assessment of the vulnerability severity
      • CVE ID: If already assigned
    6. At the bottom of the form, click Submit report.

    After you submit the report, the maintainers of the European-Parliament-MCP-Server repository will be notified. They will review the report, validate the vulnerability, and take necessary actions to address the issue. You will be added as a collaborator and credited for the security advisory.

    Upon receipt of a vulnerability report, our team will:

    1. Acknowledge the report within 48 hours
    2. Validate the vulnerability within 7 days
    3. Assess GDPR/data protection implications within 7 days
    4. Develop and release a patch or mitigation within 30 days, depending on the complexity and severity of the issue
    5. Publish a security advisory with a detailed description of the vulnerability and the fix
    6. Notify affected users if there is a potential data breach (as required by GDPR)

    We appreciate your effort in helping us maintain a secure and reliable project. If your report results in a confirmed security fix, we will recognize your contribution in the release notes and/or a public acknowledgment, unless you request to remain anonymous.


    • πŸ›‘οΈ Security Headers - Security headers implementation for API responses
    • πŸ“– README.md - Project overview with security features
    • πŸ€– Copilot Agents - AI-assisted secure development
    • 🎯 Copilot Skills - Specialized security and compliance skills

    All security practices are governed by our publicly available ISMS:



    πŸ“‹ Document Control:
    βœ… Approved by: James Pether SΓΆrling, CEO
    πŸ“€ Distribution: Public
    🏷️ Classification: Confidentiality: Public
    πŸ“… Effective Date: 2026-02-26
    ⏰ Next Review: 2026-05-26
    🎯 Framework Compliance: ISO 27001 NIST CSF 2.0 CIS Controls AWS Well-Architected GDPR Compliant


    Thank you for helping us keep the European Parliament MCP Server and its users safe.

    Part of Hack23 AB's commitment to transparency and security excellence


    Input Validation: All tool parameters validated with Zod schemas

    • Country codes: ISO 3166-1 alpha-2 format
    • Dates: YYYY-MM-DD format
    • Keywords: Alphanumeric + spaces/hyphens only

    Rate Limiting: 100 requests per 15 minutes per IP address

    Output Sanitization: Error messages sanitized to prevent information disclosure

    Threats Addressed:

    • βœ… Injection attacks β†’ Zod validation
    • βœ… DoS attacks β†’ Rate limiting
    • βœ… Data exfiltration β†’ Audit logging
    • βœ… Information disclosure β†’ Error sanitization

    πŸ”’ Complete security architecture β†’

    • [x] Input validation (Zod schemas)
    • [x] Rate limiting (Token bucket)
    • [x] Audit logging (All requests)
    • [x] Error sanitization
    • [x] HTTPS only
    • [x] No secrets in code
    • [x] GDPR compliance

    πŸ“‹ Complete security guide β†’