CommerceGov: Governed AI Commerce via WebMCP

• 

  AI agent can inspect, but cannot change production.

Inspiration (Why you built it)

Capability is not authority.

Shopify agencies want AI to draft catalog changes. They cannot afford AI that publishes them. One bad catalog change can hit a live store, paid traffic, and brand trust. That is a control problem, not a model-quality problem.

WebMCP makes websites directly usable by agents through structured tools. But as agent capabilities expand, applications need a hard boundary between “prepare a change” and “write production.”

CommerceGov focuses on that boundary. The agent gets enough capability to discover, inspect, and propose changes, but it does not get authority to change production state — it cannot approve or apply without human review.

What it does (The core solution)

CommerceGov puts a ChatGPT agent inside the same governed commerce workflow used by human operators — while keeping production authority outside the agent.

The agent searches the shop, reads policy and governance state, proposes a change, and creates a Review proposal. Authorized operators review, approve, and apply according to CommerceGov’s workflow and role boundaries. Only then may CommerceGov’s worker write to Shopify.

The agent cannot approve, apply, or mutate Shopify production. Those capabilities are not exposed through WebMCP.

For Shopify agencies, this means AI can assist with daily catalog operations without receiving direct production authority. Agencies keep control over clearances, review, approval, and the history of governed changes.

Live path: ChatGPT selects openai-webmcp-hackathon.myshopify.com, finds The Complete Snowboard, proposes changing the title to The Complete Snowboard — WebMCP Proof, creates a Review proposal, and retrieves its status and audit evidence.

Production stays unchanged.

How we built it (The technical stack)

The backend is Python FastAPI. The operator UI is server-rendered, and Shopify writes go through a CommerceGov worker rather than the agent or browser. The application is hosted on Render at app.commercegov.io.

We implemented WebMCP as a bounded tool surface, not a wrapper around the full CommerceGov API.

The page's modelContext exposes five tools:

• search_products
• get_governance_context
• propose_change
• get_change_status
• get_audit_evidence

We deliberately omit approve, apply, and Shopify production-write tools. The agent therefore has no WebMCP handle to invoke them.

Each tool is bound to the authenticated shop and target. Proposal status and audit retrieval resolve to the exact proposal the agent created rather than silently switching to a newer object.

Production-mutating tools are absent, not merely permission-gated after the fact.

Challenges we ran into

The main challenge was identity and authority: keeping tenant, shop, product, and proposal bound across tool calls while ensuring that a request for status or audit evidence cannot silently jump to a newer object.

We addressed this by keeping the WebMCP surface deliberately small, excluding production-authority tools entirely, and resolving status and audit evidence against the exact proposal created by the agent.

Accomplishments that we're proud of

The agent can perform useful catalog work while people retain risk, approval, and production control.

The result is one collaboration workflow:

agent discovers → agent proposes → human authority → governed apply → Shopify

The WebMCP interaction ends before production authority begins.

What's next for CommerceGov

Next are richer policy explanations, stronger proposal diffs, and more governed mutation classes — under the same rule.

WebMCP may add capability. It may not add production authority.

Built With

• chatgpt
• codex
• cursor
• fastapi
• grok
• html
• oauth-2.0
• pkce
• postgresql
• python
• redis
• render
• shopify
• webmcp