Firebreak
Agentic demos ask: How much can the agent do? For incident response, I think the question becomes How much should it be allowed to do? Speed is useful. Standing authority is not. Firebreak separates the two.
What it does Firebreak gives a browser agent nine intent-level WebMCP tools to investigate a checkout outage. The agent gathers evidence, correlates recent changes and tests recovery options.
A payment-database restart gets rejected because it threatens protected outcomes: payments and accepted orders.
Similarly, a safer checkout rollback becomes an Action Contract bound to the system state, evidence, blast radius, expiry, verification and compensation plan.
The human authorises that exact contract. Only then can the agent execute. If state changes, the authority becomes stale. If execution is retried, it remains idempotent. If verification fails, compensation is required instead of declaring false success.
The result is a complete chain: investigate - propose - authorise - execute - verify - receipt
Why WebMCP Incident response is an incorrect place for agents to infer intent from pixels. It is urgent, stateful and potentially destructive.
Firebreak exposes intent. The agent can inspect, simulate, prepare, execute and verify through narrow typed tools.
The UI and WebMCP tools use the same deterministic application service, so there is no privileged agent path around the controls visible to the human, but one capability is deliberately missing: human authorisation . The agent can request authority, but it cannot grant authority to itself.
Better human-agent collaboration The agent handles the repetitive work: investigation, correlation, simulation and proposal. The human makes the consequential decision. They see before approving anything.
And the approval is not: “let the agent operate.” It's: this action, against this state, under these constraints. That's the core of Firebreak. Intelligence can stay flexible. Authority should be precise.
Who can use it The current implementation is a checkout recovery scenario, though the pattern extends to SRE, security, commerce, data and regulated operations where agents can investigate and prepare consequential work without receiving standing authority.
The important abstraction is a proper roadmap from investigation to proposal - authority - execution - verification. Other domains would still require their own identity, provider adapters, telemetry, policy and tested rollback paths.
How it was built Firebreak uses React and TypeScript with a deterministic domain engine. That engine owns revisioned state, protected outcomes, constraints, expiring Action Contracts, idempotent execution, verification, compensation and receipts.
Nine WebMCP tools sit on top of the same service used by the human interface. Vitest, Playwright and deterministic journey fixtures test the system from foundation through workflow and stress cases. The demo requires no API key, cloud account or production credentials.
Making approval mean something is harder. If state changes after approval, should the old approval still work? No. If execution retries, should the action happen twice? No. If the command runs but recovery fails, should we call it success? No. If the agent can approve itself, was there ever a human boundary? No. Firebreak turns those answers into system properties instead of UI promises.
What we learned Agents do not need more buttons. They need better abstractions like Raw controls, implementation and intent-level tools for meaning. And once intent is explicit, we can attach evidence, policy, authority and verification to it. That makes agents easier to guide.
Try it Live app: https://neel-error404.github.io/firebreak-webmcp/
Source: https://github.com/Neel-Error404/firebreak-webmcp
The intended flow: inspect - correlate - reject unsafe recovery - prepare rollback - human authorisation - execute - verify - recept
What's next Firebreak is a prototype; production would require signed identities, durable audit storage, isolated real connectors, stronger policy authoring, broader evaluations and staged deployment evidence.
We want to explore & make capability bounded, legible and accountable.
Built With
- playwright
- react
- typescript
- vite
- vitest
- webmcp
Log in or sign up for Devpost to join the conversation.