--- title: "Roadmap: MCP Security Sprint — 4 domains, 10 chantiers (DELIVERED ✅)" description: "Hardening sprint DELIVERED May 9, 2026 on arleo.eu MCP infrastructure: 10 chantiers across 4 domains, hugo-mcp v1.9.0 published. Archive page." url: "https://www.arleo.eu/en/posts/roadmap-sprint-securite-mcp/" language: "en" datePublished: "2026-05-09T13:07:33+02:00" dateModified: "2026-05-15T23:51:25+02:00" tags: ["roadmap","security","mcp","hardening"] categories: ["roadmap"] contentSignal: "ai-train=no, search=yes, ai-input=yes" --- # Roadmap: MCP Security Sprint — 4 domains, 10 chantiers (DELIVERED ✅) Hardening sprint DELIVERED May 9, 2026 on arleo.eu MCP infrastructure: 10 chantiers across 4 domains, hugo-mcp v1.9.0 published. Archive page. ## Status: ✅ DELIVERED — sprint closed on May 9, 2026 **Update May 9, 2026 (end of session)**: all 10 chantiers delivered in a single marathon session, **and all 3 coordinated releases published the same day** (`hugo-mcp` v1.9.0, `mcp-oauth-proxy` v2.1.0, `mcp-installer` v1.3.0). Every component of the MCP ecosystem hardened in one day. Full technical recap: [MCP security sprint delivered: v1.9.0, 10 chantiers, hardened ecosystem](/en/posts/sprint-securite-mcp-livre/). This page stays published as an archive — to show the trajectory of an announced sprint, then kept. All original content below is preserved. --- ## Original status (pre-delivery) This page publicly documented an ongoing hardening sprint on arleo.eu's MCP infrastructure. For security reasons, specific details of each chantier were not exposed until fixes were delivered ("sec-first" philosophy: don't publish an attack roadmap). ## Why this transparency I debated whether to publish this page. Arguments for transparency: - **Public commitment** = healthy pressure on yourself to deliver - **Documentation** of a homelab whose goal is to learn and share - **Honesty** with readers consuming other technical articles Arguments against: - **Attack roadmap**: if I precisely list what's not yet protected, I give clues to a patient attacker - **Artificial pressure**: announcing a sprint then not delivering = worse than announcing nothing Adopted compromise: publish the **direction** and **hardening domains** without specifying what's weak today. Specific technical detail published on delivery. ## Sprint scope The sprint covered 10 chantiers grouped into 4 domains: ### 1. Application hardening (FastAPI + Pydantic) Reinforcement of MCP entry layers: strict input validation, unified error handling, no information leak in responses (stack traces, internal paths, lib versions). ### 2. Authentication and tokens Refactor of MCP access token management: lifetime, rotation, revocation, hashing in storage. Allow cutting off a compromised client's access without redeploying the service. ### 3. Observability and audit Integration of JSON structured logs ingested in BetterStack via Vector. Each MCP call must produce a traceable event: who, what, when, duration, status. Enables anomaly detection in near real-time. ### 4. Infrastructure and resilience TLS for internal traffic between NUC and VM, dedicated ModSec rules on the `/mcp` path, disaster recovery runbook (token theft, server compromise, data loss). ## What was already in place before the sprint To not create false impressions, here are the layers **already in place** on infrastructure before the sprint (so out of scope): - nginx + mandatory TLS 1.3 (Mozilla Modern config) - Cloudflare WAF + Bot Management + IP whitelist - ModSecurity + OWASP CRS 4.x on all vhosts - CrowdSec in WAF mode + Cloudflare bouncer - systemd hardening at level 1.7 (cf. [systemd hardening](/en/posts/hardening-systemd-mcp/)) - HMAC validation on webhooks - Frontmatter Pydantic validation (1 chantier of 4 in the validation category) The sprint aimed to **complete** this base, not replace it. ## Method For each chantier: 1. Implemented locally + unit tests 2. Validated on `mcp-test-vm` (pre-prod VM) 3. Deployed to prod only after passing tests 4. Structured JSON audit log for deployment traceability 5. Post-mortem or technical write-up published **after** delivery No direct prod deployment without pre-prod step. ## Published releases {{< mermaid-svg hash="807b96b4" >}} 3 coordinated releases planned, **all delivered the same day**: | Component | Version | Status | |-----------|---------|--------| | `hugo-mcp` | v1.9.0 | ✅ Published | | `mcp-oauth-proxy` | v2.1.0 | ✅ Published | | `mcp-installer` | v1.3.0 | ✅ Published | See the [victory recap](/en/posts/sprint-securite-mcp-livre/) for details. All commits are GPG-signed, fingerprint `33133FBFAFFFCA48AFFD3953E34BC7955D46431A`: - [github.com/jmrGrav/hugo-mcp v1.9.0](https://github.com/jmrGrav/hugo-mcp/releases/tag/v1.9.0) - [github.com/jmrGrav/mcp-oauth-proxy v2.1.0](https://github.com/jmrGrav/mcp-oauth-proxy/releases/tag/v2.1.0) - [github.com/jmrGrav/mcp-installer v1.3.0](https://github.com/jmrGrav/mcp-installer/releases/tag/v1.3.0) ## ETA (historical) Started May 9, 2026. Planned ETA: late May 2026. **Actual**: full delivery on **May 9, 2026 same day**, in a marathon session. ## Why now Several converging triggers: - Internal audit of v1.6.0/v1.7.0/v1.8.1 code identified specific gaps (without going into details here) - Several benign incidents highlighted operational blind spots (cf. [MCP timeouts post-mortem](/en/posts/postmortem-mcp-timeouts-cloudflare/), [Cloudflare Bot Mgmt post-mortem](/en/posts/postmortem-cf-bot-blocking-mcp/)) - The Webhook Git Strategy 4 project (cf. [webhook git roadmap](/en/posts/roadmap-webhook-git-rebuild/)) needs several sprint primitives (rate limiting, audit logs, strict validation) before being implemented Aligning security chantiers with short-term need = good ROI. ## Commitment kept The compromise announced before the sprint (sec-first, transparency on direction, details on delivery) was kept. No specific information about pre-sprint vulnerabilities was published until fixes were in prod. Full recap: [MCP security sprint delivered](/en/posts/sprint-securite-mcp-livre/). ## Tags - roadmap - security - mcp - hardening ## Categories - roadmap