Inspiration

Security tools are good at producing alerts, but an alert is not the same as a vulnerability. The hardest part often comes afterward: understanding the evidence, checking the security context, deciding whether a finding is real, and documenting why.

I built SecureFlow to make that process more structured and auditable. My goal is not to replace security researchers or let an AI make final security decisions. Instead, SecureFlow combines deterministic analysis, contextual investigation, AI-assisted reasoning, and human validation in one evidence-first workflow.

For the WebMCP Challenge, I created the SecureFlow Review Room: a focused web experience where a person and an agent can investigate security candidates together without transferring final authority to the model.

What it does

The Review Room presents a set of structured security candidates from an explicitly authorized synthetic application.

For each candidate, the reviewer can inspect:

  • the suspected security issue;
  • source, control, and sink evidence;
  • confidence and known limitations;
  • revision context;
  • a provisional agent memorandum;
  • suggested validation and hardening steps;
  • the append-only audit history.

Through WebMCP, an agent can navigate the structured evidence, inspect candidates, compare revision context, and stage a recommendation. It cannot silently confirm a vulnerability or submit the human decision.

The reviewer must independently choose to validate, reject, or abstain, provide a rationale, and record the disposition. This creates a visible boundary between machine assistance and human accountability.

How I built it

SecureFlow itself is a local-first Rust project composed of versioned contracts for deterministic analysis, contextual security review, benchmark evidence, advisory knowledge, optional AI assistance, and human adjudication.

The challenge entry is a deliberately smaller vertical slice. Instead of moving the entire security pipeline into a browser, I built a Review Room around a synthetic, pre-structured case. This keeps the demo safe, fast, and easy to evaluate.

The interface is designed around three principles:

  1. Agents investigate.
  2. Humans decide.
  3. Evidence persists.

WebMCP provides the interaction layer between the agent and the application. The tools expose only the information and actions required for investigation. Human disposition controls remain outside the agent tool boundary.

The public demo uses synthetic findings and does not scan visitors, execute target code, exploit systems, collect credentials, or contact third-party infrastructure.

Challenges

The biggest challenge was deciding what the agent should not be allowed to do.

It would have been easy to expose every button as a tool, including the final validation action. That would make the demo appear more autonomous, but it would weaken the security model. I instead separated agent recommendations from human dispositions and made that separation visible in both the interface and the audit trail.

Another challenge was presenting enough technical evidence without turning the experience into a scanner dashboard full of unexplained alerts. Each candidate therefore includes a compact evidence path, limitations, confidence, and a clear next validation step.

I also had to keep the claims honest. The current Review Room demonstrates a human-agent workflow using synthetic cases. It does not prove that SecureFlow finds every vulnerability, eliminates false positives, or outperforms expert researchers.

What I learned

WebMCP is most useful when it exposes meaningful product capabilities rather than simply mirroring interface controls.

A security-review agent does not need unrestricted access to the application. It needs carefully scoped tools, stable evidence, explicit limitations, and a safe way to stage recommendations. The person should remain responsible for conclusions that require authorization, contextual judgment, or real-world validation.

I also learned that abstention is a valuable result. When the available evidence is insufficient, the correct action is not to invent certainty—it is to explain what is missing.

What's next

The next step is to connect the Review Room to real SecureFlow artifacts produced locally from explicitly authorized repositories.

Future work includes:

  • importing deterministic Secure Engine results;
  • comparing findings across revisions;
  • connecting contextual Secure Skill reviews;
  • measuring reviewer time, agreement, precision, recall, and abstentions;
  • adding stronger provenance and signed human decisions;
  • evaluating the workflow through preregistered, blinded studies.

The long-term research question is whether SecureFlow can outperform human baselines on narrow, measurable tasks such as coverage, speed, pattern recall, and reproducibility. Until that is demonstrated with independent evidence, final vulnerability validation remains a human responsibility.

Built With

Share this project:

Updates

Submission history