Inspiration

Cyber incident investigations require analysts to distinguish carefully between what the evidence actually shows and what is merely an interpretation or hypothesis.

AI agents can help investigate, summarize, correlate, and organize large amounts of technical evidence. But their conclusions should remain traceable to the underlying data and subject to meaningful human review.

EvidenceFlow was inspired by that problem: how can humans and AI agents investigate cybersecurity evidence together without losing the distinction between evidence, inference, and validated conclusions?

What it does

EvidenceFlow is a human-agent workspace for cybersecurity incident investigation.

Using WebMCP, an AI agent can:

  • discover available incidents;
  • retrieve structured incident evidence;
  • analyze events chronologically;
  • propose a finding linked to specific evidence IDs;
  • assign a confidence level;
  • recommend a next investigative action.

Every agent-generated finding enters the application as pending-human-review.

A human investigator can then Approve, Reject, or request more evidence through the application interface.

EvidenceFlow deliberately exposes no WebMCP tool for approving or rejecting findings. Validation remains a separate human-review step outside the WebMCP tool surface.

The current demo uses a synthetic SSH authentication incident.

How I built it

EvidenceFlow is a static web application built with HTML, CSS, and JavaScript and deployed through GitHub Pages.

The application exposes three browser-native WebMCP tools through document.modelContext:

  • list_incidents
  • get_incident_events
  • propose_finding

Together they create the agent workflow:

incident → evidence → agent analysis → evidence-grounded proposal → human review

The implementation also treats incident evidence as untrusted data and includes bounded inputs, evidence-reference validation, duplicate-reference rejection, text-only DOM rendering, and mandatory pending-human-review status for agent proposals.

I tested the tools in Chrome with WebMCP support and the WebMCP Model Context Tool Inspector on the public GitHub Pages deployment. I also validated an agent-driven investigation workflow in which the agent autonomously selected and executed the registered WebMCP tools from a natural-language investigation request.

Challenges I ran into

One challenge was designing the boundary between agent capability and human authority.

It would have been easy to expose a tool that allowed the agent to complete the entire workflow automatically. Instead, I chose to make proposal and validation separate operations.

Another challenge was WebMCP client interoperability. Different agent environments behaved differently when discovering and invoking browser-exposed tools. Direct testing through Chrome and the WebMCP Model Context Tool Inspector helped distinguish EvidenceFlow’s WebMCP behavior from client-specific orchestration behavior.

I also performed a security review of the WebMCP interaction surface and added limits and validation to prevent oversized or malformed agent inputs from unnecessarily consuming browser resources.

Key accomplishments

EvidenceFlow demonstrates an integrated WebMCP investigation workflow rather than simply exposing isolated tools.

From a natural-language investigation request, an agent can discover an incident, retrieve structured evidence, analyze that evidence, and create a proposed finding linked to specific evidence IDs.

The resulting finding is not automatically validated. It enters the application as pending-human-review, preserving a clear boundary between agent-generated analysis and human validation.

The prototype makes three stages of the investigation explicit:

evidence → inference → human review

That separation became one of the central design principles of EvidenceFlow.

What I learned

I learned that exposing an application to AI agents is not only about giving the agent more capabilities.

Tool boundaries, data provenance, validation, failure behavior, and human oversight all become part of the application design.

WebMCP provides an interesting way to make those capabilities explicit at the browser level rather than requiring an agent to infer application behavior only from the visual interface.

My background is in law and digital law rather than software engineering, and that strongly influenced this approach: traceability, evidence, authority, and review became design requirements rather than secondary considerations.

What's next for EvidenceFlow

The current prototype intentionally uses synthetic evidence and does not connect to live security infrastructure.

A future architecture could ingest and normalize evidence from systems such as:

SIEM / EDR / IDS / firewalls / authentication systems / cloud logs

and expose that normalized investigation context to agents through the same WebMCP layer.

Future versions could also add authenticated backends, persistent audit trails, reviewer identity and authorization, incident-ingestion pipelines, and integrations with real security platforms.

The long-term idea is not to replace existing security infrastructure, but to add a controlled human-agent investigation layer on top of it.

Share this project:

Updates

Submission history