ProdPermit

Home Screen
WebMCP Tools
Audit Logs

Project name

ProdPermit

Inspiration

AI agents can investigate production incidents faster than a person moving between dashboards, logs, release history, and diagnostics. However, giving an agent permanent production access creates a serious risk.

ProdPermit explores a safer model: the agent investigates and prepares an exact recovery, while a person retains authority over execution.

What it does

ProdPermit presents a simulated checkout incident caused by release_284. The release changed database authentication to password, while the database still requires scram-sha-256.

The website exposes six initial WebMCP tools:

inspect_incident
compare_releases
query_logs
run_diagnostic
prepare_recovery
verify_recovery

The agent uses these tools to identify the authentication mismatch and prepare a rollback to the healthy release_283.

Preparing the plan does not change production. ProdPermit displays the target release, supporting evidence, expiry, risk, and SHA-256 fingerprint for human review.

Only after the person clicks Approve exact plan does the browser register execute_approved_recovery. The temporary tool can execute only that approved plan. It disappears after execution, rejection, revocation, reset, or expiry.

After execution, checkout returns to a healthy state:

Error rate falls from 18.7% to 0.2%
P95 latency falls from 1,420 ms to 176 ms
Database status changes to DB_CONNECTION_OK
The audit timeline records preparation, approval, execution, and verification

Why WebMCP

WebMCP gives the agent typed, purpose-built operations instead of forcing it to scrape labels or guess which buttons to click.

More importantly, the website can change the available tools when authority changes. The agent can investigate immediately, but execution does not exist until a person approves one exact recovery.

This creates a clear partnership: the agent gathers evidence and recommends an action, while the human controls the production decision.

How we built it

The Next.js and React frontend registers tools through document.modelContext.registerTool. Zod validates data at the browser boundary.

A Rust and Axum backend owns the recovery rules, authorization checks, session state, expiry, replay protection, and plan fingerprints. SQLite stores isolated demo sessions, evidence, plans, recovery results, and audit events.

Vercel hosts the frontend. Cloudflare Tunnel connects the public application to the loopback-only Rust service. Tailscale Funnel provides a fallback route.

Challenges

The hardest part was making human approval a real authorization boundary instead of a cosmetic confirmation button.

The backend must reject unapproved, modified, stale, expired, replayed, and cross-session plans. Execution, telemetry changes, diagnostic results, and audit records must also commit atomically.

We also handled browser registration behavior, session revocation, persistent recovery state, tunnel reliability, and end-to-end WebMCP testing.

What we learned

WebMCP works best when websites expose meaningful domain operations rather than generic interface controls.

We also learned that dangerous capabilities do not need to exist permanently. A website can register a narrow tool only when the server confirms that the human has granted temporary authority.

What's next

ProdPermit currently demonstrates one deterministic checkout incident. The next version could support multiple services, recovery actions, organization roles, approval policies, and real deployment providers.