Inspiration

AI agents can browse websites, summarize information, and use tools, but they also read content written by untrusted third parties. A malicious page can hide instructions in visible text, HTML comments, image alt text, metadata, or search snippets and attempt to override the user’s request. We built LatchBrowse around one principle: the internet should be treated as data, never as trusted instructions.

What it does

LatchBrowse is a secure research agent that applies a trust boundary to everything it retrieves from the web. Content passes through four security layers: isolation, prompt-injection detection, capability restriction, and independent cross-checking. Suspicious segments are quarantined, unsafe capabilities are removed, and answers must pass final validation before being released.

The Attack Lab compares the same controlled hostile page through protected and unprotected paths. The IT Review Console then records findings, affected content, severity, security decisions, and review status without storing the user’s original prompt.

How we built it

We built LatchBrowse primarily with Jac, using its server and client capabilities to create the research workflow and interface. The application integrates language models for research, detection, summarization, and structured security analysis.

The security pipeline assigns provenance to content, splits pages into addressable segments, detects attacks, produces capability-constrained SafeArtifacts, and gives an independent critic only structured claims (not the original hostile text). The production application runs on Vercel, with Redis providing shared storage for sessions, findings, reviews, and rate limits across serverless instances.

Challenges we ran into

The hardest challenge was separating useful page information from instructions targeting the agent. Simply asking another model whether a page is safe was not enough, because the security model could itself be influenced or return incomplete output.

We also had to design for disagreement and failure. If detection and independent review conflict—or if a security service becomes unavailable—the system must fail closed without unnecessarily destroying useful evidence. Deploying stateful research workflows to a serverless environment added another challenge because sessions and findings could not rely on process memory.

Accomplishments that we're proud of

We created a layered defense instead of relying on a single prompt or classifier. LatchBrowse can localize suspicious content, quarantine individual segments, restrict tool capabilities, independently challenge security decisions, and withhold unsafe output.

We are especially proud that Attack Lab uses the actual production pipeline rather than hard-coded verdicts. Findings persist in the Review Console, dangerous tool attempts are intercepted, and the same trust model covers retrieved pages and search results. We also built regression tests around security invariants and serverless behavior.

What we learned

Prompt injection is not only a content-classification problem; it is a systems and authorization problem. Detection helps, but an agent also needs provenance tracking, constrained capabilities, isolated model inputs, validation, and safe behavior when components disagree.

We learned that model independence depends on controlling information flow. A critic cannot independently evaluate a decision if it receives the same hostile text and can reconstruct the original attack. We also learned that production infrastructure, which includes persistence, rate limiting, timeouts, and failure handling, is part of the security boundary.

What's next for LatchBrowse

Next, we want to expand the adversarial fixture library and evaluate LatchBrowse against established prompt-injection benchmarks. We also plan to add safer custom testing, stronger detection for encoded and multimodal attacks, richer policy controls, and clearer explanations for quarantined content.

Longer term, LatchBrowse could become middleware for any browsing agent, allowing organizations to define their own trust policies, tool permissions, review workflows, and audit integrations.

Built With

Share this project:

Updates

Submission history