• 

• 

• 

• 

Patronus WebMCP Security Scanner

About the project

Inspiration

Autonomous agents increasingly work with content they did not create: repository files, uploaded documents, MCP tool descriptions, prompts, and resources. That content can contain prompt injections designed to redirect an agent before it has a chance to evaluate whether the source is trustworthy.

We wanted to move that security decision in front of the context boundary. Instead of asking an agent to read potentially hostile content and then judge it, Patronus lets the agent scan the content first and receive only a compact security result.

What it does

Patronus WebMCP Security Scanner gives people and agents access to the same prompt-injection security layer.

People can use the visual interface to:

• scan text for prompt injections;
• inspect an MCP server's tool, prompt, and resource metadata without executing any of its capabilities;
• scan the normalized static surface of a public HTTPS page; and
• upload source code or text documents for analysis.

Agents discover four typed WebMCP tools directly from the page:

• scan_text
• scan_mcp_server
• scan_url
• scan_file

The repository also contains an installable Codex plugin that can scan an entire repository before the agent reads it. A deterministic local helper validates and uploads supported files directly to the scanner. The agent receives only filenames, opaque file IDs, and compact verdicts, so the candidate file contents never enter the model context before the security decision.

Capabilities

Interactive security scanner

The hosted application exposes four read-only WebMCP tools backed by Patronus Ark:

• scan_text checks a bounded text candidate for prompt injection.
• scan_file checks an uploaded source-code or text file through an opaque file ID.
• scan_mcp_server inspects the advertised tools, prompts, and resources of a public MCP server without executing any of them.
• scan_url checks the complete normalized static body of one public HTTPS page.

The same capabilities are available through the visual interface. When an agent invokes a tool, its result is reflected in the page so the person and the agent share the same observable security state.

Repository scan before context

The installable Codex plugin lets a person ask an agent to scan a repository before reading its files. The workflow deliberately separates deterministic file handling from model-visible context:

1. A local helper selects supported files, validates their type and size, and uploads their bytes directly to the hosted scanner.
2. It returns a content-free upload manifest. Prepared entries contain only a filename, byte size, and opaque file_id; skipped entries contain only a filename and reason.
3. The agent calls the scan_file WebMCP tool once for every prepared ID and receives compact verdicts and bounded evidence.
4. The plugin reports every detected incident and the final scan coverage without modifying, deleting, quarantining, or repairing repository files.

This means potentially hostile source text does not need to enter the model context just to reach the classifier. Uploaded objects are short-lived and are deleted after scanning. The result is a bounded prompt-injection check, not a claim that the repository is free of every possible security issue.

WebMCP iframe security manifest

The Patronus website embeds the security manifest as a small cross-origin iframe in its shared footer. It provides the origin-bound WebMCP tool patronus_security_manifest_v1.

The website-scan flow works as follows:

1. A compatible agent is asked whether one exact public HTTPS URL is safe to use.
2. The website-scan skill addresses only the trusted Patronus iframe and supplies that exact URL through fixed bridge controls.
3. Inside its own origin, the iframe discovers and invokes its own WebMCP tool. It rejects a missing, duplicated, or same-named tool from another origin.
4. The Patronus Control Plane fetches the anonymous static page surface, converts the complete normalized document body into one Ark candidate, and keeps other advertised security surfaces as separate candidates.
5. The iframe returns only a bounded verdict, tool identity, URL identity, digests, cache metadata, and coverage. The agent treats missing, mismatched, failed, or truncated results as unverified rather than benign.

Iframe embedding and WebMCP exposure are restricted to the configured Patronus website origins. The manifest does not execute capabilities from the scanned page and does not claim to assess authenticated state, later DOM mutations, privacy, malware, reputation, or every security risk.

The current browser harness may still add navigation or page observations to model context automatically. The demo therefore shows the intended pre-context security sequence and a practical origin-bound WebMCP bridge, while a future native tools-only harness is needed to guarantee that no parent-page content is exposed before the verdict.

Why WebMCP

This use case needs more than UI automation. Scraping the DOM or clicking through a form would force an agent to inspect the very content we are trying to keep outside its context.

