Protocol-0 is an MCP server that lets Claude, Cursor, ChatGPT, or NitroChat diagnose infrastructure incidents and propose fixes, but it will not run a single mutation unless the request carries a valid HMAC signature. Built by Team TheBlacklisted at Amrita Vishwa Vidyapeetham Coimbatore, it treats AI authority over production systems as something to be proven, not assumed.
What this enables
- Routes incidents through separate Monitoring, Infrastructure, and Incident Commander agents instead of one generic assistant loop
- Blocks every infrastructure-mutating tool call behind a cryptographic HMAC check, enforced in the handler, not in a prompt
- Runs a What-If Disaster Simulator that estimates blast radius for scenarios like losing a cloud region before anything actually breaks
- Writes every decision, human or model-made, to a tamper-evident audit trail exposed as an MCP resource
- Exposes 21 tools, 5 resources, 5 prompts, and 4 UI widgets to any MCP-compatible client without a separate integration for each one
The 3 a.m. problem this is built for
On-call engineers already know the shape of a bad incident: metrics live in one dashboard, tickets live in another, deploy history is somewhere else, and paging is its own system. An SRE has to hold all of that in their head while deciding whether to roll back, patch, or escalate, usually at the worst possible hour.
Handing that decision loop to an AI assistant sounds appealing until it can act. A model that can call an API to restart a service or redeploy a node is also a model that can be talked into doing it under the wrong conditions, by a bad prompt, a bad actor, or its own reasoning error. The interesting engineering problem is not "can an AI diagnose an outage." It is closer to "how do you let an AI diagnose and even propose a fix, while making it structurally impossible for it to execute anything destructive without an explicit, unforgeable authorization."
Why MCP is the right boundary here
MCP separates what a client can ask for from what the server is willing to run. Protocol-0 uses that separation directly: read-only diagnostic tools sit on one side, and the handful of tools that mutate infrastructure sit behind a guard that checks for a signed authorization payload before the handler body even executes. Because the server is a standard MCP server rather than a bespoke integration, the same tool set and the same gate apply whether the caller is Claude Desktop, a ChatGPT App, or the project's own NitroChat-based dashboard. Nothing about the safety logic has to be reimplemented per client.
Inside the incident loop
A typical run through the system follows a fixed sequence:
- A monitoring signal (a triggered incident, a security alert, or a manual prompt like "simulate a CPU spike") enters the graph.
- The Monitoring Agent pulls the relevant telemetry or audit log context.
- The Infrastructure Agent correlates that context against the affected system, for example matching a suspicious IP against a specific Kubernetes node.
- The Incident Commander evaluates business impact and SLA risk, then proposes a remediation, such as redeploying a set of gateway replicas.
- If a human or client approves the action, the Action Agent requests execution, but only proceeds once it verifies the HMAC-signed zero-trust payload.
- The outcome, along with every intermediate decision, is appended to the tamper-evident audit trail as an MCP resource, queryable later through an incident report tool.
The demo build routes this reasoning through Google's Gemini models and mocks the downstream Datadog, Jira, GitHub, PagerDuty, and Kubernetes calls with deterministic adapters, so the full loop runs end to end without touching real infrastructure. The simulate_disaster tool follows a separate path: instead of waiting for a real failure, it lets an operator ask "what happens if we lose eu-west-1" and get a blast-radius estimate back before anything is actually down.
Where NitroStack fits
Protocol-0 is structured as a NitroStack SDK application: tools, resources, prompts, and widgets are declared through the SDK's decorator pattern rather than hand-rolled request routing, which is why the project can expose 21 tools and 5 resources without the server logic sprawling into an unmanageable file. The guard that enforces the zero-trust HMAC check sits in that same tool layer, so the authorization boundary is part of the application's structure instead of a bolt-on middleware step.
The server is deployed live on NitroCloud, reachable at a public MCP endpoint that any compatible client can connect to directly. That matters for a hackathon-scale team specifically because it removes the need to stand up and maintain separate container infrastructure just to make the project reachable from Claude or Cursor. The same deployed server also backs the project's own web dashboard, built with a NitroChat-style conversational surface, so a developer can test tool calls directly against production behavior rather than a local mock.
The part worth paying attention to
The obvious story here is "AI that fixes outages." The more useful detail is where the trust boundary actually sits. Protocol-0 does not rely on the model to decide when to be careful. The Action Agent's handler checks for a valid signed payload before it does anything else, which means even a compromised or adversarially prompted client cannot skip the check by asking nicely. That is a meaningfully different design than a system prompt that tells the model to "always confirm before destructive actions," because a system prompt is a suggestion and a cryptographic check in the handler is not.
The trade-off is real, too: a hard gate means legitimate urgent fixes also have to clear the same bar as everything else. For a team building this pattern further, that argues for a fast, well-designed approval path rather than a shortcut around the gate itself.
What the build demonstrates
Protocol-0 is a proof-of-concept level build, not a verified enterprise deployment. What it does demonstrate cleanly is that a multi-agent incident response graph, a cryptographic execution gate, and a tamper-evident audit log can all be expressed as ordinary MCP primitives and served from one deployed endpoint to multiple different clients without per-client rework. The mocked integrations mean the diagnostic and remediation logic has been exercised end to end, even though it has not yet been run against a live production environment.
The reusable pattern
The takeaway is not "add AI to your SRE process." It is that giving a model real authority over infrastructure works better as an architecture decision than a prompting decision: keep diagnosis and recommendation on the conversational side, and put every state-changing action behind a mechanism the model itself cannot talk its way around. MCP gives that separation a clean home, since read tools, write tools, and the audit trail can all live in the same server with different rules attached to each.
Explore the source and connect to the live MCP endpoint on GitHub, or read more about building MCP servers with NitroStack's SDK and deploying them on NitroCloud.