Technical Initiative
Security Tooling
Lifecycle Phase
Sandbox / Early Stage (pre-incubation — the project is actively developed with a working release on npm and the Official MCP Registry, but has not yet formally joined any foundation)
Funding amount
$75,000
Problem Statement
AI agents are being deployed in production with direct access to filesystems, databases, cloud infrastructure, and internal APIs — but the security infrastructure to protect those connections does not exist. Each new integration protocol (MCP today, others tomorrow) creates a new perimeter surface that existing security tools were not designed to protect. The industry is repeating the early-2000s web security gap, but at machine speed: an AI agent can probe, exfiltrate, and pivot across your entire infrastructure in the time it takes a human to notice a single alert. MCP is the first and most urgent perimeter to secure, but it will not be the last. The goal is a unified enforcement plane that any AI-to-infrastructure connection flows through, regardless of protocol.
Who does this affect?
Every organization deploying AI agents in production that connect to external tools via MCP. This includes: Developers using Claude Code, Cursor, VS Code extensions, and other AI coding assistants that wire into MCP servers for filesystem access, database queries, cloud CLI execution, and code repository operations Enterprise security teams responsible for governing AI agent behavior across their infrastructure Open source maintainers publishing MCP servers on npm who need a standard security layer their users can deploy The broader MCP ecosystem which currently lacks a shared security vocabulary and testing benchmark
Have there been previous attempts to resolve the problem?
Several projects are addressing parts of the gap: MCPGuard provides basic allow/deny patterns for tool calls with a lightweight regex engine. It is simple and easy to understand but fundamentally limited — it cannot detect encoding evasion, semantic attacks, or cross-tool-chain exploits. It has no adversarial testing pipeline, no audit trail, and no closed-loop learning. Spyglass focuses on MCP traffic inspection and debugging, offering visibility after the fact but no runtime prevention. It is a monitoring tool, not an enforcement layer. Cloudflare AI Gateway and WSO2 AI Gateway operate at the network layer, adding authentication and routing for remote HTTP MCP servers, but they cannot protect local stdio servers — which constitute the majority of MCP deployments today — and they require sending traffic through a third-party gateway. Various sandboxing approaches isolate MCP server processes in containers or micro-VMs, but sandboxes cannot inspect tool call content for semantic attacks, and the agent must opt into them. The MCP Policy Proxy pattern published in several blog posts shows the right architectural direction but covers only basic rate limiting and regex patterns with no semantic analysis, no adversarial testing harness, and no learning loop. No existing open source project combines inline enforcement across all five MCP transports with three-layer detection (regex, schema, semantic), a comprehensive adversarial attack corpus with documented 100 percent block rate, closed-loop policy evolution, on-demand package trust scoring, and enterprise deployment support in a single deployable system.
Why should it be tackled now and by this TI?
The window for establishing security standards in the MCP ecosystem is closing rapidly. The protocol achieved widespread adoption in roughly 18 months — faster than REST. Every major AI coding client now wires into it. The number of unauthenticated servers nearly tripled in a three-month follow-up study. Each week without a standard enforcement layer means more production AI deployments operating with zero runtime protection. This is the right time because the ecosystem is still early enough that a single well-engineered open source reference implementation can establish the security patterns the community builds around — before fragmentation sets in. OpenSSF is the right home because this is fundamentally an open source infrastructure security problem: protecting the software supply chain of AI agent tooling, establishing a shared attack corpus as a community benchmark, and providing maintainers with a deployable security layer they don't have to build themselves.
Give an idea of what is required to make the funding initiative happen
The project already exists as working software. What grant funding enables is the transition from a solo-maintained project to a community-owned security standard.
-
Expand the adversarial attack corpus from 637 to 2,000+ fixtures through systematic red-teaming across all five MCP transports. This includes dedicated security researcher time for manual probe generation, automated LLM-based evasion generation, and a community submission pipeline. ($25,000)
-
Build enterprise compliance packs (SOC 2, HIPAA, PCI-DSS, NIST-CSF). Each framework requires mapping controls to policy rules, writing and testing YAML configurations, and documenting the mapping for auditors. ($15,000)
-
Ship the package trust scoring engine as a fully automated service. This extends an existing prototype into a GitHub Action and public web service that evaluates npm MCP packages for CVE posture, typo-squat risk, dependency confusion, and maintainer signals. ($10,000)
-
Recruit and onboard additional maintainers. Transition from solo to multi-maintainer governance. This includes drafting governance documents, establishing a rotating review schedule, and compensating initial contributors for their time during the transition. ($15,000)
-
Conference and community presence. Submit talk proposals to Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit. Publish deployment guides and case studies from early enterprise adopters. ($10,000)
Mastyf.ai is building the open-source perimeter security layer for AI infrastructure. We started with MCP because it is where the most CVEs are being disclosed today — over 40 in Q1–Q2 2026 — and where the widest gap exists between adoption and protection. But our architecture is protocol-agnostic: a six-phase enforcement pipeline (ingress, economics, policy, intelligence, upstream, egress) with three-layer detection that can be adapted to any AI-to-infrastructure interface.
Our vision is a unified security plane that protects every connection between AI agents and your infrastructure — MCP servers, API gateways, vector databases, model endpoints, data connectors — with consistent policy enforcement, adversarial validation, and audit. We started with MCP because that is where the ecosystem needs it most today, but the same pipeline applies everywhere AI agents touch production systems.
What is going to be needed to deliver this funding initiative?
Personnel:
Rudraneel Das (Project Lead) — full-time during grant period. Architects all core development, maintains CI pipeline, manages releases, oversees governance transition. Currently sole maintainer contributing full-time without compensation.
LinkedIn: https://www.linkedin.com/in/rudraneel-das-a0525a1a6
Sneharghya Roy (Security Research Lead) — part-time throughout grant period. Leads adversarial testing, attack corpus expansion, bypass probe generation, and CVE tracking.
LinkedIn: https://www.linkedin.com/in/sneharghya
One contract security researcher — dedicated 3-month sprint for systematic red-teaming across all five MCP transports to expand the attack corpus from 637 to 2,000+ fixtures.
Two part-time contributors to be recruited during the grant: one backend engineer for compliance packs and trust scoring engine, one community lead for documentation, deployment guides, and conference preparation.
Infrastructure:
Existing CI pipeline on GitHub Actions evaluates the full attack corpus on every PR. Currently runs 637 fixtures against every policy rule across Node.js and Python implementations. Scaling to 2,000+ fixtures will require additional runner minutes — estimated $200/month.
Trust scoring engine requires a small VM or serverless deployment for the public web service at mastyf.ai/certified — estimated $100/month.
Domain hosting (mastyf.ai), DNS, and npm package registry costs are minimal.
Deliverables schedule:
Month 1–2: Attack corpus expanded to 1,000 fixtures (depends on security researcher hired).
Month 2: SOC 2 compliance pack released (no dependencies).
Month 3–4: Attack corpus expanded to 1,500 fixtures (depends on corpus pipeline in place). HIPAA and PCI-DSS compliance packs released (depend on SOC 2 pack template).
Month 3: Trust scoring engine v1 shipped as GitHub Action (no dependencies).
Month 5–6: Attack corpus expanded to 2,000 fixtures (depends on red-teaming sprint complete). Two additional maintainers onboarded (depends on governance docs published).
Month 8: NIST-CSF compliance pack released (depends on prior pack patterns). Conference talk submissions submitted (depends on corpus and benchmark data).
Month 7–9: Enterprise deployment guides published (depends on beta deployments).
Month 12: Cumulative targets — 500+ GitHub stars, 50+ unique contributors, 10+ verified enterprise deployments (depends on all prior deliverables).
Success criteria:
- Attack corpus publicly available as MIT-licensed benchmark
- All four compliance packs released with test suites
- Trust scoring engine handling live queries at mastyf.ai/certified
- Multi-maintainer governance with published decision-making process
- At least one accepted conference talk
- 500+ GitHub stars, 50+ unique contributors, 10+ verified enterprise deployments
- Quarterly transparency report published with metrics and utilization
Are there tools or tech that still need to be produced to facilitate the funding initiative?
The core MCP enforcement layer is built and shipping — the six-phase Defense Fabric, three-layer detection engine, CI/Runtime swarm architecture, and 637-fixture attack corpus are all in production on npm and the Official MCP Registry. No foundational R&D remains on the MCP side.
What still needs to be produced to deliver the broader vision:
-
Protocol-agnostic adapter framework — The current pipeline is tightly coupled to MCP's JSON-RPC message format. To extend enforcement to other AI-infrastructure interfaces (API gateways, vector databases, model endpoints), the detection engine needs a transport abstraction layer that normalizes incoming calls into a common intermediate representation before policy evaluation. This is designed but not built.
-
Public attack corpus benchmark — The corpus currently lives inside the project's test suite. To function as an ecosystem-wide benchmark, it needs to be extracted into a standalone, MIT-licensed repository with a standardized fixture format that any security tool can consume — regardless of protocol.
-
Enterprise compliance packs — No SOC 2, HIPAA, PCI-DSS, or NIST-CSF configurations exist. Each requires mapping framework controls to policy rules, writing YAML, and building validation test suites.
-
Package trust scoring engine — A CLI prototype exists. The public-facing service with GitHub Action, SVG badge generator, and web UI needs to be built.
-
Governance infrastructure — No CONTRIBUTING.md, SECURITY.md, or CODE_OF_CONDUCT.md exists. Maintainer onboarding and decision-making charter need to be drafted.
Integration adapters — One-click setup for MCP clients (Claude Code, Cursor, VS Code) does not exist. Current setup requires manual configuration.
Everything listed is implementation work on a working architectural foundation — not research or invention.
Give a summary of the requirements that contextualize the costs of the funding initiative
The project already exists as working software published on npm with 637 attack fixtures, a three-layer detection engine, and enterprise deployment support. What grant funding enables is the transition from a solo-maintained project serving the MCP ecosystem to a community-owned, multi-protocol security standard for AI infrastructure. The $75,000 budget covers the specific work items required to achieve that transition:
Security researcher time ($25,000). Expanding the attack corpus from 637 to 2,000+ fixtures requires a dedicated 3-month red-teaming sprint across all five MCP transports. The current corpus was built incrementally by the project lead; reaching 2,000 fixtures with systematic transport-by-transport coverage, encoding variant enumeration, and cross-tool-chain attack patterns requires full-time researcher focus. This is the largest cost because the corpus is the project's fundamental asset — it validates every policy change, serves as the ecosystem benchmark, and is what distinguishes this project from basic allow-deny proxies.
Compliance pack development ($15,000). SOC 2, HIPAA, PCI-DSS, and NIST-CSF each require mapping dozens of controls to the 18 existing policy rules, writing YAML configurations that satisfy auditors, and building test suites that validate each pack against the full attack corpus. No compliance configurations exist today. This work is formulaic but labor-intensive — each framework takes 2–3 weeks of a TypeScript engineer familiar with both the control frameworks and the policy engine.
Trust scoring engine shipping ($10,000). The existing on-demand CLI prototype queries npm registry and OSV.dev data and outputs a letter grade. Productionizing this into a GitHub Action, a public web service with SVG badge generation, and a documented scoring methodology that the community can audit and improve requires focused engineering time.
Additional maintainer compensation ($15,000). The project is currently maintained by two founders with no external funding. Transitioning to multi-maintainer governance requires compensating initial contributors during the onboarding period — establishing review rotation, documenting processes, and building the contributor pipeline. This cost covers stipends for two part-time maintainers over 6 months.
Conference and community presence ($10,000). Establishing MCP security best practices in the industry requires presenting at Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit. This covers speaker travel, registration, and producing high-quality talk materials. Publishing deployment guides and case studies requires documentation engineering time.
All infrastructure costs (CI compute, hosting, domains) are not included in this request — they will continue to be covered out of pocket. The $75,000 funds only the personnel and direct costs of specific deliverables that transform this from a solo project into a community standard.
Who is responsible for doing the work of this funding initiative?
Rudraneel Das
Who is accountable for doing the work of this funding initiative?
Rudraneel Das
If the responsible or accountable parties are no longer available, what is the backup contact or plan?
If Rudraneel Das (project lead) is unavailable, Sneharghya Roy (co-founder and Security Research Lead) assumes project leadership. Sneharghya has full access to the codebase, npm publishing, CI pipeline, and the Official MCP Registry listing. He leads the security research track and adversarial testing pipeline, making him structurally positioned to maintain the core detection engine and corpus. If both founders are unavailable, the fallback plan depends on the grant phase: During grant period (months 1–6): The additional maintainers recruited and compensated through grant funding will have been onboarded with full context on the architecture, CI pipeline, governance processes, and release workflow. One will be designated as lead maintainer in the governance documents drafted in month 2. The project's decision-making charter will use a lazy consensus model, so no single person being unavailable blocks progress. Post-grant (months 7+): All code, documentation, governance documents, and CI infrastructure are fully open source and publicly accessible. The attack corpus is published as a standalone MIT-licensed benchmark. The trust scoring engine and compliance packs are documented and maintainable by any competent TypeScript engineer. The OpenSSF Technical Initiative structure provides an organizational backstop — the project can be adopted by another maintainer within the foundation if the original team steps away. The key architectural safeguard is that the detection engine is deterministic — no trained models, no opaque state, no runtime dependencies on external services. Any engineer familiar with TypeScript, regex, and AST parsing can understand and extend it without the original authors.
What license is this funding initiative being used under?
AGPL-3.0
Code of Conduct
List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.
The initiative will run for 12 months, divided into five milestone phases with payments tied to deliverable completion.
Months 1–2 (Foundation & Corpus Phase 1, $20,000). We hire a contract security researcher for a dedicated red-teaming sprint and expand the adversarial attack corpus from 637 to 1,000 fixtures. Governance documents (CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md) are drafted and published. The SOC 2 compliance pack is released with YAML configurations and a validation test suite. At the end of this phase, the project has public governance, a corpus of 1,000 fixtures, and its first enterprise compliance pack. Payment is made on delivery of these artifacts.
Months 3–4 (Expand & Compliance Phase 2, $20,000). The corpus is further expanded to 1,500 fixtures through continued red-teaming and automated evasion generation. HIPAA and PCI-DSS compliance packs are released, each with framework-specific policy mappings and test suites. The package trust scoring engine ships as a GitHub Action, allowing any developer to evaluate npm MCP packages from CI. Payment is tied to the verified corpus count, both compliance packs, and the working GitHub Action.
Months 5–6 (Scale & Maintain, $15,000). The corpus reaches 2,000 fixtures, covering all seven attack classes across all five MCP transports. Two additional maintainers are recruited, onboarded, and actively participating in review rotation. The governance structure moves from solo operation to multi-maintainer lazy consensus. Payment is made when the 2,000-fixture corpus is verified by CI and both maintainers have demonstrated independent contribution capability.
Months 7–9 (Enterprise & Community, $10,000). The NIST-CSF compliance pack is released, completing the four-pack suite. Enterprise deployment guides and case studies are published, documenting real-world latency, block rates, and configuration patterns from beta deployments. Conference talk proposals are submitted to Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit, with supporting benchmark data from the attack corpus. Payment is made on delivery of the compliance pack, published guides, and documented submissions.
Months 10–12 (Scale & Sustainability, $10,000). The full attack corpus is published as a standalone MIT-licensed benchmark repository that any security tool can consume independently. The public trust scoring service goes live at mastyf.ai/certified with SVG badge generation. Cumulative community targets are verified: 500+ GitHub stars, 50+ unique contributors, 10+ verified enterprise deployments. A quarterly transparency report is published documenting grant utilization, milestones reached, and community growth metrics. Payment is made when targets are verified and the transparency report is published.
Each payment follows LF Legal and Financial review of the completed deliverables. No payment is made before work is verified. The total budget across all five milestones is $75,000.
If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.
Mastyf.ai is an open-source MCP policy enforcement proxy published on npm as @mastyf_ai/server (v4.1.12) and listed on the Official MCP Registry at io.github.mastyf-ai/mastyf-ai. It intercepts every tool call across all five MCP transports (stdio, HTTP, SSE, streamable HTTP, WebSocket) through a six-phase Defense Fabric and a three-layer detection engine (regex/AST pattern matching in microseconds, schema validation in milliseconds, and optional LLM-based semantic review). The project currently ships with 637 adversarial attack fixtures across 21 categories, achieving a 1.0 F1 score with zero false positives — validated by a CI pipeline that enforces three gates on every pull request: 100% corpus block rate, zero benign false positives, and 100% detection parity between Node.js and Python implementations. The closed-loop learning system connects a CI Swarm (six agents running on every PR and nightly) with a Runtime Swarm (five agents operating in production on every tool call) through four automated feedback loops that evolve the detection engine without manual YAML. Enterprise deployment is supported through Helm charts with Postgres, Redis, OpenTelemetry, Prometheus, and three operational profiles (baseline, max-security, fast-path). The project is currently maintained by two founders with no external funding.
This SOW funds a 12-month transition to a community-owned security standard. Rudraneel Das (Project Lead, full-time) and Sneharghya Roy (Co-founder and Security Research Lead, part-time) will execute five milestones with support from a contract security researcher (3 months) and two additional part-time maintainers recruited during the grant period.
Milestone 1 (Months 1–2, $20,000) establishes the foundation. A contract security researcher is hired for a dedicated red-teaming sprint covering all five MCP transports systematically — stdio transport injection chains, HTTP header smuggling, SSE stream poisoning, WebSocket message fragmentation, and Streamable HTTP response splitting. The attack corpus expands from 637 to 1,000 fixtures. Specific targets: 20 new prompt injection variants targeting frontier model tool-call parsing, 30 shell obfuscation techniques including Unicode normalization bypasses and multi-byte encoding tricks, 25 SSRF probes covering cloud metadata endpoints across AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) with various protocol smuggling techniques, and 15 credential exfiltration patterns simulating real-world agent tool chains. Governance documents (CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md) are drafted with defined maintainer roles, a 24-hour vulnerability acknowledgement SLA, and a 90-day fix window. The SOC 2 compliance pack is released, mapping each of the 18 existing policy rules to SOC 2 trust service criteria — specifically, the sensitive path blocking rule maps to Logical and Physical Access Controls (CC6.1), the rate limiting rule maps to Monitoring Activities (CC7.2), and the audit logging rule maps to System Operations (CC7.1). Each mapping includes a YAML configuration and a validation test suite that confirms the pack blocks all relevant attack fixtures while passing all 55 benign fixtures.
Milestone 2 (Months 3–4, $20,000) expands and diversifies. The corpus reaches 1,500 fixtures through continued red-teaming and automated LLM-based evasion generation. The CI pipeline's Evasion agent is upgraded to generate 200 novel bypass probes per cycle using a frontier model, with each probe tested against the current policy and any bypass automatically added to the corpus as a permanent fixture. HIPAA and PCI-DSS compliance packs are released — HIPAA covers the Security Rule (administrative, physical, technical safeguards) with specific mappings for the access control rule (164.312.a.1) mapped to the RBAC policy rule, and the audit control rule (164.312.b) mapped to the structured audit logging phase. PCI-DSS covers Requirement 6 (develop and maintain secure systems) and Requirement 7 (restrict access by business need-to-know). The package trust scoring engine ships as a GitHub Action — it accepts an npm package name, queries the npm registry for metadata, checks OSV.dev for known CVEs (with severity-weighted scoring: CVSS 7.5+ deducts 60 points from a 100-point base), computes Levenshtein distance against a list of 10,000 known packages for typo-squat detection (threshold: distance <= 3), inspects dependency depth and publisher account age, and outputs a letter grade (A+ through F) with an optional SVG badge. The scoring methodology is documented so the community can audit and improve it.
Milestone 3 (Months 5–6, $15,000) scales the project. The corpus reaches 2,000 fixtures, including the first cross-tool-chain attack patterns — scenarios where a single prompt injection causes the agent to chain a filesystem read, a database query, and an HTTP exfiltration in sequence, with each step individually benign but the chain constituting an attack. Two additional maintainers are recruited from the contributor pool and onboarded through a structured program: they review the architecture documentation, shadow the CI pipeline for two weeks, submit three reviewed pull requests addressing real issues, and are added to the repository maintainer team with npm publishing and CI admin access. Governance transitions to a lazy consensus model where non-breaking changes can be merged after 72 hours without objection, and breaking changes require approval from at least two maintainers.
Milestone 4 (Months 7–9, $10,000) targets enterprise adoption. The NIST-CSF compliance pack is released, mapping the five core functions (Identify, Protect, Detect, Respond, Recover) to specific policy rules and detection phases — for example, the Protect function maps to the Ingress and Policy phases, the Detect function maps to the Intelligence phase with all three detection layers. Enterprise deployment guides are published covering three scenarios: single-server development setup, multi-server Fleet Hub deployment, and production Helm deployment with Redis-backed state and Postgres audit storage. Case studies from beta deployments document real-world latency at p50, p95, and p99 under various load patterns, block rates by attack category, and false positive rates. Conference talk proposals are submitted to Black Hat Arsenal (tool demonstration), OWASP Global AppSec (MCP threat model and detection methodology), and AI Security Summit (lessons from building production AI security infrastructure).
Milestone 5 (Months 10–12, $10,000) ensures sustainability. The full 2,000-fixture attack corpus is published as a standalone MIT-licensed benchmark repository with a documented fixture format (JSON schema including fixture ID, attack category, transport type, expected detection layer, expected outcome, and payload), a CLI runner that accepts any detection tool's output and computes precision, recall, and F1, and contribution guidelines for adding new fixtures. The public trust scoring service goes live at mastyf.ai/certified with a web UI that accepts npm package names and returns letter grades with detailed breakdowns, plus SVG badge generation for README embedding (40 badge variants across 8 styles and 5 embed formats — GitHub Markdown, HTML, reStructuredText, BBCode, and AsciiDoc). Community targets are verified at month 12: 500+ GitHub stars (measured by GitHub API), 50+ unique contributors (measured by GitHub Insights — individuals who have committed to any branch), and 10+ verified enterprise deployments (verified through published case studies, public references, or direct confirmation). A quarterly transparency report is published documenting grant utilization against budget, milestone completion status, corpus growth trajectory, community metrics, and any blockers or timeline adjustments.
Total funding request is $75,000. Each payment is made following LF Legal and Financial review of completed deliverables verified against objective acceptance criteria — corpus fixture count measured by CI, compliance packs validated by test suites passing at 100%, GitHub Action publishing verified by workflow run logs, and community targets confirmed by GitHub API snapshots. All work produced under this SOW is licensed under AGPL-3.0. The contractor retains ownership of background technology (existing codebase, CI pipeline, npm packages, registry listing), which is already available under the same license.
Technical Initiative
Security Tooling
Lifecycle Phase
Sandbox / Early Stage (pre-incubation — the project is actively developed with a working release on npm and the Official MCP Registry, but has not yet formally joined any foundation)
Funding amount
$75,000
Problem Statement
AI agents are being deployed in production with direct access to filesystems, databases, cloud infrastructure, and internal APIs — but the security infrastructure to protect those connections does not exist. Each new integration protocol (MCP today, others tomorrow) creates a new perimeter surface that existing security tools were not designed to protect. The industry is repeating the early-2000s web security gap, but at machine speed: an AI agent can probe, exfiltrate, and pivot across your entire infrastructure in the time it takes a human to notice a single alert. MCP is the first and most urgent perimeter to secure, but it will not be the last. The goal is a unified enforcement plane that any AI-to-infrastructure connection flows through, regardless of protocol.
Who does this affect?
Every organization deploying AI agents in production that connect to external tools via MCP. This includes: Developers using Claude Code, Cursor, VS Code extensions, and other AI coding assistants that wire into MCP servers for filesystem access, database queries, cloud CLI execution, and code repository operations Enterprise security teams responsible for governing AI agent behavior across their infrastructure Open source maintainers publishing MCP servers on npm who need a standard security layer their users can deploy The broader MCP ecosystem which currently lacks a shared security vocabulary and testing benchmark
Have there been previous attempts to resolve the problem?
Several projects are addressing parts of the gap: MCPGuard provides basic allow/deny patterns for tool calls with a lightweight regex engine. It is simple and easy to understand but fundamentally limited — it cannot detect encoding evasion, semantic attacks, or cross-tool-chain exploits. It has no adversarial testing pipeline, no audit trail, and no closed-loop learning. Spyglass focuses on MCP traffic inspection and debugging, offering visibility after the fact but no runtime prevention. It is a monitoring tool, not an enforcement layer. Cloudflare AI Gateway and WSO2 AI Gateway operate at the network layer, adding authentication and routing for remote HTTP MCP servers, but they cannot protect local stdio servers — which constitute the majority of MCP deployments today — and they require sending traffic through a third-party gateway. Various sandboxing approaches isolate MCP server processes in containers or micro-VMs, but sandboxes cannot inspect tool call content for semantic attacks, and the agent must opt into them. The MCP Policy Proxy pattern published in several blog posts shows the right architectural direction but covers only basic rate limiting and regex patterns with no semantic analysis, no adversarial testing harness, and no learning loop. No existing open source project combines inline enforcement across all five MCP transports with three-layer detection (regex, schema, semantic), a comprehensive adversarial attack corpus with documented 100 percent block rate, closed-loop policy evolution, on-demand package trust scoring, and enterprise deployment support in a single deployable system.
Why should it be tackled now and by this TI?
The window for establishing security standards in the MCP ecosystem is closing rapidly. The protocol achieved widespread adoption in roughly 18 months — faster than REST. Every major AI coding client now wires into it. The number of unauthenticated servers nearly tripled in a three-month follow-up study. Each week without a standard enforcement layer means more production AI deployments operating with zero runtime protection. This is the right time because the ecosystem is still early enough that a single well-engineered open source reference implementation can establish the security patterns the community builds around — before fragmentation sets in. OpenSSF is the right home because this is fundamentally an open source infrastructure security problem: protecting the software supply chain of AI agent tooling, establishing a shared attack corpus as a community benchmark, and providing maintainers with a deployable security layer they don't have to build themselves.
Give an idea of what is required to make the funding initiative happen
The project already exists as working software. What grant funding enables is the transition from a solo-maintained project to a community-owned security standard.
Expand the adversarial attack corpus from 637 to 2,000+ fixtures through systematic red-teaming across all five MCP transports. This includes dedicated security researcher time for manual probe generation, automated LLM-based evasion generation, and a community submission pipeline. ($25,000)
Build enterprise compliance packs (SOC 2, HIPAA, PCI-DSS, NIST-CSF). Each framework requires mapping controls to policy rules, writing and testing YAML configurations, and documenting the mapping for auditors. ($15,000)
Ship the package trust scoring engine as a fully automated service. This extends an existing prototype into a GitHub Action and public web service that evaluates npm MCP packages for CVE posture, typo-squat risk, dependency confusion, and maintainer signals. ($10,000)
Recruit and onboard additional maintainers. Transition from solo to multi-maintainer governance. This includes drafting governance documents, establishing a rotating review schedule, and compensating initial contributors for their time during the transition. ($15,000)
Conference and community presence. Submit talk proposals to Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit. Publish deployment guides and case studies from early enterprise adopters. ($10,000)
Mastyf.ai is building the open-source perimeter security layer for AI infrastructure. We started with MCP because it is where the most CVEs are being disclosed today — over 40 in Q1–Q2 2026 — and where the widest gap exists between adoption and protection. But our architecture is protocol-agnostic: a six-phase enforcement pipeline (ingress, economics, policy, intelligence, upstream, egress) with three-layer detection that can be adapted to any AI-to-infrastructure interface.
Our vision is a unified security plane that protects every connection between AI agents and your infrastructure — MCP servers, API gateways, vector databases, model endpoints, data connectors — with consistent policy enforcement, adversarial validation, and audit. We started with MCP because that is where the ecosystem needs it most today, but the same pipeline applies everywhere AI agents touch production systems.
What is going to be needed to deliver this funding initiative?
Personnel:
Rudraneel Das (Project Lead) — full-time during grant period. Architects all core development, maintains CI pipeline, manages releases, oversees governance transition. Currently sole maintainer contributing full-time without compensation.
LinkedIn: https://www.linkedin.com/in/rudraneel-das-a0525a1a6
Sneharghya Roy (Security Research Lead) — part-time throughout grant period. Leads adversarial testing, attack corpus expansion, bypass probe generation, and CVE tracking.
LinkedIn: https://www.linkedin.com/in/sneharghya
One contract security researcher — dedicated 3-month sprint for systematic red-teaming across all five MCP transports to expand the attack corpus from 637 to 2,000+ fixtures.
Two part-time contributors to be recruited during the grant: one backend engineer for compliance packs and trust scoring engine, one community lead for documentation, deployment guides, and conference preparation.
Infrastructure:
Existing CI pipeline on GitHub Actions evaluates the full attack corpus on every PR. Currently runs 637 fixtures against every policy rule across Node.js and Python implementations. Scaling to 2,000+ fixtures will require additional runner minutes — estimated $200/month.
Trust scoring engine requires a small VM or serverless deployment for the public web service at mastyf.ai/certified — estimated $100/month.
Domain hosting (mastyf.ai), DNS, and npm package registry costs are minimal.
Deliverables schedule:
Month 1–2: Attack corpus expanded to 1,000 fixtures (depends on security researcher hired).
Month 2: SOC 2 compliance pack released (no dependencies).
Month 3–4: Attack corpus expanded to 1,500 fixtures (depends on corpus pipeline in place). HIPAA and PCI-DSS compliance packs released (depend on SOC 2 pack template).
Month 3: Trust scoring engine v1 shipped as GitHub Action (no dependencies).
Month 5–6: Attack corpus expanded to 2,000 fixtures (depends on red-teaming sprint complete). Two additional maintainers onboarded (depends on governance docs published).
Month 8: NIST-CSF compliance pack released (depends on prior pack patterns). Conference talk submissions submitted (depends on corpus and benchmark data).
Month 7–9: Enterprise deployment guides published (depends on beta deployments).
Month 12: Cumulative targets — 500+ GitHub stars, 50+ unique contributors, 10+ verified enterprise deployments (depends on all prior deliverables).
Success criteria:
Are there tools or tech that still need to be produced to facilitate the funding initiative?
The core MCP enforcement layer is built and shipping — the six-phase Defense Fabric, three-layer detection engine, CI/Runtime swarm architecture, and 637-fixture attack corpus are all in production on npm and the Official MCP Registry. No foundational R&D remains on the MCP side.
What still needs to be produced to deliver the broader vision:
Protocol-agnostic adapter framework — The current pipeline is tightly coupled to MCP's JSON-RPC message format. To extend enforcement to other AI-infrastructure interfaces (API gateways, vector databases, model endpoints), the detection engine needs a transport abstraction layer that normalizes incoming calls into a common intermediate representation before policy evaluation. This is designed but not built.
Public attack corpus benchmark — The corpus currently lives inside the project's test suite. To function as an ecosystem-wide benchmark, it needs to be extracted into a standalone, MIT-licensed repository with a standardized fixture format that any security tool can consume — regardless of protocol.
Enterprise compliance packs — No SOC 2, HIPAA, PCI-DSS, or NIST-CSF configurations exist. Each requires mapping framework controls to policy rules, writing YAML, and building validation test suites.
Package trust scoring engine — A CLI prototype exists. The public-facing service with GitHub Action, SVG badge generator, and web UI needs to be built.
Governance infrastructure — No CONTRIBUTING.md, SECURITY.md, or CODE_OF_CONDUCT.md exists. Maintainer onboarding and decision-making charter need to be drafted.
Integration adapters — One-click setup for MCP clients (Claude Code, Cursor, VS Code) does not exist. Current setup requires manual configuration.
Everything listed is implementation work on a working architectural foundation — not research or invention.
Give a summary of the requirements that contextualize the costs of the funding initiative
The project already exists as working software published on npm with 637 attack fixtures, a three-layer detection engine, and enterprise deployment support. What grant funding enables is the transition from a solo-maintained project serving the MCP ecosystem to a community-owned, multi-protocol security standard for AI infrastructure. The $75,000 budget covers the specific work items required to achieve that transition:
Security researcher time ($25,000). Expanding the attack corpus from 637 to 2,000+ fixtures requires a dedicated 3-month red-teaming sprint across all five MCP transports. The current corpus was built incrementally by the project lead; reaching 2,000 fixtures with systematic transport-by-transport coverage, encoding variant enumeration, and cross-tool-chain attack patterns requires full-time researcher focus. This is the largest cost because the corpus is the project's fundamental asset — it validates every policy change, serves as the ecosystem benchmark, and is what distinguishes this project from basic allow-deny proxies.
Compliance pack development ($15,000). SOC 2, HIPAA, PCI-DSS, and NIST-CSF each require mapping dozens of controls to the 18 existing policy rules, writing YAML configurations that satisfy auditors, and building test suites that validate each pack against the full attack corpus. No compliance configurations exist today. This work is formulaic but labor-intensive — each framework takes 2–3 weeks of a TypeScript engineer familiar with both the control frameworks and the policy engine.
Trust scoring engine shipping ($10,000). The existing on-demand CLI prototype queries npm registry and OSV.dev data and outputs a letter grade. Productionizing this into a GitHub Action, a public web service with SVG badge generation, and a documented scoring methodology that the community can audit and improve requires focused engineering time.
Additional maintainer compensation ($15,000). The project is currently maintained by two founders with no external funding. Transitioning to multi-maintainer governance requires compensating initial contributors during the onboarding period — establishing review rotation, documenting processes, and building the contributor pipeline. This cost covers stipends for two part-time maintainers over 6 months.
Conference and community presence ($10,000). Establishing MCP security best practices in the industry requires presenting at Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit. This covers speaker travel, registration, and producing high-quality talk materials. Publishing deployment guides and case studies requires documentation engineering time.
All infrastructure costs (CI compute, hosting, domains) are not included in this request — they will continue to be covered out of pocket. The $75,000 funds only the personnel and direct costs of specific deliverables that transform this from a solo project into a community standard.
Who is responsible for doing the work of this funding initiative?
Rudraneel Das
Who is accountable for doing the work of this funding initiative?
Rudraneel Das
If the responsible or accountable parties are no longer available, what is the backup contact or plan?
If Rudraneel Das (project lead) is unavailable, Sneharghya Roy (co-founder and Security Research Lead) assumes project leadership. Sneharghya has full access to the codebase, npm publishing, CI pipeline, and the Official MCP Registry listing. He leads the security research track and adversarial testing pipeline, making him structurally positioned to maintain the core detection engine and corpus. If both founders are unavailable, the fallback plan depends on the grant phase: During grant period (months 1–6): The additional maintainers recruited and compensated through grant funding will have been onboarded with full context on the architecture, CI pipeline, governance processes, and release workflow. One will be designated as lead maintainer in the governance documents drafted in month 2. The project's decision-making charter will use a lazy consensus model, so no single person being unavailable blocks progress. Post-grant (months 7+): All code, documentation, governance documents, and CI infrastructure are fully open source and publicly accessible. The attack corpus is published as a standalone MIT-licensed benchmark. The trust scoring engine and compliance packs are documented and maintainable by any competent TypeScript engineer. The OpenSSF Technical Initiative structure provides an organizational backstop — the project can be adopted by another maintainer within the foundation if the original team steps away. The key architectural safeguard is that the detection engine is deterministic — no trained models, no opaque state, no runtime dependencies on external services. Any engineer familiar with TypeScript, regex, and AST parsing can understand and extend it without the original authors.
What license is this funding initiative being used under?
AGPL-3.0
Code of Conduct
List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.
The initiative will run for 12 months, divided into five milestone phases with payments tied to deliverable completion.
Months 1–2 (Foundation & Corpus Phase 1, $20,000). We hire a contract security researcher for a dedicated red-teaming sprint and expand the adversarial attack corpus from 637 to 1,000 fixtures. Governance documents (CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md) are drafted and published. The SOC 2 compliance pack is released with YAML configurations and a validation test suite. At the end of this phase, the project has public governance, a corpus of 1,000 fixtures, and its first enterprise compliance pack. Payment is made on delivery of these artifacts.
Months 3–4 (Expand & Compliance Phase 2, $20,000). The corpus is further expanded to 1,500 fixtures through continued red-teaming and automated evasion generation. HIPAA and PCI-DSS compliance packs are released, each with framework-specific policy mappings and test suites. The package trust scoring engine ships as a GitHub Action, allowing any developer to evaluate npm MCP packages from CI. Payment is tied to the verified corpus count, both compliance packs, and the working GitHub Action.
Months 5–6 (Scale & Maintain, $15,000). The corpus reaches 2,000 fixtures, covering all seven attack classes across all five MCP transports. Two additional maintainers are recruited, onboarded, and actively participating in review rotation. The governance structure moves from solo operation to multi-maintainer lazy consensus. Payment is made when the 2,000-fixture corpus is verified by CI and both maintainers have demonstrated independent contribution capability.
Months 7–9 (Enterprise & Community, $10,000). The NIST-CSF compliance pack is released, completing the four-pack suite. Enterprise deployment guides and case studies are published, documenting real-world latency, block rates, and configuration patterns from beta deployments. Conference talk proposals are submitted to Black Hat Arsenal, OWASP Global AppSec, and AI Security Summit, with supporting benchmark data from the attack corpus. Payment is made on delivery of the compliance pack, published guides, and documented submissions.
Months 10–12 (Scale & Sustainability, $10,000). The full attack corpus is published as a standalone MIT-licensed benchmark repository that any security tool can consume independently. The public trust scoring service goes live at mastyf.ai/certified with SVG badge generation. Cumulative community targets are verified: 500+ GitHub stars, 50+ unique contributors, 10+ verified enterprise deployments. A quarterly transparency report is published documenting grant utilization, milestones reached, and community growth metrics. Payment is made when targets are verified and the transparency report is published.
Each payment follows LF Legal and Financial review of the completed deliverables. No payment is made before work is verified. The total budget across all five milestones is $75,000.
If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.
Mastyf.ai is an open-source MCP policy enforcement proxy published on npm as
@mastyf_ai/server(v4.1.12) and listed on the Official MCP Registry atio.github.mastyf-ai/mastyf-ai. It intercepts every tool call across all five MCP transports (stdio, HTTP, SSE, streamable HTTP, WebSocket) through a six-phase Defense Fabric and a three-layer detection engine (regex/AST pattern matching in microseconds, schema validation in milliseconds, and optional LLM-based semantic review). The project currently ships with 637 adversarial attack fixtures across 21 categories, achieving a 1.0 F1 score with zero false positives — validated by a CI pipeline that enforces three gates on every pull request: 100% corpus block rate, zero benign false positives, and 100% detection parity between Node.js and Python implementations. The closed-loop learning system connects a CI Swarm (six agents running on every PR and nightly) with a Runtime Swarm (five agents operating in production on every tool call) through four automated feedback loops that evolve the detection engine without manual YAML. Enterprise deployment is supported through Helm charts with Postgres, Redis, OpenTelemetry, Prometheus, and three operational profiles (baseline, max-security, fast-path). The project is currently maintained by two founders with no external funding.This SOW funds a 12-month transition to a community-owned security standard. Rudraneel Das (Project Lead, full-time) and Sneharghya Roy (Co-founder and Security Research Lead, part-time) will execute five milestones with support from a contract security researcher (3 months) and two additional part-time maintainers recruited during the grant period.
Milestone 1 (Months 1–2, $20,000) establishes the foundation. A contract security researcher is hired for a dedicated red-teaming sprint covering all five MCP transports systematically — stdio transport injection chains, HTTP header smuggling, SSE stream poisoning, WebSocket message fragmentation, and Streamable HTTP response splitting. The attack corpus expands from 637 to 1,000 fixtures. Specific targets: 20 new prompt injection variants targeting frontier model tool-call parsing, 30 shell obfuscation techniques including Unicode normalization bypasses and multi-byte encoding tricks, 25 SSRF probes covering cloud metadata endpoints across AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) with various protocol smuggling techniques, and 15 credential exfiltration patterns simulating real-world agent tool chains. Governance documents (CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md) are drafted with defined maintainer roles, a 24-hour vulnerability acknowledgement SLA, and a 90-day fix window. The SOC 2 compliance pack is released, mapping each of the 18 existing policy rules to SOC 2 trust service criteria — specifically, the sensitive path blocking rule maps to Logical and Physical Access Controls (CC6.1), the rate limiting rule maps to Monitoring Activities (CC7.2), and the audit logging rule maps to System Operations (CC7.1). Each mapping includes a YAML configuration and a validation test suite that confirms the pack blocks all relevant attack fixtures while passing all 55 benign fixtures.
Milestone 2 (Months 3–4, $20,000) expands and diversifies. The corpus reaches 1,500 fixtures through continued red-teaming and automated LLM-based evasion generation. The CI pipeline's Evasion agent is upgraded to generate 200 novel bypass probes per cycle using a frontier model, with each probe tested against the current policy and any bypass automatically added to the corpus as a permanent fixture. HIPAA and PCI-DSS compliance packs are released — HIPAA covers the Security Rule (administrative, physical, technical safeguards) with specific mappings for the access control rule (164.312.a.1) mapped to the RBAC policy rule, and the audit control rule (164.312.b) mapped to the structured audit logging phase. PCI-DSS covers Requirement 6 (develop and maintain secure systems) and Requirement 7 (restrict access by business need-to-know). The package trust scoring engine ships as a GitHub Action — it accepts an npm package name, queries the npm registry for metadata, checks OSV.dev for known CVEs (with severity-weighted scoring: CVSS 7.5+ deducts 60 points from a 100-point base), computes Levenshtein distance against a list of 10,000 known packages for typo-squat detection (threshold: distance <= 3), inspects dependency depth and publisher account age, and outputs a letter grade (A+ through F) with an optional SVG badge. The scoring methodology is documented so the community can audit and improve it.
Milestone 3 (Months 5–6, $15,000) scales the project. The corpus reaches 2,000 fixtures, including the first cross-tool-chain attack patterns — scenarios where a single prompt injection causes the agent to chain a filesystem read, a database query, and an HTTP exfiltration in sequence, with each step individually benign but the chain constituting an attack. Two additional maintainers are recruited from the contributor pool and onboarded through a structured program: they review the architecture documentation, shadow the CI pipeline for two weeks, submit three reviewed pull requests addressing real issues, and are added to the repository maintainer team with npm publishing and CI admin access. Governance transitions to a lazy consensus model where non-breaking changes can be merged after 72 hours without objection, and breaking changes require approval from at least two maintainers.
Milestone 4 (Months 7–9, $10,000) targets enterprise adoption. The NIST-CSF compliance pack is released, mapping the five core functions (Identify, Protect, Detect, Respond, Recover) to specific policy rules and detection phases — for example, the Protect function maps to the Ingress and Policy phases, the Detect function maps to the Intelligence phase with all three detection layers. Enterprise deployment guides are published covering three scenarios: single-server development setup, multi-server Fleet Hub deployment, and production Helm deployment with Redis-backed state and Postgres audit storage. Case studies from beta deployments document real-world latency at p50, p95, and p99 under various load patterns, block rates by attack category, and false positive rates. Conference talk proposals are submitted to Black Hat Arsenal (tool demonstration), OWASP Global AppSec (MCP threat model and detection methodology), and AI Security Summit (lessons from building production AI security infrastructure).
Milestone 5 (Months 10–12, $10,000) ensures sustainability. The full 2,000-fixture attack corpus is published as a standalone MIT-licensed benchmark repository with a documented fixture format (JSON schema including fixture ID, attack category, transport type, expected detection layer, expected outcome, and payload), a CLI runner that accepts any detection tool's output and computes precision, recall, and F1, and contribution guidelines for adding new fixtures. The public trust scoring service goes live at mastyf.ai/certified with a web UI that accepts npm package names and returns letter grades with detailed breakdowns, plus SVG badge generation for README embedding (40 badge variants across 8 styles and 5 embed formats — GitHub Markdown, HTML, reStructuredText, BBCode, and AsciiDoc). Community targets are verified at month 12: 500+ GitHub stars (measured by GitHub API), 50+ unique contributors (measured by GitHub Insights — individuals who have committed to any branch), and 10+ verified enterprise deployments (verified through published case studies, public references, or direct confirmation). A quarterly transparency report is published documenting grant utilization against budget, milestone completion status, corpus growth trajectory, community metrics, and any blockers or timeline adjustments.
Total funding request is $75,000. Each payment is made following LF Legal and Financial review of completed deliverables verified against objective acceptance criteria — corpus fixture count measured by CI, compliance packs validated by test suites passing at 100%, GitHub Action publishing verified by workflow run logs, and community targets confirmed by GitHub API snapshots. All work produced under this SOW is licensed under AGPL-3.0. The contractor retains ownership of background technology (existing codebase, CI pipeline, npm packages, registry listing), which is already available under the same license.