Ronin Hub: The Bug Bounty Command Center
AI bug bounty programs are a lot of work. Every frontier lab runs one. The bounties are real. The competition is fierce. And most researchers we know are tracking their submissions in a spreadsheet that works until it does not. Ronin Hub is the workspace we built for the researchers on our team. 12 programs, 4 tabs, one pipeline from research to disclosure. Day 12 of the DojoLM builder's journal.

AI bug bounty programs are a lot of work. Every frontier lab now runs one. OpenAI, Anthropic, Google, Meta, Microsoft, plus several smaller labs. The bounties are real. The competition is fierce. And most researchers are tracking their submissions in a spreadsheet.
"Three programs are open right now. Nobody can remember which program got the Cyrillic homoglyph finding."
"The spreadsheet has 40 rows. Half of them are duplicates because two researchers on the team submitted the same payload to different programs."
"A finding went out two weeks ago. The program's disclosure window is 60 days. Last year, a deadline was missed on another finding because nobody tracked the clock."
"A program updated its scope last week. Nobody noticed. Active research on that program is now out of scope and has to start over."
"The best researcher on the team keeps all the context in her head. When she took a vacation, three submissions stalled because nobody else could trace the evidence."
A spreadsheet is fine until you are working three programs at once, and the same payload is a duplicate on one, eligible on another, and in a gray area on a third. Or until a program quietly updates its scope and half of the active research is suddenly out of scope. Or until a reviewer needs the chain of evidence connecting a finding to its underlying attack pattern, and the chain lives in 14 different tabs of a workbook nobody else can read.
Yesterday's post walked through multilingual detection. Today opens Ronin Hub, the workspace built so researchers could stop fighting their spreadsheets and start fighting the actual attack surface.
What Ronin Hub Is
Ronin Hub is DojoLM's bug bounty command center. It tracks programs, submissions, research plans, and intelligence feeds in a single workspace. Four tabs. 12 programs currently tracked on the production instance. A direct pipeline from research to submission to disclosure, and from accepted disclosure back into the Armory as a new fixture.
The four tabs: Programs, Submissions, Planning, Intelligence.

The numbers
- 12 bounty programs currently tracked with scope, rubric, and status
- 4 tabs: Programs, Submissions, Planning, Intelligence
- 7-state submission pipeline: draft, ready, submitted, triaged, accepted, paid, disclosed
- Program scope drift detection, automatic diffs when a program updates its scope
- Disclosure window tracking, SLA-aware reminders on every active submission
- Direct Armory integration, accepted findings become fixtures with attribution preserved
- Mitsuke-backed Intelligence feed, NIST, MITRE, AI Incident DB, and several other sources
Ronin Hub replaces the spreadsheet with a pipeline.
The Programs Tab
Programs is the catalog. Each program has a scope, a bounty range, a severity rubric, a disclosure window, a response SLA, and a link to the official submission portal. Currently tracked programs include OpenAI, Google, Anthropic, Meta, and Microsoft, plus seven others (smaller labs, frameworks, and agentic vendors).
Every program entry is watched for changes. When a program updates its scope, the entry updates with a diff and an alert surfaces in the workspace. A payload that was out of scope last week may be in scope this week, and Ronin Hub surfaces that change automatically so the researcher does not have to re-read every scope page every Monday.
Every program is tagged with its category (model safety, product security, infrastructure, agentic, data handling) and its current status (active, paused, deprecated). Researchers can filter by tag to find the right target for a specific research objective. A researcher looking to do MCP work can filter for agentic programs and see the four programs that currently accept MCP findings.
Why scope drift tracking matters
Scope drift is the single most expensive failure mode for a researcher running multiple bounties. A week goes into a finding, it gets submitted, and a "this is no longer in scope" response comes back. There was no way of knowing. The scope page was updated two days before the submission.
Ronin Hub watches scope pages. When the diff is meaningful (categories added or removed, severity thresholds changed, new exclusions), the program entry surfaces an alert. A researcher with active research against that program gets notified. The cost of scope drift drops from "wasted a week" to "read a diff on Monday morning."
The Submissions Tab
Submissions is the pipeline. Every submission is a row with a state, a program, a pattern id, and a link back to the Armory fixture and DNA node that produced the finding.
The submission state machine has seven states:
- Draft. The researcher is writing it up.
- Ready. Written, linked, and queued for internal review.
- Submitted. Sent to the program, waiting for acknowledgment.
- Triaged. Program has acknowledged and is investigating.
- Accepted. Program has accepted the finding as valid.
- Paid. Bounty has been paid out.
- Disclosed. The coordinated disclosure window has expired and the finding is public.
Transitions are logged with timestamps. The current state of every submission is visible at a glance. A weekly review meeting can walk the board and see exactly what is active, what is waiting on the program, and what is approaching a disclosure deadline.

