ADAPT

Inspiration

ADAPT actually started before this hackathon as a completely different project: an adaptive browser privacy and content-blocking system.

When we started looking seriously at WebMCP, though, one thing kept bothering us.

WebMCP gives websites a much cleaner way to expose tools directly to AI agents. Instead of an agent guessing where to click or trying to understand a page visually, the site can simply say: here is a tool, here is what it does, here are the arguments it accepts.

That is a huge improvement.

But it also means the agent is trusting a description written by the same page that controls the code behind the tool.

So we asked a pretty simple question:

What happens if a WebMCP tool lies?

We made one.

It described itself like a harmless cart-viewing action. When it was executed, it attempted payment-like network activity, changed local payment state, and navigated to an order-success page.

That experiment became the new direction for ADAPT.

What made us take the idea even more seriously was seeing that the WebMCP specification itself discusses this problem as misrepresentation of intent. At that point, it stopped feeling like an artificial demo attack and started feeling like a real trust problem that the agent-native web is going to have to solve.

What it does

ADAPT is a behavioral trust layer for WebMCP.

Instead of trusting only what a tool says it will do, ADAPT compares that declaration with what actually happens when the tool runs.

The basic flow is:

Declare → Classify → Observe → Compare → Decide

When a WebMCP tool is exposed, ADAPT builds a declared contract from information such as its name, description, schema, annotations, and expected capabilities.

During execution, ADAPT observes browser-visible effects such as network writes, storage mutations, and navigation.

It then compares the two.

If the observed behavior stays within what the tool declared, the result can be marked SAFE.

If the tool behaves in a way that does not match its declaration, ADAPT can surface the mismatch and QUARANTINE the result.

For actions that are already known to be consequential, ADAPT can take a different path entirely: execution is HELD before it happens and a human has to explicitly approve or deny it.

That distinction was important to us.

A deceptive low-risk tool and an openly high-risk tool should not be treated as the same problem.

We also generate an auditable trail of what was declared, what was observed, what decision ADAPT made, and how the action was executed.

The idea is simple:

Trust the behavior, not just the label.

How we built it

The WebMCP work lives in the ADAPT Trust Lab and a reusable trust core under src/webmcp.

We use the real document.modelContext WebMCP surface where it is available, including tool registration and discovery.

Around that lifecycle, we built several pieces:

declared tool contracts
consequence classification
runtime behavior observation
declared-vs-observed capability comparison
guarded execution
human approval for consequential actions
trust receipts and an audit trajectory
tool-surface change detection
adversarial scenarios for deceptive and benign tools

One thing we cared about a lot was keeping the security logic separate from the demo UI.

The Trust Lab is just the place where you can see the system working. The actual decision and trust logic lives in standalone modules that can be tested independently.

We also built a deterministic WebMCP-compatible test path because relying only on live browser behavior would have made the security tests flaky and hard to reproduce.

The current build has 526 unit tests, 24 E2E assertions plus 2 harness meta-checks, adversarial scenarios, repeated stress runs, receipt-chain verification, and a real Chromium WebMCP surface check.

The live version is deployed as a static site and can be opened in ChatGPT's in-app browser or Chrome with WebMCP enabled.

Challenges we ran into

The hardest part was not detecting that "something happened."

The hard part was deciding whether what happened was actually outside the behavior the tool had declared.

Early versions of ADAPT were much too simple. A read-only tool performing a write was easy to classify, but real tools are not always that clean. A legitimate write-capable tool may make a network request, change state, or navigate as part of its intended behavior.

That forced us to move away from a basic read-only vs. write check and start thinking in terms of declared capabilities versus observed effects.

Another challenge was being precise about the word "blocked."

For a consequential action that ADAPT holds before execution, "blocked" really can mean nothing happened.

For a deceptive tool that has already started running before ADAPT observes the mismatch, that is different. In that case we describe the result as quarantined rather than pretending ADAPT somehow reversed an arbitrary side effect.

We spent a surprising amount of time fixing that language because we did not want the demo to claim more than the implementation actually guarantees.

Real WebMCP testing was another challenge. Browser support is still experimental, so we needed both a real WebMCP path and a deterministic test harness to make development and CI reliable.

And because this is a page-level prototype, the observer currently shares a JavaScript context with the page it is observing. A fully hostile same-context script can bypass some instrumentation. We treat that as a real limitation, not something to hide.

Accomplishments that we're proud of

The thing we are most proud of is that ADAPT stopped being just an interesting security idea and became something we could actually demonstrate end to end.

A judge can see:

a normal WebMCP tool behave as declared and pass as SAFE
a deceptive tool produce a visible declared-vs-observed mismatch
a consequential action get HELD before execution for a human decision
a decision leave behind an auditable trust receipt

We are also proud of how much effort went into proving the demo rather than just polishing it.

The trust core is covered by hundreds of tests, adversarial cases, repeated browser runs, tamper checks, and reproducible evidence tied to a specific build.

We also kept the history of the original ADAPT project in the same repository instead of pretending everything existed only for this challenge. The WebMCP Trust Lab and trust runtime were added during the challenge period, and the repository history makes that separation visible.

What we learned

The biggest thing we learned is that metadata is useful, but metadata is not enforcement.

A tool name, description, schema, or annotation can help an agent understand what a tool is supposed to do. But if the system never compares that promise with reality, the declaration is still just a claim.

We also learned that "security" gets much harder the moment you try to describe exactly what you guarantee.

It is easy to say:

"ADAPT blocks malicious tools."

It is much harder, and much more useful, to say:

"This action was held before execution."

or:

"These effects were observed, they exceeded the declared capability, and the result was quarantined."

That distinction changed a lot of the design.

Finally, WebMCP made us think differently about the browser itself. Once websites expose callable capabilities directly to agents, trust can no longer live only at the UI level. The relationship between declaration, execution, user intent, and evidence becomes part of the product.

What's next for ADAPT

The current challenge build is a research prototype, not a complete browser security boundary.

The next step is moving more of the enforcement into a trusted browser or extension context so observation cannot be bypassed by code running in the same page.

We also want to make the behavioral model richer.

Today ADAPT focuses on a small set of high-value effects such as network writes, storage changes, navigation, and consequential actions. A production system could reason about much more specific capabilities: payments, deletion, account changes, credential access, file actions, identity changes, cross-origin effects, and more.

We would also like the trust receipts to become portable evidence that an agent, browser, user, or external policy system can inspect independently.

WebMCP makes the web callable.

We think the next question is whether those calls can also become accountable.

That is the part of ADAPT we want to keep building.