ThreatTriage WebMCP

Human-visible, agent-ready defensive cyber triage that lets people and browser agents safely analyze suspicious messages, organize incidents, and build response plans with WebMCP.

Comment

Inspiration

Security incidents are a bad place for an AI browser agent to guess. Suspicious messages can contain unsafe links, urgent language, credential requests, and untrusted instructions, while many schools, nonprofits, and public-service teams may not have a dedicated security operations center.

ThreatTriage explores a safer agent-native pattern: the website explicitly exposes defensive capabilities through WebMCP while keeping every result visible to the human operator.

What it does

ThreatTriage is a privacy-first defensive cybersecurity workflow where a person and a browser agent can collaborate on suspicious-message triage.

It can:

  • analyze suspicious SMS, email, or chat messages;
  • create a local incident case;
  • build a defensive response plan;
  • draft an unsent cybersecurity awareness notice;
  • list local incident cases; and
  • mark a case as reviewed.

Instead of forcing an agent to inspect the page and guess which controls to click, ThreatTriage exposes six bounded WebMCP tools with structured JSON schemas.

Every agent action is also reflected in the same visible interface used by the human and recorded in the Agent Activity panel.

How we built it

ThreatTriage is a dependency-free static web application built with HTML5, CSS, vanilla JavaScript, browser localStorage, and GitHub Pages.

The WebMCP implementation uses the imperative API on document.modelContext.

Six tools are registered through await document.modelContext.registerTool(...):

  1. analyze_suspicious_message
  2. create_incident_case
  3. build_response_plan
  4. draft_awareness_notice
  5. list_incident_cases
  6. mark_case_reviewed

Each tool has a clear description, constrained input schema, execution handler, and relevant safety annotations such as readOnlyHint and untrustedContentHint.

The WebMCP handlers reuse the same application functions as the manual interface. This means agent actions do not happen in a hidden automation layer—the user immediately sees the resulting analysis, incident case, response plan, notice, or status change.

Challenges we ran into

The biggest challenge was designing tools that were useful without becoming overly broad.

Cybersecurity workflows involve untrusted content, so ThreatTriage needed strong boundaries. It never opens suspicious links, sends messages, changes external accounts, or produces offensive cybersecurity functionality.

Another challenge was keeping agent activity understandable to the human. We solved this by updating the normal page UI after each WebMCP action and adding a visible Agent Activity log.

We also deliberately avoided backend dependencies and external APIs so the challenge demo would remain reproducible and privacy-conscious.

Accomplishments that we're proud of

We built a complete end-to-end WebMCP workflow with six structured tools.

Agent actions update the same human-visible workspace instead of operating through a separate hidden automation path.

The MVP requires no backend or API key, stores demo data locally in the browser, and maintains defensive-only safety boundaries.

The application is publicly deployed, open source, and successfully tested with Chrome's WebMCP tooling.

What we learned

WebMCP works best when websites expose domain-level intentions instead of low-level UI operations.

A tool such as build_response_plan is more reliable and understandable than asking an agent to locate several controls and simulate a sequence of clicks.

We also learned that agent-native UX should remain human-native UX. Structured tools become easier to trust when their effects are immediately visible to the person using the application.

What's next

Future versions could add optional encrypted persistence, organization-specific incident playbooks, role-based workflows, exportable incident summaries, stronger defensive scoring, and integrations with authorized IT or security channels.

Consequential external actions would still require explicit human approval.

Privacy and safety

ThreatTriage is defensive-only.

The current MVP has no backend and no API key. Demo message and incident data remain in browser localStorage. The app never opens URLs found in suspicious messages and does not provide malware, exploitation, credential-harvesting, persistence, or unauthorized-access functionality.

Risk scoring is an educational heuristic and is not intended to replace a professional security investigation.

Built With

Share this project:

Updates

Submission history