Every submission entry has a provenance block that shows where the payload came from: a manually curated Armory fixture, a SAGE champion, a Sengoku campaign finding, or a Mitsuke threat intelligence signal. Reviewers (internal and external) can trace the full chain from submission back to origin without asking for follow-up.
The Planning Tab
Planning is the research workspace. The researcher declares an objective ("find an MCP exploit in scope of program X"), picks targets, sets a timebox, and tracks progress against the plan. Plans can run alone or call Sengoku campaigns to automate the exploration.
A research plan has:
- Objective (what the plan is trying to find)
- Scope (which programs and which categories)
- Timebox (how long the plan has)
- Assigned researcher (single owner)
- Milestones (checkpoints for progress or plan revision)
- Success criterion (either "found and submitted" or "demonstrated infeasibility in scope")
Milestones are checkpoints where the researcher either reports progress or revises the plan. The success criterion is either a filed submission or a documented reason the objective is not reachable in the current scope. Both outcomes are valuable. A plan that produces a documented infeasibility is not a failure, it is a conclusion that shapes future research.

Plans are visible across the team. Two researchers on the same team targeting the same program is wasted effort, and the Planning tab is how Ronin Hub prevents it.
The Intelligence Tab
Intelligence is the feed. It pulls from the same sources as Mitsuke: NIST NVD, MITRE ATT&CK, AI Incident Database, HuggingFace, OWASP, and several other advisory streams. CVE drops, new vulnerability disclosures, model release notes, and advisories land in the feed.
When a new advisory lands that overlaps with an active plan, the plan surfaces an alert. A researcher working on an MCP exploit plan gets notified when a new MCP-related CVE drops, even if the CVE is in a tool they were not directly targeting. The alert includes the plan id and the overlap reason, so the researcher can decide whether to pivot.

