Agent Kill Switches: What I Build vs. Salesforce Agent Fabric

The failure that scares me most in production is not the loud one. It is the agent that keeps returning HTTP 200, keeps looking busy, and is quietly wrong for six hours while the token meter spins. Salesforce just detailed the next phase of Agent Fabric to address exactly this, with evaluations that can trigger a kill switch. I have built this kind of control logic for unattended systems, so here is how I do it, and how it compares with what Agent Fabric is pitching.

What Salesforce actually announced (and what is not shipped yet)

On October 27, 2026, Salesforce announced Agent Evals, API Evals and advanced cost controls for Agent Fabric (Salesforce announcement). Agent Evals is meant to check agents, LLMs and MCP servers in production against defined quality thresholds, and when results fall short it triggers predefined interventions, including the Agent Kill Switch, with approval where team policy requires it (Tech Monitor).

The timeline matters. Agent Evals and API Evals go to beta in November 2026, with general availability in January 2027, and the evaluation-triggered shutdown (the Triggered-Agent Kill Switch) is also scheduled for January 2027. It is not available today (Technology Magazine). The sources I found disagree on exactly when the basic Kill Switch and the cost controls reached general availability, so check Salesforce's own pages before you plan around any date.

I also found no technical documentation on how Agent Evals defines thresholds, metrics or scoring. The press release only says "defined quality thresholds." So I will compare architecture and intent, not internals.

The three failure classes I design for

Every agent failure I have seen in production falls into one of three buckets, and each needs a different detector.

Loud failures are the easy ones, and any decent monitoring stack catches them. Runaway failures are cheap to prevent if you enforce limits at the call boundary rather than reporting them afterward. Quiet failures are the hard ones, and they are the reason evaluation-triggered shutdown is an interesting product category at all.

Most teams I see invest in the first class, bolt a budget alert onto the second, and ignore the third. Then a model swap or a prompt tweak makes answers subtly worse, and nothing fires, because nothing was measuring correctness in the first place.

Spend limits: enforce before the call, not after the invoice

My rule: a budget is only a control if it can say no. An alert that emails someone at 3 a.m. is a notification, not a control.

In my own systems every LLM call goes through a thin wrapper that checks a ledger before it sends the request. Here is the shape of it:

class BudgetExceeded(Exception):
    pass

def guarded_call(agent_id: str, model: str, est_tokens: int, fn):
    ledger = get_ledger(agent_id, window="daily")
    if ledger.spent_tokens + est_tokens > ledger.cap_tokens:
        raise BudgetExceeded(f"{agent_id} hit cap for {model}")
    if ledger.step_count >= ledger.max_steps_per_run:
        raise BudgetExceeded(f"{agent_id} exceeded step ceiling")
    result = fn()
    ledger.record(result.usage)
    return result

Three details that come from getting burned:

1. Count steps, not just tokens. A looping agent on a cheap model can burn fewer dollars than a single long-context call while still being badly broken. A per-run step ceiling catches loops that a dollar cap would miss for hours.
2. Budget per agent and per model. A shared pool lets one runaway agent starve the healthy ones. Per-agent ledgers keep the blast radius small.
3. Fail closed. If the ledger is unreachable, refuse the call. Failing open turns your safety mechanism into a single point of failure that disappears exactly when you need it.

Agent Fabric's Model Wallet is built on the same principle. Budgets can be set per provider and model, capped by dollar value or token count, on daily, weekly or monthly grants (MuleSoft blog). Hard limits work by refusing requests once an agent reaches its ceiling, not by alerting after the fact (MuleSoft blog). That is the right design, and it matches what I would build. Budgets are tracked live as spend accrues, and forecasting flags a projected overrun days in advance (MuleSoft).

Note what the documentation implies about prerequisites: model wallets and rogue-agent detection need an identity provider that issues JWTs, and Omni Gateway 1.13.5 or later (MuleSoft docs). Per-agent enforcement depends on being able to identify the agent on every call. If you build your own, the same dependency exists: agent identity has to be solved first.

Detecting quiet failures: sampled evals with a trip wire

Here is the part where I can say what I do, and where I have to be careful about what I can say about Salesforce.

For quiet failures I run a continuous evaluation loop on production traffic. The pattern:

1. Sample, don't score everything. Evaluating every response doubles your cost and latency. I score a rotating sample, with a higher rate on new prompt or model versions and on high-stakes intents.
2. Use two kinds of checks. Deterministic assertions (schema valid, required fields present, cited ID actually exists in the database) are cheap and precise. An LLM judge handles the fuzzy rubric questions. I trust the deterministic checks far more, and I weight them accordingly.
3. Trip on a rate over a window, not a single failure. One bad answer is noise. A failing-rate crossing a threshold across, say, the last N sampled responses is a signal. Single-failure triggers produce false-positive shutdowns that teach your team to disable the kill switch.
4. Keep a golden set. A small fixed set of known-answer cases runs on every deploy and on a schedule. It is the only thing that catches regressions from a silent upstream model change.

