FuseGuard: Trip Agent Loops Locally, See Blocks in Your Fleet Console

Agents retry forever when a tool schema drifts or a loop never terminates.

Your service dashboards look fine. Stripe still charges. Meanwhile the model burns tokens on tools/call that will never succeed — or spins in a loop because nothing enforces a fuse at the edge.

FuseGuard is the runtime complement to contract watches: DriftGuard tells you when a vendor changed the schema; FuseGuard stops bad calls before they compound. This post walks OSS policy simulation, then the hosted fleet console — about 10 minutes if you follow along.

---

The gap HTTP monitoring misses

Check	Sees runaway agent spend?	Sees MCP catalog drift?
API latency / 5xx	Sometimes	No
Scheduled tools/list diff	No	Yes (DriftGuard watches)
Local policy fuse on tool invocation	Yes	When wired to drift signals

You want both: observe contracts on a schedule, trip fuses at invocation time.

---

Step 1 — OSS fuse in CI (no card)

Install the open-source FuseGuard CLI from the DriftGuard repo and simulate a loop before merge:

git clone https://github.com/Drift-Guard/driftguard
cd driftguard/packages/fuseguard  # or follow README install path
fuseguard doctor
fuseguard policy simulate --policy examples/fuseguard/fuse.policy.yaml \
  --tool loop_tool --iteration 12

Policy denies the loop before another model round — same class of protection teams wire in agent gateways.

Wire fuseguard policy lint on PRs that touch agent tool manifests or MCP config. Fail fast when a change removes fuse rules your production overlay expects.

Docs: FuseGuard on driftguard.org.

---

Step 2 — Hosted fleet console (demo)

Open the Fuse view in the demo console (no signup required for the tour):

driftguard.org/console?demo=1&view=fuse

What to look for:

1. Activity — block reasons such as loop_detected and contract_drift_blocked
2. Metrics — estimated USD saved from denied invocations (FinOps-oriented, not vanity charts)
3. Features — org-level kill switch when you need to stop an agent fleet quickly

With the production overlay enabled, devices sync trip metadata to the hosted index — not full prompt exfiltration, just enough to audit blocks across a team.

---

Step 3 — Correlate drift → fuse

When a watch classifies a breaking change on an MCP endpoint, FuseGuard can block tools/call against the stale schema instead of letting the agent retry into a bill spike.

In the console, open a block row tied to a drifted watch — you get the incident trail from contract observability through runtime enforcement. That is the story we tell in sales engineering demos: detect on schedule, deny on invoke.

---

Pricing path (practitioner voice)

• Today: OSS fuse + policy lint in CI — no hosted key required.
• When you need fleet metrics: enable the FuseGuard product overlay on Pro-tier hosting; start with one endpoint on trial.

Start free — same trial as MCP watches; add FuseGuard from the console when you are ready.

Partner practitioners who recommend tools like this: driftguard.org/partners.

---

How this fits the DriftGuard series

Layer	Product surface
Baseline + diff	OSS compare_json, CI gates
Scheduled contract polls	Hosted watches + alerts
Runtime fuse + fleet	FuseGuard OSS + console overlay

Earlier posts in this series: silent MCP drift, ToolSchema lab, CI gate, contract drift monitoring (this queue — link updates after publish).

---

Try it

1. Run fuseguard policy simulate on a loop fixture in your repo.
2. Open the demo console Fuse view.
3. Start a trial when you want one watched MCP endpoint plus fleet overlay.

Question: Where would you enforce a fuse first — CI on policy files, the agent gateway, or both? Reply with your stack (Cursor, custom gateway, etc.) — I use threads to prioritize the next tutorial.

---

Series links

Post	Topic
Market gap / launch	Why silent MCP drift happens
ToolSchema lab	Hands-on MCP lab
CI gate	GitHub Actions funnel
MCP tool removed postmortem	Incident timeline

GitHub: Drift-Guard/driftguard · FuseGuard: driftguard.org/features/fuseguard

Comments

[Alex Shev]

Loop guards are becoming table stakes for agent systems. The interesting part is that token spend is often the first symptom, but the real issue is missing stop conditions. I like anything that makes runaway behavior visible locally before it becomes a fleet-level surprise.