WebMCP provides a typed capability boundary instead. The page explicitly describes what an agent may do, validates structured inputs, and returns bounded results. The same calls also update the visible interface, so a person can observe the result and stay in the loop while the agent performs the scan.

That creates a workflow that was previously difficult: a person can point an autonomous agent at an unknown repository, and the agent can evaluate it for prompt injections before reading or reasoning over its contents.

How we built it

The application is written in TypeScript with React and Vinext and runs on Cloudflare Workers. It registers its agent-facing capabilities with document.modelContext.registerTool() and defines strict JSON schemas for every input.

Prompt-injection analysis is powered by Patronus Ark. Text is sent directly for analysis. File scanning uses short-lived Cloudflare R2 sessions: the browser or local helper uploads a file, WebMCP receives only an opaque file_id, and the server deletes the object after scanning.

MCP inspection is intentionally read-only. The server calls only initialize, tools/list, prompts/list, and resources/list; it never executes remote tools, prompts, or resources. The endpoint also rejects credentials, localhost, literal private addresses, unsafe redirects, and oversized responses.

Patronus Ark: CPU-first security

Patronus Ark is Casdo Labs' CPU-first security stack. It is built around our own multilingual security models and shared-encoder architectures, allowing multiple security tasks to reuse a common representation instead of requiring a separate heavyweight model for every detector.

We believe an agent's security layer should not have to compete with the agent itself for scarce GPU capacity. When GPUs are occupied by large language models, security still needs to remain available, responsive, and always on. A CPU-first architecture makes it possible to run protection close to the workload and helps keep essential security affordable—or even free—for a much broader group of users.

The Ark API behind this demo currently runs on only four vCPUs and still provides latency that is practical for an interactive scanning workflow. The API service and its integration were built as part of this hackathon, while the underlying Ark architecture and model research build on several months of prior research and development.

Casdo Labs' long-term vision is a safer future for autonomous agents and the people who rely on them. Agents are rapidly becoming faster and more capable; we believe their security infrastructure must become widely accessible just as quickly.

Challenges we faced

The hardest problem was preserving the security boundary end to end. A repository scanner is not useful if the agent must read each file in order to upload it, so we separated deterministic file handling from model-visible context and designed the WebMCP contract around opaque identifiers.

We also had to make remote MCP inspection useful without turning it into an SSRF proxy or accidentally invoking an untrusted server's capabilities. That required strict URL validation, response limits, read-only protocol calls, and careful error handling.

The iframe manifest introduced a different trust problem: a same-named tool must not be accepted from the parent page or another origin. We bound embedding and tool exposure to explicit origins, verify the discovered tool's identity before execution, return only a bounded result, and document the remaining browser-harness limitation instead of overstating the pre-context guarantee.

Finally, the real classifier runs on a CPU-only deployment. We designed the interface around explicit progress states and compact results so that the additional security step remains understandable even when analysis takes a little longer.

What we learned

WebMCP is not only a more reliable way for agents to operate a website. It can also become a security and policy boundary: the page decides which capabilities exist, which inputs are accepted, what data remains outside model context, and what result is safe to return.

We also learned that human-agent collaboration works best when both sides share the same observable state. A WebMCP call should not feel like a hidden backend operation; reflecting its result in the interface gives the person immediate visibility into what the agent did.

What we are proud of

• Four working, non-trivial WebMCP tools backed by a real prompt-injection classifier
• A repository-wide Codex workflow that scans files before model context
• An origin-bound WebMCP iframe manifest for bounded website checks
• Read-only MCP inspection that never executes discovered capabilities
• Ephemeral file handling with opaque IDs and automatic deletion
• A public controlled MCP test server containing known prompt injections

What's next

Next we want to move the iframe flow onto a native tools-only browser harness, add streamed batch progress for larger repositories, produce signed scan attestations, and build policy integrations that let organizations require a clean result before an agent can consume external content.

Built with

• WebMCP
• TypeScript
• React
• Vinext
• Next.js
• Cloudflare Workers
• Cloudflare R2
• Patronus Ark
• Model Context Protocol
• Codex
• Prompt Injection Detection
• AI Security
• Agent Security
• Cybersecurity
• Open Source

Built With

• onnx
• python
• rust
• typescript