A minimal trip wire looks like this:

def should_trip(results, window=50, fail_rate=0.15, min_samples=20):
    recent = results[-window:]
    if len(recent) < min_samples:
        return False
    failures = sum(1 for r in recent if not r.passed)
    return failures / len(recent) >= fail_rate

The min_samples guard is the unglamorous part that matters. Without it, the first two failures after a restart trip the wire on a sample size of two.

Salesforce's pitch is that this loop becomes a platform feature: evaluate in production, compare against thresholds, trigger an intervention. It also cites a statistic that fewer than half of organizations with AI agents evaluate them on live traffic (Tech Monitor). That is a vendor-cited figure with no independent verification I could find, but it matches what I see: most teams test before launch and then stop looking.

What "kill" should mean, and why the details matter

This is the section I would read twice if I were evaluating any kill switch, mine or a vendor's.

"Shut down" is doing a lot of work in the headline. In MuleSoft's current documentation, the Kill Switch policy is applied per model proxy and blocks a quarantined agent's access to that proxy. Quarantine always requires human review and can be reversed (MuleSoft docs). The runtime enforcement point is Omni Gateway, which sits in front of agents, APIs, MCP servers and LLM traffic (MuleSoft docs).

That is a gateway-level cut, and it is a sound design for what it covers. But cutting an agent's access to a model proxy is not the same as terminating the process that hosts the agent. VentureBeat notes that blocking access through a gateway does not necessarily stop processes running on the external platform hosting the agent. I would not claim more than the docs say: it blocks access, and what happens to the rest of the agent depends on where it runs and what else it can reach.

In my own systems I think about kill as a ladder with distinct rungs:

A single "kill" button that jumps straight to rung 3 or 4 on a noisy signal is how you take down a healthy revenue-generating agent at 2 a.m. I let low-confidence signals trigger the low rungs automatically and reserve the high rungs for strong signals or a human. The rungs also have to cover every path the agent can act through, not just the LLM call. If the agent holds database credentials or an email API key, cutting model access alone leaves the dangerous capabilities live.

There is also an open question about automation. Current MuleSoft docs say quarantine always requires human review, while Salesforce's announcement says evaluation-triggered intervention needs approval only where policy requires it. How automatic the January 2027 Triggered-Agent Kill Switch will be is not documented in what I found. I would want that answered before depending on it.

Governance: the boring part that decides whether any of this works

Controls are only as good as your inventory. You cannot put a budget or a kill switch on an agent you do not know exists.

This is the part of Agent Fabric's pitch I find most credible from an operations standpoint. Its scanners automatically detect and register agents, MCP servers and APIs from ecosystems including Amazon, Google, Microsoft, Claude, Databricks and Kong into an Agent Registry (Salesforce). The October announcement also added a Custom Agent Scanner and Open Policies for Federated API Gateways (Artiverse). Shadow agents are a real problem: someone wires up an MCP server on a Friday and nobody governs it.

When I build this myself, governance reduces to four artifacts per agent:

• An owner. A named human or team, not a distribution list.
• A budget. Per-agent, per-model, hard-enforced.
• A trip policy. Which signals trigger which rung, and who approves the high rungs.
• An audit trail. Every call, every eval result, every intervention, queryable after the fact.

The audit trail is what lets you tune thresholds honestly. Without it you cannot tell whether your kill switch is too sensitive or not sensitive enough.

What I'd do

If I were advising a team today:

1. Build the cheap controls now. Hard per-agent spend and step ceilings, enforced at the call boundary, failing closed. This takes days, not months, and it does not depend on anyone's roadmap.
2. Start sampling production output this week. A golden set plus deterministic assertions gets you most of the value before you ever need an LLM judge.
3. Define your kill ladder on paper before choosing tools. Know which signals trigger which rung and who can approve the top two. Then evaluate whether a platform's kill switch actually covers the paths your agents use.
4. If you are already in the Salesforce and MuleSoft ecosystem, watch the beta. A gateway-enforced control plane with a registry, model wallets and evals in one place is genuinely attractive, and the gateway-level enforcement is the right architecture. Treat the January 2027 evaluation-triggered shutdown as a roadmap item until it ships and you have tested what it does to a real agent.
5. Treat the vendor numbers as vendor numbers. The claimed token reductions of up to 75% from semantic caching, payload compression and response trimming are test-scenario results, not a guaranteed saving on your bill (VentureBeat). The 1.2 billion requests per day figure (Compare the Cloud) tells you about scale, not about how well evals catch your particular failures. Measure on your own traffic.

The direction is right: evaluation tied to enforcement is where agent operations has to go. The details of what gets cut, how fast, and who approves it are where these systems succeed or fail.

If you are working through this for a production agent system and want a second pair of eyes, you can reach me at lazar-milicevic.com/#contact, or keep reading on the blog.