Release Sentinel — WebMCP Proof Arena

Inspiration

WebMCP solves an important problem for agentic websites: instead of forcing an AI agent to guess at a page's DOM, a site can expose explicit, typed tools.

But that creates a second question:

How do you give an AI agent enough power to be genuinely useful without also giving it the authority to approve its own actions?

For consequential systems, that distinction matters. An agent may need to investigate, challenge, repair, or prepare an action — while approval must remain somewhere else.

Release Sentinel explores that boundary using software release approval as a concrete test case.

Our principle is simple:

agent acts → Gatekeeper decides → human verifies

What it does

Release Sentinel is a WebMCP-powered security lab for AI-assisted software releases.

A vulnerable software release begins at NO_GO.

The AI agent receives useful capabilities through WebMCP. It can inspect the release, inspect the trust boundary, run bounded attacks, compare gate revisions, find and minimize counterexamples, propose remediation, rebuild a candidate, and request fresh verification.

What it cannot do is authorize the release.

The demo first lets the agent try the available attacks against the authority boundary. Advisory GO votes, replay attempts, forged authority, evidence tampering, severity downgrades, blocker deletion attempts, and prompt injection still do not give the agent release authority.

So the agent has to solve the real problem instead.

It compares the production gate against an independent Coverage Arena reference oracle, identifies an observed security escape, minimizes it, and creates a bounded remediation proposal.

That proposal is explicitly PROPOSAL_ONLY.

The candidate is then rebuilt to a new SHA-256, fresh evidence is generated, and the deterministic Gatekeeper performs verification again.

Only the Gatekeeper can return the final GO or NO_GO.

A human can independently verify the resulting proof context, but human verification is not release authority either.

How we built it

The browser registers exactly 12 typed WebMCP tools through document.modelContext.registerTool().

They are divided into three capability classes:

• READ — inspect release state, trust boundaries, coverage, and proofs
• CHALLENGE — run attacks and find counterexamples
• PROPOSE — request bounded remediation and rebuilding

There is intentionally no set_verdict, force_go, arbitrary shell execution, arbitrary filesystem access, evidence editor, policy-disable tool, or Gatekeeper override.

That absence is tested as part of the security contract.

Inputs use strict schemas with bounded enums and forbidden extra fields. The agent selects package-owned identities rather than supplying arbitrary source code, fixture paths, or executable content.

We also built run_attack_suite as browser-side composition instead of adding a more powerful server endpoint. It reads the bounded attack catalog and invokes the same registered attack capability repeatedly.

The browser gets better ergonomics without expanding server authority.

The release decision itself remains in a separate deterministic Go Gatekeeper using signed, hash-bound evidence.

Challenges we ran into

The hardest challenge was making the security model understandable.

An earlier version of the Proof Arena was technically accurate but difficult to read. A judge would encounter concepts such as proof-context binding, overblocks, and PROPOSAL_ONLY before understanding the story.

We added a guided demo and plain-language narration without weakening the security model.

Another challenge was resisting convenient shortcuts.

For example, implementing the attack suite as one powerful server endpoint would have been easy. Instead, we kept the server surface narrow and composed the workflow in the browser over the existing bounded tools.

That required more work, but better demonstrates the architectural value of WebMCP.

Accomplishments that we're proud of

The final system demonstrates a useful agent that remains structurally unable to authorize its own success.

The agent can attack the release gate, identify a real weakness, propose a fix, rebuild the software, and request verification — yet final authority remains outside the WebMCP capability plane.

The project also includes:

• 12 typed WebMCP tools
• strict bounded schemas
• agent-readable recovery errors
• browser-side capability composition
• an independent Coverage Arena
• a deterministic Go Gatekeeper
• signed and hash-bound evidence
• source-hash transition visibility
• a Human Proof Checkpoint
• frozen trust and coverage kernel manifests
• Python, Go race, browser, and WebMCP contract verification

What we learned

WebMCP is not only about making browser agents more capable.

The more important architectural question is which capabilities should never become authority.

Typed tools make agent interaction clearer, but tool design also defines the security boundary. The capabilities that are deliberately absent can be just as important as the capabilities that are exposed.

We also learned that browser-side composition is a powerful WebMCP pattern: useful agent workflows can become more ergonomic without automatically creating broader server privileges.

What's next

Release approval is our test case, but the pattern is broader.

Any consequential website may need agents that can act without being allowed to authorize — for example administrative systems, payments, infrastructure, or other sensitive workflows.

The next step would be turning this pattern into a reusable primitive: capability classes plus a verifiable assertion that final authority is not reachable from the WebMCP capability plane.

Built With

• agents
• ai
• cybersecurity
• docker
• fastapi
• github
• go
• javascript
• playwright
• pydantic
• python
• rest
• webmcp