About sentinel-agent
An agent that takes a production incident from alert to prepared fix without asking you anything — and then stops dead before the one action that matters, and asks.
When checkout latency triples, an engineer opens five tabs. Dashboards, to see the shape of it. The deploy log, to see what changed. GitHub, to read the diff. A terminal, to work out whether the change is big enough to explain it. And then a decision — roll back or keep digging — taken under time pressure on partial evidence.
The investigation is mechanical. The decision is not. Almost every attempt to automate this goes wrong in one of two directions: the tool only reports, and leaves you exactly where you started, or it acts on its own, and now a language model’s inference is wired straight into your production control plane.
sentinel-agent does the mechanical part completely, and stops at the decision. That split is the product: investigation is automated, execution is authorised.
What it actually does
Given one incident id, the agent reaches real systems over MCP, delegates three parallel lines of investigation to subagents, writes and runs diagnostic Python in an isolated sandbox to compute the magnitudes rather than estimate them, correlates the evidence into a root cause with a stated mechanism and a confidence number — and then pauses, holding the remediation until a human approves it.
- It reads. Incident, service health, deployment history, diffs, raw golden-signal samples. All seven of those tools are read-only, so none of them ever interrupts you.
- It computes.
export_metrics_csvreturns samples and no analysis, on purpose. The change point, the settled means and the ratio all have to be derived — which is what makes the sandbox load-bearing rather than decorative. - It argues. Before a gated call it must state action, target, evidence, mechanism, expected effect, risk, reversibility and confidence. A thin case is a failure, because a reasonable approver will decline it.
- It stops. Not by choice — by construction. The pause is enforced by the harness, in a place the agent cannot reach.
How it works
Four processes, one credential boundary. The UI is a view over harness events and holds no agent logic; the harness holds every key; the MCP server is reachable only from loopback; the sandbox gets its tool calls bridged back out so no credential ever enters it.
Why a harness is load-bearing
Remove TrueForge and this project does not degrade — it stops existing. Six things it carries that would otherwise have to be built from scratch, and gotten right under time pressure:
| Capability | What it carries |
|---|---|
MCP tool routing | Reaching the ops estate at all — discovery, schemas, dispatch. |
Approval gating | The entire safety model, enforced in the harness where the agent cannot bypass it. |
Sandbox orchestration | Isolated Python on demand, with tool calls bridged back so no credential enters it. |
Subagent delegation | Three investigation lines in parallel, isolated contexts, conclusions only. |
Session persistence | Surviving a page reload mid-investigation. |
Context management | Compaction and large-response offloading, so 61 samples plus four diffs still fit. |
The agent loop itself — plan, call tools, observe, decide, pause, resume — is the harness’s. sentinel-agent contributes the domain, the safety classification, the methodology, and the view.
Security posture
- No credential reaches this repo, the sandbox, or the UI. All three live in the harness.
- The MCP server binds
127.0.0.1by default and supports bearer auth, because the gate protects a path, not a tool — anything reaching the MCP server directly never encounters it. - The UI proxy refuses cross-origin mutations and requires an operator token for every state-changing method. It fails closed when unconfigured.
- The estate is simulated, so no real system is reachable from this repo. The protocol traffic against it is not simulated.
Try it in two commands
npm install && npm run dev:mcpnpm run doctor