Origin, access model, eligibility, and substitution are reviewer diagnostics, not judging criteria. Authentication requirements are not penalized.
02 The two blind reviews
Two independent reviewers scored this project blind, from a sanitized evidence packet.
Scores are shown separately so the reasoning stays inspectable. A withheld score means the reviewers differed by more than two points.
Reviewer A (round 1)
confidence 76%
Leverage
8 /10
The core value is changing WebMCP from capability exposure into execution-time authority enforcement with shared live state; generic UI-driving agents would be less reliably constrained.
Evidence cited
Description says the website, not the prompt, enforces authority at execution time.
Claimed blocked €1,200 refund under €500 cumulative limit, then live €800 session authority and approval-bound remainder.
Frame sheet visibly shows an authority/security product and Control Center, though exact flow is not legible.
Execution
7 /10
The packet describes a coherent end-to-end safety workflow and has a live demo, public repository, and frame-sheet evidence, but no video or transcript and the screenshots do not prove every claimed state.
Evidence cited
Live demo and public repository are reported alive.
Frame sheet shows consistent product surfaces including overview, configuration, and Control Center.
Impact
8 /10
It addresses a concrete high-stakes problem for teams deploying browser agents against billing and sensitive business systems, with a credible safety mechanism.
Evidence cited
Billing dispute scenario uses refunds and account credits as consequential actions.
Description directly frames stale or manipulated prompts as inadequate guardrails.
Human approval and audit/state visibility are central to the demonstrated use case.
Creativity
7 /10
The capability-versus-authority framing and website-enforced, session-scoped governance are a strong synthesis for WebMCP, though the general authorization concept is established.
Evidence cited
Core thesis explicitly separates what an agent can do from what it is authorized to do now.
Authority changes without restarting the agent, requiring rereading and replanning.
Exact-action approval binding is a thoughtful interaction model.
Reviewer B (round 2)
confidence 86%
Leverage
10 /10
The website must enforce live authority at the exact action boundary; this is materially beyond an agent driving buttons or relying on prompt instructions.
Evidence cited
ABOUT states the website blocks a €1,200 refund against a €500 cumulative limit and no money moves.
Authority is reread after a session-only increase and exact approval binds amount, customer, session, and action.
Frame sheets show a security/billing workflow with policy and action states.
Execution
8 /10
The scenario is unusually specific and internally coherent, with a full deny-adjust-execute-verify lifecycle; visual proof is packaging/frame evidence rather than an observed transcript.
Evidence cited
ABOUT enumerates invoice inspection, contract verification, authority read, blocked refund, approval, execution, and final verification.
Frame sheets visibly show multiple authority and billing states.
No transcript is supplied.
Impact
9 /10
Consequential agent actions need runtime authorization, and the demo addresses a concrete financial-control and prompt-injection-resilience problem.
Evidence cited
The fictional dispute models refunds, credits, customer identity, and human approval.
The stated thesis clearly separates capability from authority.
Creativity
8 /10
Treating the website as the enforceable authority boundary is a sharp, original interaction and security model for WebMCP agents.
Evidence cited
Exact-action approval and live session authority are demonstrated as product concepts.
The denial/replanning flow is more than a generic permission toggle.
03 Review highlights
Standouts across reviewers
Strong separation of capability and authority.
Live, session-scoped limit changes with blocked-action semantics.
Exceptionally clear WebMCP leverage: authority is checked at execution time.
Red flags
No submitted video or transcript; central agent invocation is claimed rather than directly evidenced.
Many detailed claims in the packet are not independently observable from the supplied frame sheet.
Demo uses fictional billing data; real-world enforcement robustness is not established.
04 Evidence
What each artifact proves is labeled on the artifact itself. A Devpost page capture is packaging evidence, not proof the product runs;
video frames are evidence from the submitted demo, not live verification.
Contact sheets from the ?s video the team submitted. This is what reviewers were shown;
it demonstrates the product in motion but is not independent verification.
· watch the original
EX-V1 Sheet 1 of 3 · reported video evidenceEX-V2 Sheet 2 of 3 · reported video evidenceEX-V3 Sheet 3 of 3 · reported video evidence
