You're pledging to donate if the project hits its minimum goal and gets approved. If not, your funds will be returned.
$38,000 left to reach the funding goal.
I maintain LLMSecTest, an open-source security test suite for applications built on large language models. It is a pytest plugin that attacks a running application along all ten categories of the OWASP Top 10 for LLM Applications in its 2025 edition and writes its findings as SARIF, the format GitHub and GitLab already read in their code-scanning views. It is MIT-licensed, the code is at github.com/wehnsdaefflae/llmsectest, the documentation at docs.llmsec.dev. It is funded by the German Federal Ministry through the Prototype Fund, funding code 16IS26S10, and that grant pays for building and shipping the tool.
What no grant pays for, and what I am asking for here, is finding out whether the tool's findings are true. The suite currently runs daily against 49 test applications I built myself on LangChain, LlamaIndex and Haystack, and the reports stand in public uncut. But those runs tell you what the tool reported, not what was actually there. Nobody has measured how often it reports a vulnerability that does not exist, and nobody has measured how often it walks past one that does. For a security tool that is the number that matters most, because a scanner with a bad false-negative rate does not merely fail, it hands the user a clean report and a false sense of safety.
This project produces that number and publishes it whichever way it comes out. I build a labelled corpus from the applications I already maintain, where each application carries a documented ground truth of which vulnerabilities were deliberately planted and which categories are deliberately clean, run the suite against it, and report precision and recall per OWASP category. An independent security reviewer, paid from this grant, audits the corpus design and the planted flaws before any numbers exist, so that the ground truth is not just my own opinion of what counts as a vulnerability.
The goal is a measured, published, reproducible false-positive and false-negative rate for an open-source LLM application security scanner, broken down by OWASP LLM category, together with the labelled corpus that produced it, so that anyone can repeat the measurement or run it against a different scanner.
There are five pieces of work, 500 hours in total over six months.
First, the corpus. I take the 49 test applications I already run the suite against daily and turn them into a labelled benchmark. Each application gets a machine-readable ground truth: which vulnerability was planted, in which component, reachable by which input, and which OWASP categories that application is deliberately clean on. Negative controls matter as much as positive ones, because a false-positive rate can only be measured against applications where there is nothing to find. I budget 180 hours here, and it is the largest line because labelling is the part that cannot be automated away.
Second, the measurement harness. A scoring layer that takes a SARIF report from a run and the ground truth for that application and computes true positives, false positives and false negatives per category, with the matching rule written down rather than hidden in code. The hard part is the matching rule: deciding when a finding that names a slightly different component than the planted flaw still counts as a hit. I will publish that rule separately and early, before the numbers exist, so people can argue with it while changing my mind is still free. 120 hours.
Third, the runs and the analysis. The suite across the corpus, repeated across several model families behind the applications, since a prompt-injection probe that works against one model may fail against another, and a recall number that holds for only one model is not a recall number. 100 hours plus the inference budget below.
Fourth, the external review. A security reviewer who is not me audits the corpus design, the planted flaws and the matching rule, and the audit is published alongside the results. This is the piece my current funder explicitly cannot cover; in my own Second Stage application I had to write that an independent security review does not fit into the funded work plan. 60 hours of my time to prepare for, respond to and act on the review, plus the reviewer's honorarium.
Fifth, publication. The corpus and ground truth archived with a DOI, the matching rule, the per-category numbers and a write-up of what the numbers mean for anyone relying on a scanner like this. 40 hours.
To be explicit about scope, because I am mid-term on another public grant for the same codebase: the Prototype Fund money pays for building the suite, shipping it to PyPI, writing CI templates and documenting it. The Second Stage I have applied for, if it is awarded, pays for adoption work — enterprise integration guides, compliance mapping, governance, outreach to the OWASP community, sustainability. Neither pays for measuring whether the findings are correct, and neither can, because validating my own tool against an externally reviewed ground truth is not a development work package. I can point at my own words to the German funder on this: in my Second Stage application I named an independent security review as one of three things the project needs and wrote that it no longer fits into the funded work plan. That is the gap this proposal fills. That is the whole of what I am asking Manifund to fund, and nothing in this proposal is work another funder is already paying for.
The project worked if, at the end of six months, five things exist in public and a stranger can check each one.
A labelled corpus, archived with a DOI, where every application carries its planted flaws and its clean categories in a machine-readable form. A written matching rule, published before the results. A precision and recall figure per OWASP LLM category, with the raw runs attached so the figures can be recomputed. An external reviewer's audit of the corpus and the rule, published as it was written and not as I would have preferred it. And a write-up that states plainly what the numbers imply, including the implications I would rather not have found.
It did not work if the only output is my own assertion that the tool is accurate. It also did not work if I publish numbers that nobody can recompute.
I want to be clear that a bad result is a successful project. If recall for a whole OWASP category turns out to be near zero, then using this class of tool as evidence of safety for that category is a mistake, and saying so publicly is worth more than another feature. I do not know which way the numbers go, and that is most of why I want to do it.
The total ask is USD 38,000 over six months of solo work. The minimum is USD 25,000.
My own time, 500 hours at USD 56 per hour: USD 28,000. The rate is the one my current grant's Second Stage calculation is based on, EUR 50 per hour, converted at an assumed 1.12 USD per EUR. There is no overhead or institutional surcharge on top, because I am a sole proprietor in Berlin with nobody between me and the funder.
Model inference for the runs across several model families: USD 4,000.
Sandbox compute and storage, for running the corpus in disposable containers and keeping the raw runs: USD 2,000.
Honorarium for the independent security reviewer who audits the corpus design and the matching rule: USD 2,500.
Archival and hosting of the corpus, the ground truth and the results so they outlive the grant: USD 1,000.
Contingency: USD 500.
That is USD 28,000 plus 4,000 plus 2,000 plus 2,500 plus 1,000 plus 500, which is USD 38,000.
At the minimum of USD 25,000 the shape changes rather than shrinking evenly, and the USD 13,000 difference comes off named lines. I cut my own hours from 500 to 350, which is 150 hours at USD 56, so USD 8,400, by labelling a smaller corpus — fewer applications, the same labelling standard. I cut model inference from USD 4,000 to USD 1,000, which means a single model family instead of several and a wider stated uncertainty on the numbers. I cut sandbox compute from USD 2,000 to USD 1,400, archival from USD 1,000 to USD 500, and the contingency from USD 500 to zero. That is 8,400 plus 3,000 plus 600 plus 500 plus 500, which is USD 13,000. The reviewer's honorarium survives the cut intact, because an externally reviewed ground truth is the part that makes the result worth anything, and between wider model coverage and the external review I would keep the review. What survives at the minimum is therefore the corpus, the matching rule, the external review, the measurement and the published per-category numbers.
It is just me. I am Dr. Mark Wernsdorfer, an independent AI researcher and developer in Berlin, working as a sole proprietor with no organisation, no host institution and no fiscal sponsor. My doctorate is in cognitive AI, Bamberg 2018. Alongside my own work I hold a half-time research position at FAU Erlangen-Nürnberg. My CV is at https://markwernsdorfer.com/mark-wernsdorfer-cv-en.pdf and my code at https://github.com/wehnsdaefflae.
The directly relevant track record is LLMSecTest itself, which is the subject of this proposal and is public: version 0.1.0 released on 10 June, all ten modules of the OWASP LLM Top 10 (2025) in operation with over a hundred red-team prompts, CVSS v4 scoring, local models through Ollama and LMStudio, supply-chain checking against OSV, embedding inversion and stress tests, and 49 test applications I built on LangChain, LlamaIndex and Haystack that are rescanned daily with the reports public and uncut. A reviewer can read the code, the commit history and the reports before deciding anything about me.
Before that I have delivered publicly funded software as a sole developer three times. SpotTheBot, a game for training people to recognise AI-generated text, funded by the German Federal Ministry of Education and Research together with the Open Knowledge Foundation Germany in 2023 and 2024. DoppelCheck, a local-first browser assistant for journalistic fact-checking, funded by Media Lab Bayern and the WPK Innovationsfonds, and a finalist for the International Award for Innovation in Journalism 2024. AMPEL, clinical decision support for laboratory medicine at the University Hospital Leipzig from 2019 to 2022. I also maintain terminal-control-mcp, an MCP server that puts a human and an agent inside the same live tmux session, which is the most externally noticed of my repositories.
Three things weigh against me and a regrantor should know them from me rather than find them. I have no public footprint in the AI safety community: no LessWrong posts, no EA Forum posts, no prior collaboration with any of the organisations whose evaluation work this project sits next to. My doctorate is in cognitive AI, not AI safety. And my open-source contributions outside my own repositories are bug reports rather than code: all of my public pull requests are in my own projects, and what I have filed into other people's are issues, in Keras in 2017, in swagger-codegen in 2017 and in a GNOME extension in 2023. I would rather state that than let it be discovered, and all three are checkable in ten seconds.
The most likely failure is the ground truth. A planted vulnerability is my own construct, and if my idea of what counts as a planted flaw is idiosyncratic, then the precision and recall numbers measure my taste rather than the tool. That is exactly why the external review comes before the numbers and why the matching rule is published early and separately. If the reviewer tells me the corpus design is unsound, the honest outcome is a published corpus design, a published critique, and no headline numbers — a worse result than I want, but not a wasted one.
The second failure mode is that the corpus is too easy. If every planted flaw is the kind of thing the suite was explicitly written to find, recall will come out flattering and meaningless. The defence is the negative controls and the clean categories, and planting flaws whose shape I did not design a probe for, but I cannot fully escape the fact that the person labelling the corpus is the person who wrote the scanner. I will say so in the write-up, and the labelled corpus being public means someone else can plant harder flaws into it and rerun the measurement, which is a large part of why the corpus is a deliverable at all.
The third is non-determinism. The applications are driven by language models, so a probe can succeed on one run and fail on the next, and a single pass gives a recall figure with no error bar. The mitigation is repeated runs across model families, which is what the inference budget buys; if funding lands at the minimum, the numbers come with a wider stated uncertainty and fewer models, and I will present them that way rather than pretending to a precision I did not pay for.
The fourth is me. I am one person with a half-time position elsewhere and another grant running on the same codebase. If I misjudge the labelling effort, the corpus shrinks before the measurement does — I would rather publish a smaller corpus measured properly than a large one measured badly.
One grant, running: the Prototype Fund Round 02, funding code 16IS26S10, financed by the German Federal Ministry of Research, Technology and Space through a funding guideline implemented by the Open Knowledge Foundation Germany, with VDI/VDE-IT as project agency. The funded phase for LLMSecTest is calculated as 481 hours at EUR 99 per hour plus five percent overhead, and it runs to the end of November, when version 1.0 is due on PyPI. That grant covers building and shipping the tool.
Pending, undecided: I applied for the Prototype Fund Second Stage on 28 September 2026, which would fund up to 633 further hours of adoption work on the same codebase — enterprise integration guides, compliance mapping, governance and outreach — and not the validation work proposed here. I also have an application with the EA Funds Transformative AI Fund for cross-model longitudinal security measurement with the shipped tool, which asks a different question from this one: it measures how model versions change over time, whereas this project measures whether the tool's findings are correct at all. If either is awarded I will say so on this page, and if the Transformative AI Fund award would make any part of this budget redundant I will reduce the ask accordingly rather than hold both.
Declined, for completeness: four earlier pitches to the Long-Term Future Fund were turned down on 31 July 2026. Each of them proposed building a new artefact. This one does not; it measures an artefact that already exists.
This is the only project I have on Manifund.
There are no bids on this project.