Principles Behind the Design
Submissions have provenance
Every submission links back to the pattern, the fixture, the DNA node, and the campaign that produced it. A reviewer can trace the finding all the way to its origin without asking for a follow-up. This is important for two reasons. One, it shortens the triage cycle on the program side, because the reviewer has the full chain of evidence in one place. Two, it preserves institutional knowledge on the team side, because the finding is no longer locked in the original researcher's head.
Plans prevent duplicate work
Two researchers on the same team targeting the same program is wasted effort. The Planning tab is visible to the team, and objectives are negotiated before the timebox starts. If two researchers want to target the same program, they either collaborate on a single plan or divide the scope so they are not duplicating effort. The platform makes the duplication visible at plan-creation time, not at submission time.
Disclosure timelines are first class
Every program has a responsible disclosure window that starts when the finding is accepted. Ronin Hub tracks the clock from triage to disclosure and warns when a program deadline is approaching. Missing a disclosure window is a relationship-damaging mistake with a program. The tool exists in part to prevent it.
The disclosure clock is not a calendar reminder. It is an active state of the submission, visible on the board, counting down. When a finding hits the 30-day mark before disclosure, the submission turns yellow. At 7 days, it turns red. At the deadline, it moves to the disclosed state automatically and the associated Armory fixture becomes public.
Scope changes are tracked
Program scopes drift. A program that accepted agentic findings last quarter might narrow its scope this quarter. Ronin Hub watches scope pages and surfaces diffs as part of the program entry. A researcher can see exactly when a scope changed and what it means for their active plans.
Everything routes back to the Armory
A high-value finding that is accepted and disclosed becomes a fixture in the Armory, enters the DNA graph, and shows up in the scanner's next evaluation. The bounty pipeline is upstream of the detection pipeline. The two pipelines share the same library and the same evidence chain.
This is the design choice that turns bounty work into compounding defense. A researcher who lands a finding in an external program is also contributing to the internal fixture library, the scanner, the guard, and every other downstream module. One discovery, multiple improvements.
A Worked Example
A researcher creates a plan: find a tool schema abuse vulnerability in the scope of Anthropic's bounty program, timebox two weeks, using Atemi Lab and Sengoku. The plan is peer-reviewed and approved. A milestone is set for the end of week one.
Week one, day one. The researcher uses Atemi Lab's Protocol Fuzz workspace to probe the target MCP surface. They notice a pattern in how a specific tool handles malformed arguments and build a candidate payload.
Week one, day five. The candidate payload reproduces reliably in Atemi Lab. The researcher hits the week-one milestone and logs progress: candidate identified, reproduction confirmed, ready to explore variants.
Week two, day one. They run a Sengoku campaign using TAP to explore variations on the candidate. The campaign surfaces three variants, one of which produces a clear boundary violation.
Week two, day three. The researcher writes up the finding. The write-up is a draft submission in Ronin Hub, with linked references to the Atemi Lab session, the Sengoku campaign report, the Armory fixture (newly created with draft state), and the DNA node the payload was placed into.
Week two, day four. The submission moves to the "ready" state and goes through an internal review. A second researcher confirms the finding is reproducible and novel. The submission transitions to "submitted" and goes out to the program.
Two weeks later. The program triages the finding and accepts it at a high severity level. Ronin Hub tracks the disclosure window and schedules reminders. The submission state moves to "accepted." The associated Armory fixture is locked in its draft state pending disclosure.
Six weeks later. The finding is disclosed publicly. The fixture is promoted from draft to production state in the Armory. The scanner team adds a pattern to cover the new attack class. Hattori Guard picks up the new pattern automatically. Every other team running DojoLM gets the benefit.
From plan to public defense in about ten weeks, with every step auditable, every artifact linked, and every transition logged. That is the pipeline.
Why This Matters Beyond the Bounty Check
Bounty programs are the public-facing edge of frontier AI security research. The findings that land in bounty reports today are the attack patterns that will be in production red team engagements next quarter. Tracking them as a pipeline instead of a spreadsheet turns the researcher's workflow into a source of scanner improvements and compliance evidence at the same time.
There is also a cultural benefit. A researcher who knows their work will compound into the library is more willing to share findings internally. A researcher who thinks the work ends with a paid bounty has no incentive to document the chain. Ronin Hub makes the chain the default, and the default shapes behavior.
The Principle
The deeper design principle is that bounty research, internal red teaming, scanner improvement, and compliance evidence should share one substrate. Most teams treat them as four separate activities run by four different people using four different tools. Ronin Hub treats them as one pipeline with four stages, all reading from the same control set, the same fixture library, and the same DNA graph.
One pipeline. Four stages. One source of truth. That is what keeps the work from rotting.
What Is Next
Tomorrow, Day 13, the module tour closes out with Kotoba and Kagami. Prompt hardening and model fingerprinting. Two halves of the same workflow: harden the prompt, verify the model has not drifted.
Both modules are short. Both modules close loops that most teams leave open. And both modules connect back to the same shared spine the rest of the platform sits on.
See you there.