DEV Community: yongrean

Prompt injection starts in your inbox. The defense can't be a prompt.

yongrean — Wed, 26 Aug 2026 18:46:31 +0000

Cross-posted from klorn.ai/blog — continuing the receipts discussion from my last post's comments.

Every AI assistant that reads email shares one threat model, usually unstated: the primary input is text written by strangers, delivered free, from anywhere, by design. A crafted message that steers the model isn't a breach of anything — it's email working as intended.

Here are the four layers Klorn puts between that message and anything irreversible, and an honest accounting of which are promises and which are properties.

Layer 1 — Wrapper hygiene (a promise, kept tidy)

Every email subject, body and third-party string is wrapped in <untrusted_content> markers before it reaches a model, and pre-existing wrapper tags are stripped from the message first — so a sender who includes </untrusted_content> in their email cannot close the wrapper and promote their text to instructions. The classifier's system prompt states that anything inside the tags is data, and that a message arguing about its own classification is an injection attempt.

Be clear about what this is: instructions to a model are a policy. A sufficiently clever message may still steer scores. This layer raises the cost of the attack; it cannot make the attack impossible, and any vendor telling you otherwise is describing a prompt.

Layer 2 — The model has nothing to steal

The structural defense is what the model is allowed to output: four numbers. Confidence, sender trust, reversibility, urgency — a deterministic, unit-tested rule maps them to one of five lanes. So the worst a fully-steered classifier can achieve is a wrong lane, and the failure direction of a wrong lane is pinned by a CI-enforced test: urgent mail never degrades to the hidden lane, only to the visible queue.

A hostile email can waste your attention. It cannot spend your authority.

Layer 3 — Irreversible actions bind bytes, not intent

Send, permanent delete and forward-external cannot ride on model confidence at all. Approval mints a receipt: a sha256 over the canonical payload — action type, schema version, normalized recipient, message ID — at the moment a human says yes. At execution the payload is re-hashed and compared; any drift between what you approved and what is about to run throws, and the action is refused.

The verifier is hash comparison in the execution path — it cannot read English, so there is no phrasing that gets past it. This one is a property.

(A commenter on the last post asked whether the hash binds the operation envelope or just the body — the answer, with test names, ended up improving this section. The negative test they proposed, "swap only the recipient after approval," already exists as flips when recipient changes; the two things it surfaced that weren't covered are now tracked issues.)

Layer 4 — Autonomy is opt-in, twice

The assistant's default mode is suggest-only. Unattended replies require the account-level AUTO mode and a per-message eligibility flag (reversible, high-confidence, trusted sender, not urgent) — and every unattended send still writes a receipt. Classification never silently becomes action.

What's still missing, stated plainly

The repo's SECURITY.md maps each claim above to the test that enforces it and to what would falsify it — and it also names the gap: there is no end-to-end adversarial corpus yet, fixtures that start from a hostile email and assert containment across the whole path. That's written down rather than hidden, because the difference between a security page and security is whether the gaps are on it.

Everything above is AGPL and checkable: github.com/k08200/klorn

Every AI email tool has the same bug. It is not a bug in the model.

yongrean — Tue, 25 Aug 2026 17:45:39 +0000

Every AI email product shipped in the last two years has the same architecture, and it is the wrong one.

The model reads your mail. The model decides what matters. The model drafts a reply, and in the ambitious ones, the model sends it. Somewhere in the system prompt there is a paragraph asking it politely to check with you first.

That paragraph is the entire safety story. That is the bug.

The bug is not that models hallucinate

Everyone knows models hallucinate. That is priced in. The bug is subtler and worse: these systems give the model authority, then try to constrain it with instructions.

Instructions are input. Your email is also input. And your email is written by strangers.

So the threat model is not "the model is sometimes wrong." It is: someone who wants your model to do something writes an email designed to make it do that. They do not need to breach your infrastructure. They just have to send you mail — which is a thing they are already allowed to do, by design, for free, from anywhere on earth.

Ask whatever AI inbox tool you use one question:

When it decides to hide a message from me, what artifact can I read to see why? Not a natural-language explanation the model generated afterward — the actual decision.

There usually isn't one. The decision was a forward pass. It left no trace you can audit, test, or pin.

The fix is boring and nobody ships it

Separate perception from authority.

Let the model do what models are genuinely good at: read messy text, produce a few calibrated numbers. Then let code make the decision.

In my own tool the model never picks the outcome. It scores four features per email — confidence, sender trust, reversibility, urgency — and a deterministic, unit-tested rule maps those four numbers to exactly one of five lanes: interrupt me now, it's scheduling, queue it, file it as a record, or never render it. That rule is about 200 lines. You can read it. A test pins it. If its behaviour changes, CI fails.

Three things fall out of that split, and they are why I think this is a correctness argument rather than a style preference.

Model choice stops being a vibe and becomes a measurement. I re-ran my committed 56-email gate set across six current models today — same prompt, same rule, one run each:

model	overall	urgent recall	$/M input
gpt-5.4	100% (56/56)	13/13	$2.50
gemini-3.5-flash	98.2%	13/13	$1.50
gemini-2.5-flash	96.4%	13/13	$0.30
grok-4.3	94.6%	12/13	$1.25
claude-opus-4.8	91.1%	10/13	$5.00
claude-sonnet-5	80.4%	5/13	$2.00

I had been telling people a cheap model beats the expensive ones. That is no longer true and I am retiring it — gpt-5.4 is perfect on this set. But look at what replaced it, because it is worse news for the industry, not better: price does not order the table. The most expensive model lands fifth. Two frontier models fail my gate outright. And the spread among frontier models is 19.6 points — five times the 3.6-point gap between the best of them and a pin that costs eight times less.

If you picked your model because it benchmarks well, you picked on a number that has nothing to do with this job.

A failure gets a mechanism instead of a shrug. Sonnet 5 missed eight urgent emails. Seven of them failed on confidence, not urgency — it scored urgency 0.80–1.00, which is correct, and confidence 0.55–0.60, against a rule that needs 0.70 to interrupt you. It read the situation right and then declined to say it was sure.

I know that because the threshold is a number in a file I can open. In a "the model picks the tier" design, this same result reads as Sonnet 5 is worse at email — which is both wrong and useless. You cannot fix a vibe.

It degrades instead of breaking. With no LLM at all — provider down, rate limited, key expired — a keyword path produces the same four features and still classifies at 82.1%. I want to be precise about what that does and does not buy, because I have been sloppy about it before: urgent recall in that mode is 46.2%. Degraded mode costs you the interrupt. It does not cost you the message — every urgent item it missed landed in the queue, visible, and none were hidden.

Automation is not a lane

This is the part people get wrong when they copy the pattern.

Classification and delegation are separate decisions, and collapsing them is how "it sorted my mail" becomes "it answered my mail." A lane says what a message is. A separate flag says whether this particular message is even eligible to be answered unattended — reversible, high confidence, trusted sender, not urgent. And a separate account-level mode says whether unattended answering is on at all.

Three switches, not one. You can be wrong about the lane and still not be wrong about the outbox.

Approval has to bind bytes, not intent

The classification half is the easy half. The hard part is the three actions you cannot take back: send, permanent delete, forward.

Most tools gate those behind a confirmation dialog. That is theater, because what you confirmed and what executes are connected by nothing but hope.

So: approving mints a receipt — a sha256 over the exact canonical payload bytes at the moment you click yes. At execution the bytes are hashed again and compared. Any drift and it fails closed. No send, no delete, no forward.

The check does not live in the prompt. It lives in the execution path. There is no phrasing that gets around it, because the thing doing the checking cannot read English.

That is the difference between a safety policy and a safety property.

The part where I make this falsifiable

Claims like these are cheap, so here is mine, stated so you can break it:

Given an inbound message crafted to maximize model confidence, no path exists from classification to an executed irreversible action without a human approval that byte-pins the payload.

Note what that does not say. It does not say the model can't be fooled — it can. It does not say the lane will be right — a hostile message may well land in PUSH. That is a nuisance, not a breach. The floor is not a better classifier. It is a smaller blast radius.

The repo's SECURITY.md lists nine claims like that one, and for each: what would disprove it, and which test enforces it. It also names what has no authority — including my own accuracy numbers. A 96% classification score is not a safety argument, and I would rather say so myself than let it quietly stand in for one.

Here is the same rule applied to me. While writing this I re-ran my real-mail eval set and it came back at 86.8%, not the 94.3% my README had been claiming for weeks. The gap turned out to be fully explained — four of the seven misses are a lane the labels predate, and 46 + 4 = 50 is exactly the old number — but "fully explained" is not the same as "still true." The number stopped reproducing, so it is out of the README as of today, along with the model claim above. If you want to check either one, the eval sets and the runner are in the repo.

That is the actual test of whether a project means the falsifier thing: what happens when its own number fails.

It also lists what is missing. There is no end-to-end adversarial corpus yet — fixtures that start from a hostile email and assert containment across the whole path. That gap is written down in the repo, not hidden.

So

If you use anything with an LLM near your inbox, go find out how it decides. If the answer is "the model decides, and we told it to be careful," you are trusting a probability distribution with your outbox.

You do not have to use mine. It's AGPL, self-hostable, docker compose up -d with prebuilt images, and it runs against a local model if you want nothing leaving your machine at all. But whatever you use — make it show you the decision.

Six months solo, 101 releases, ~1,590 commits. If you think the architecture is wrong, the fastest way to prove it is a PR that breaks the claim above. I'll merge it.

github.com/k08200/klorn

My cost cap over-billed by 100x. That cost uptime, not money.

yongrean — Tue, 18 Aug 2026 14:00:00 +0000

A cost cap is supposed to be the boring part. You pick a number, you stop spending past it, you go back to work. Mine did the opposite: it became the thing most likely to take my service down, and it did that while the actual bill stayed under a dollar.

The bug was a substring match in a pricing table. The interesting part is not the bug — it is that I had already "fixed" this table once, in the safe direction, and the safe direction is what broke it.

The thing being capped

Klorn classifies every inbound email into exactly one of four tiers. Every classification is one LLM call, so cost scales with mail volume, and mail volume is not something I control. That is the whole reason a ceiling exists.

There are three of them:

// packages/api/src/config.ts
export const DAILY_COST_CAP_CENTS = intEnv("DAILY_COST_CAP_CENTS", 100);        // $1.00 / user / day
export const FREE_DAILY_COST_CAP_CENTS = intEnv("FREE_DAILY_COST_CAP_CENTS", 10); // $0.10 free tier
export const GLOBAL_DAILY_COST_CAP_CENTS = intEnv("GLOBAL_DAILY_COST_CAP_CENTS", 5000); // $50 / day fleet-wide

The per-user caps are the real guard. The global one is the fatal-bill backstop — the thing that stops a runaway loop from producing a five-figure invoice while I sleep.

None of these can meter a real invoice in real time. They estimate: token counts times a per-model rate, accumulated into a ledger. So there is a table mapping model id to price, and everything downstream trusts it.

The first bug: one price for everything

The original table had a single rate for paid models. Whatever the model was, it got billed at roughly Gemini Flash prices.

That is fine right up until a fallback chain routes a request to Claude Sonnet, which is 10x Flash on input and 6x on output. The ledger records Flash. The cap sees a number far below the truth, never fires, and the protection you think you have is decorative. This is the failure mode everyone anticipates when they build a cost cap: under-billing, which costs money.

So I fixed it in the obvious direction — a family table, and an explicit decision about what to do with models the table has never seen:

/**
 * Unknown paid models price at the sonnet tier, NOT at flash rates: a new
 * frontier model landing in CHAT_MODEL before this table learns it must be
 * over-billed against the caps, never 20x under-billed (the original bug).
 */
const DEFAULT_MODEL_RATE: ModelRateUsdPerMTok = { input: 3, output: 15 };

Unknown model? Charge it like Sonnet. Over-estimate on purpose. If I am wrong, I am wrong in the direction that stops spending too early rather than too late.

That reasoning is correct, and it is also how I shipped the second bug.

The second bug: the safe direction has a cost

Klorn's judge has a fallback chain — cheap paid SKUs it drops to when the primary model is rate-limited or down. Those SKUs are genuinely cheap. Not "cheaper," cheap enough to change the shape of the arithmetic.

The table matched them by substring. First row where every needle appears in the model id wins. So:

Model	Real rate (in/out per 1M)	What the table charged	Off by
`openai/gpt-oss-120b`	$0.037 / $0.17	$2.50 / $10.00 — matched the generic `["gpt"]` row	~67x / ~59x
`qwen/qwen3.7-flash`	$0.03 / $0.13	$3.00 / $15.00 — matched nothing, took the Sonnet default	~100x / ~115x
`mistralai/mistral-nemo`	$0.019 / $0.03	$2.00 / $6.00 — matched the generic `["mistral"]` row	~105x / ~200x

Every one of these is an over-estimate. Every one of them is "safe" by the rule I had just written down.

Now put it against the load. Measured, not guessed: a classification is about 1,000 prompt tokens and 100 completion tokens. At 100 users doing 100 emails a day, that is 10,000 classifications, which at the primary model's real rates is about $5.50/day — call it $7/day with reply drafts and briefings on top. Against a $50/day ceiling that is roughly 7x headroom, which is the amount of headroom I wanted.

Now suppose the primary is rate-limited and the fleet spends the day on qwen/qwen3.7-flash, the cheap middle of the chain. The real cost of that same work drops, because the fallback is cheaper than the primary: 10,000 calls at $0.03/$0.13 per 1M is about $0.43/day. The ledger, pricing it at the Sonnet default of $3/$15, records $45/day.

The same work. Two numbers, a hundredfold apart, and the cap acts on the wrong one.

$45 against a $50 ceiling means the fleet trips the global cap inside a single day — and on any day with more mail than average, it trips mid-morning. When it trips, classification stops. For everyone. Not because anything cost too much, but because a substring did not match.

Over-billing is not the safe direction. It is a different direction.

This is the part I got wrong, and it generalizes past my codebase.

I had been reasoning about the cap as a financial control, where the two failure modes are "spent too much" and "spent too little," and only one of them is dangerous. Under that model, over-estimating is free.

But a cap is not only a financial control. It is a runtime dependency of the request path. Every classification asks it for permission. Which means the error budget has two axes, not one:

Under-billing costs money. It fails open. The system keeps working while the invoice grows.
Over-billing costs availability. It fails closed. The invoice is fine and the product stops.

A protective ceiling that fires during normal operation has stopped protecting and started breaking. And over-billing is the sneakier of the two, because it never shows up on a bill you can go look at. The one artifact that would tell you something is wrong — a large invoice — is precisely the thing that does not happen. You get an outage with a healthy credit card.

There is a second-order version of this too. I had separately raised the global cap from $10/day to $50/day, correctly, because $10 left barely one heavy day of headroom against $7/day steady state. A protective ceiling that fires in normal operation is not a ceiling, it is a scheduled outage. But raising the ceiling also hides mis-metering for longer: with a $10 cap the 100x error would have tripped in an hour and I would have found it immediately. Slack in the system is not free either — it buys you time and it buys the bug time.

The fix, and the invariant that keeps it fixed

The fix is unglamorous — explicit rows above the generic ones, because first match wins:

// Cheap fallback SKUs, priced from the live OpenRouter catalog 2026-08-10
// and rounded up. These rows exist because the generic family rows below
// mis-price them by 60-100x [...] Over-billing is "safe" for a protective
// cap in isolation, but at 100 users it burns the daily caps ~100x too fast
// and the fleet stops classifying mid-day — the caps stop protecting and
// start breaking. Specific rows MUST stay above generic.
{ match: ["gpt-oss"], rate: { input: 0.05, output: 0.2 } },
{ match: ["qwen"], rate: { input: 0.1, output: 0.3 } },
{ match: ["mistral", "nemo"], rate: { input: 0.05, output: 0.1 } },
{ match: ["nemotron"], rate: { input: 0.1, output: 0.4 } },

Note these are still rounded up from the real catalog prices — between 1.2x and 3.3x, depending on the row. That is deliberate: the catalog moves, and a table that under-bills is the first bug again. Over-estimating by 3x is a rounding policy against a moving target. Over-estimating by 100x is an outage. The direction was never the problem; the magnitude was.

Ordering is now load-bearing, which means a comment is not enough. It is pinned by a table-driven test:

// packages/api/src/__tests__/model-fallback.test.ts
describe("fallback-chain SKUs are metered at their real rates (100-user economics)", () => {
  it.each([
    ["openai/gpt-oss-120b", 0.05, 0.2],
    ["qwen/qwen3.7-flash", 0.1, 0.3],
    ["mistralai/mistral-nemo", 0.05, 0.1],
    ["google/gemini-3.1-flash-lite", 0.25, 1.5],
    ["openai/gpt-5-nano", 0.1, 0.4],
  ])("%s is priced at $%s/$%s per M", (model, input, output) => {
    expect(resolveModelRateUsdPerMTok(model)).toEqual({ input, output });
  });

  it("keeps the sonnet-tier default for genuinely unknown models", () => {
    expect(resolveModelRateUsdPerMTok("acme/brand-new-frontier")).toEqual({
      input: 3,
      output: 15,
    });
  });
});

Every entry in the chain is in that table now, not just the three that were wrong — because the next person to add a chain entry should see a row missing, not guess. And the second test pins the unknown-model default deliberately, so a future contributor does not "simplify" the over-billing away.

The operational rule that falls out: any model added to the fallback chain must be added to the rate table in the same change. A chain entry without a rate row is not a missing optimization, it is a latent 100x metering error pointed at your availability.

What I would tell past me

Three things, in order of how much they cost to learn.

Ask what your cap actually gates. If the answer is "the request path," it is a dependency, and dependencies get availability budgets, not just correctness checks. I had been treating mine as an accounting feature.

Write down which direction of error is safe, and then check whether that is still true at scale. "Over-estimate on purpose" was correct in isolation and wrong at 10,000 calls a day. The rule did not change; the multiplier did. Any heuristic phrased as a direction rather than a magnitude has this failure mode waiting in it.

Instrument the ratio, not the total. A dashboard of daily spend would have shown $45 and looked like a busy day. What would have caught this in minutes is metered cost divided by a sanity estimate of real cost — a number that should sit near 1 and was sitting near 100. I did not have that, and the thing that eventually surfaced it was working through the unit economics on paper before the user count made it urgent.

The whole thing is open source under AGPL if you want to read the table, the ordering constraint, or the tests around it — github.com/k08200/klorn. The pricing table and the fallback resolver live in packages/api/src/llm/model-fallback.ts.

If you run LLM calls behind a spend ceiling, go check what your table does with the cheapest model in your fallback chain. The expensive models are the ones you remembered to price.

Gate on what the model can't author (my comment section redesigned my trust model)

yongrean — Wed, 01 Jul 2026 15:58:02 +0000

Post four argued that of the four features my email classifier scores — confidence, sender trust, reversibility, urgency — confidence is the odd one out: the only one with no source outside the model's opinion of itself. Then the comment section did something better than the post. Four people — @jugeni, @txdesk, @hannune, and @nazar_boyko — took the loose idea and turned it into a spec. This post is that spec, credited to them, and it's now filed as issues on the repo.

The principle, stated properly

Sort your features by whether their source is independent of the model. Gate on those. Treat the self-authored one as context, never authorization. That was @txdesk's line, and it outlives the email case completely — it's the rule for any model-scored decision.

The part I got wrong in post four: I called confidence a "tiebreaker." @jugeni corrected it, and the correction matters. Confidence doesn't demote to a weak signal — it inverts. Self-graded confidence has the same computational shape on adversarial input as on cooperative input, and that sameness is the definition of a confident hallucination. A polished impersonation that reads as a trusted sender is exactly a high-confidence, high-sender-trust, reversible-looking email. So on cooperative input confidence is scenery; on adversarial input it's counter-evidence. The same number flips meaning depending on what the rest of the gate sees. It can't be a tiebreaker, because it's wrong precisely when you'd most want to trust it.

The wiring

The gate decides on the world-anchored features only. senderTrust grounded on observed sender history, reversibility sourced from an action-type lookup — both belong to the runtime, not the model. The classifier proposes; the runtime arbitrates with facts the model has no access to author.

Confidence gets a different job: the canary. After the gate decides, compare confidence to the gate's conclusion. If they agree, silence. If confidence is high and the gate rejected — that's the post-mortem you want, and it goes to a triage queue, not a log line nobody reads. @jugeni's framing: confidence reads the gate, not the other way around. That keeps the self-authored number out of the vote and turns disagreement into something you can audit.

One implementation detail makes the whole thing provable: pull the runtime corroborator into a named external-context object in the decision trace. The model reads it; it can't write it. That's what lets you prove after the fact that the decision was anchored to something outside the model — which is also where the eval gets its teeth.

The eval that turns a belief into a number

Post four's honest close was that "the floor saves us" is a belief until it's a measurement. @jugeni and @hannune specced the measurement, and it's sharper than what I'd have built.

Don't measure a threshold ("did the impersonation reach AUTO"). Measure the delta: whether the (confidence − world-anchored-corroboration) spread separates adversarial from cooperative samples in distribution. The cooperative set is held-out known-safe senders — that's your floor distribution. The adversarial set is hand-crafted to be high-confidence, thin-corroboration on purpose, and — this is the discipline I'd have skipped — matched to the cooperative set on confidence. If the adversarial set has lower confidence than the cooperative one, the eval is leaking signal somewhere else and the spread isn't measuring what it looks like.

The canonical fixture: a sender impersonation that lands AUTO at 0.92 against an action the runtime reversibility table marks internal-only. That's the exact corner where the floor does all the work and the score does none.

It's not just email

@hannune pointed out the principle generalizes straight into retrieval. A model's confidence in a retrieved answer is high precisely because the chunk sounded plausible, not because it's grounded — the same self-referential trap. Citation overlap across retrieved chunks, entity-level consistency with a knowledge graph: corroborators the model can't author. Confident-plus-external-signals-thin-or-contradictory is the canary in that domain too. Any time a model scores features for a decision, the same sort applies.

Honest status

None of this is shipped yet. Today confidence still gates AUTO at 0.85, and what makes that safe is the deterministic floor underneath — AUTO's autonomous execution is off, and the three irreversible actions fail closed regardless of any score. This is design hardening for when AUTO acts, not a live hole. I filed the two pieces as issues so the thread has somewhere to land: the world-anchored gate + canary and the delta eval.

Four posts and a comment section later, the thesis is smaller and sharper than where it started: keep the model in the perception layer, gate on what it can't author, and treat its opinion of itself as a canary, never a vote. Thanks to everyone who out-designed me in the replies. The repo's in the open if you want to keep going — and if the series was useful to you, a ⭐ helps me gauge whether these are worth continuing: github.com/k08200/klorn.

Confidence is the one signal your model can't corroborate

yongrean — Mon, 29 Jun 2026 12:16:19 +0000

This series started as a cheap-model brag and keeps getting better comments than posts. Three readers — @nazar_boyko, @txdesk, and @jugeni — independently converged on the same seam, and @jugeni put it in one line I can't improve on:

AUTO wants a corroborator the model cannot write, not a confidence it can.

Here's what that means, and why it's the sharpest critique this design has taken.

Four signals, but not four of a kind

Quick recap of the earlier posts: the LLM scores four features per email — confidence, senderTrust, reversibility, urgency — and a deterministic rule maps those to a tier. The model perceives; a rule I can read decides.

But those four aren't the same kind of thing. Three of them describe the world:

senderTrust can be anchored to observed history — have you actually corresponded with this person, and how often. There's a source outside the email.
reversibility is a property of the action the system would take, not the message. Accepting a calendar invite is reversible because accepting is reversible — not because the email said so.
urgency answers to the clock. A real deadline either exists or it doesn't.

confidence is different in kind. It's the model grading its own work — "how sure am I about the other three?" There is no source outside the model's opinion of itself. And in my rule, the AUTO branch gates when confidence >= 0.85 (alongside the others).

Where that bites

The dangerous email isn't the one the model is unsure about — the low-confidence floor already routes that to the queue. It's the one the model is confidently wrong about. A polished impersonation that reads as a trusted sender is exactly a high-confidence, high-senderTrust, reversible-looking email. It walks toward AUTO through the one feature the model authors about itself, and self-graded confidence is the gate that structurally can't catch a confident lie.

What actually stops it today

I want to be precise about the blast radius, because it's smaller than that paragraph sounds.

AUTO is classify-only in the current build — an AUTO classification sets a tier and triggers no action. When execution does run, AUTO only ever maps to reversible, internal actions (archive, mark-read). And the three irreversible actions — send, hard-delete, forward-external — sit behind a deterministic floor that ignores every score. So a confident impersonation that reaches AUTO gets quietly handled in a recoverable way, never anything you can't undo.

The seam is real; it just can't currently reach anything unrecoverable. But "bounded by the floor" is not the same as "designed right." The day AUTO starts taking even reversible actions on its own, leaning on a number the model wrote about itself is the wrong gate.

The fix is the framing

@jugeni's line is the spec: gate on corroboration the model can't author.

Make senderTrust a deterministic floor from observed history when history exists — manualOverrides >= N pins it, instead of merely suggesting it to the model in the prompt.
Source reversibility from the action the tier would trigger, by lookup, not from the model's read of the email (that's @txdesk's point, and it's already how the irreversible floor works — it just isn't how the AUTO gate works yet).
Keep confidence as a tiebreaker, never as the thing that promotes to AUTO on its own.

The pattern generalizes past email. Any time you let a model score features for a decision, sort the features by whether their source is independent of the model's self-assessment. Gate on the ones that are. The self-graded one is scenery — useful context, never authorization.

The honest part

I haven't done this yet. Today confidence still gates AUTO, and what makes that safe is the floor underneath, not the gate itself. The thing I owe is an adversarial eval: a high-confidence, polished impersonation, measured to see whether it actually reaches AUTO — turning "I think the floor saves us" into a number instead of a belief. That's next, and the eval set is in the open if you want to write the case before I do.

Three posts in, the lesson keeps being the same shape: keep the model in the perception layer, and make every decision answer to something the model can't quietly author. AGPLv3, the whole thing: github.com/k08200/klorn.

Confidence is enough to decide. It's not enough to do.

yongrean — Thu, 25 Jun 2026 10:18:46 +0000

A classifier confidence of 0.99 is enough to decide a tier. It is not enough to send an email you can't unsend.

Those are two different bars, and most "autonomous" systems use the first one to clear the second. That's the bug.

This is the third post in a series that started as a cheap-model brag and turned into an architecture argument. Post one: a cheap model beat GPT-4o on email triage. Post two: the model only scores four features, and a deterministic rule picks the tier. A commenter, @hannune, pointed at one of those four features:

Your reversibility signal is something I have not seen named explicitly before but it is exactly the right axis for anything that touches irreversible state.

He's right, and it's the cleanest way into the last piece of the design. So: what reversibility actually routes.

The line: can the user undo it with one click?

Most of what a mail agent does is reversible. Archive, un-archive. Trash, restore. Apply a label, remove it. Mark read, mark unread. Re-tier. Snooze. Every one of those is a single click away from undone, so every one of those rides on exactly what post two described — classifier confidence plus a hash of the input bytes that drove the decision. If the model's confident and the inputs are pinned, ship it.

Three actions are not like the others:

export const FLOOR_ACTIONS = ["send_email", "delete_permanent", "forward_external"] as const;

Send (Gmail's undo-send window is 30 seconds, then it's gone). Permanent delete (skips Trash, no recovery path). Forward to an external party (same network effect as send — it's out). For these, reversibility scores near zero, and near-zero reversibility is the signal that says: confidence is necessary but no longer sufficient. You need something the probabilistic layer can't give you.

Why confidence isn't enough: sign the artifact, not the narration

The failure mode here has a name I borrowed from people doing this in crypto: agent-vs-ABI mismatch. The agent narrates a high-level intent — "I sent a polite follow-up to Alice" — and the thing that actually executed did something the narration glossed over: wrong recipient, an edited body, a different attachment. The agent isn't lying. Natural language is lossy by definition; the description and the bytes are allowed to drift.

The cure isn't to verify the narration harder. It's to stop signing on the narration and sign on the deterministic artifact — the actual bytes that will travel to Gmail.

export function sendEmailPayloadHash(input: { to: string; subject: string; body: string }): string {
  const canonical = {
    v: RECEIPT_SCHEMA_VERSION,
    action: "send_email" as const,
    to: input.to.normalize("NFC").trim().toLowerCase(),
    subject: input.subject.normalize("NFC"),
    body: input.body.normalize("NFC"),
  };
  return crypto.createHash("sha256").update(JSON.stringify(canonical)).digest("hex");
}

When you approve a send, the system mints an ActionReceipt that pins this hash — the bytes you actually approved, normalized so a cosmetic edit (Alice@Example.com vs alice@example.com) doesn't false-alarm, and NFC-normalized so composed/decomposed Unicode hashes identically (this matters the moment a body has Korean in it). At execute time it recomputes the hash from the about-to-send bytes and checks:

export function verifyReceipt(receipt: ActionReceipt, expected: { action: FloorAction; currentPayloadHash: string }): void {
  if (receipt.v !== RECEIPT_SCHEMA_VERSION) throw new ActionReceiptSchemaError(receipt);
  if (receipt.action !== expected.action) throw new ActionReceiptMismatchError(receipt, expected.currentPayloadHash);
  if (receipt.payloadHash !== expected.currentPayloadHash) throw new ActionReceiptMismatchError(receipt, expected.currentPayloadHash);
}

Any drift between approve and execute throws and the action is refused. Reusing a send_email receipt to authorize a delete_permanent throws on the action check. Bumping the schema version deliberately invalidates every pending receipt and forces a re-approve under the new shape. The autonomous path fails closed: no valid receipt, no irreversible action.

So reversibility is the router

That's the whole point of naming reversibility as a first-class feature instead of folding it into "risk." It's not decoration on the tier decision — it's the axis that decides which trust model an action even gets:

High reversibility → the probabilistic layer is enough. Confidence + input hash, done.
Near-zero reversibility → drop to the deterministic floor. Confidence got you to "this is worth doing"; the signed artifact is what gets you to "and the bytes are exactly the ones approved."

Two layers, and the feature score picks which one applies. The probabilistic layer is allowed to stay probabilistic precisely because the floor catches the cases where probability isn't enough.

The honest part

Fair question: is this actually wired, or just a module with a TODO? It's wired. The receipt is minted at /approve from the exact bytes you clicked on, executeToolCall refuses any floor action that arrives without a verified receipt (FloorReceiptRequiredError), and send_email re-checks the payload hash in its own path before anything leaves.

The honest edges, because there always are some: of the three floor actions, only send_email is a callable tool today — delete_permanent and forward_external aren't wired as tool cases yet, but the central guard already fails them closed, so a future case physically can't ship a receipt-less side effect. And the autonomous agent runs in SUGGEST mode by default — read-only tools plus propose-only, no mutating power until you opt into AUTO, and even then the floor stands in front of the irreversible three. The brake went in before the autonomous engine gets switched on, which is the only order that isn't reckless. I'd rather show you the guard and its TODOs than claim more than the code does.

The portable version

Separate "confident enough to decide" from "verified enough to do." For anything your system can't undo with one user click, don't trust the model's description of what it's about to do — hash the deterministic artifact at approval, verify it at execution, and fail closed on any drift. Confidence is a fine reason to decide. It is never, by itself, a reason to do something you can't take back.

The whole floor is ~210 readable lines in the open, AGPLv3: github.com/k08200/klorn — packages/api/src/attention-floor.ts. Three posts, one idea: keep the model in the perception layer, and put everything you actually stand behind in code you can read.

I don't trust the LLM to classify my email. So I don't let it.

yongrean — Thu, 25 Jun 2026 05:57:48 +0000

My classifier calls an LLM on every single email. The LLM is not allowed to classify the email.

That sounds like a contradiction. It's the most important design decision in the thing.

A reader named @nazar_boyko left a comment on my last post — the one where a cheap model beat GPT-4o on email triage — and put it better than I did:

Once the LLM is a feature scorer and not the decider, "consistency over genius" falls right out of it, and a cheap fast model is exactly what you want for reading the same four signals the same way every time.

The price upset was the fun headline. This is the actual thesis. So here it is on its own.

The model scores four numbers. That's all it does.

Every inbound email goes to the LLM with one job: read the message and return four scores between 0 and 1.

confidence — how sure you are the other three scores are right
senderTrust — 1.0 a known, important human; 0.3 an automated transactional notice you signed up for; 0.0 anonymous bulk marketing
reversibility — if this got auto-handled and that was wrong, how easy is the recovery? 1.0 trivial undo; 0.0 irreversible ("lost an investor")
urgency — needs attention within hours (1.0) down to informational, no clock (0.0)

The response schema is literally:

{"confidence":0.0,"senderTrust":0.0,"reversibility":0.0,"urgency":0.0,"reason":"short phrase"}

No tier. The model never sees the words PUSH, QUEUE, SILENT, AUTO in its output contract. It reads an email and describes it along four axes. It does not get a vote on what happens next.

A rule I can read decides the tier

What happens next lives in one file, tier-policy.ts, in a function with no model in it:

// 1. Very low confidence → QUEUE. Hiding uncertain mail is the worst failure.
if (f.confidence < 0.5) return "QUEUE";

// 2. Urgent AND sure → wake the user.
if (f.urgency >= 0.7 && f.confidence >= 0.7) return "PUSH";

// 3. Anonymous, no clock, trivially reversible → SILENT (narrow: marketing only).
if (f.senderTrust < 0.2 && f.urgency < 0.2 && f.reversibility > 0.9) return "SILENT";

// 4. Reversible, very sure, not urgent, trusted → AUTO.
if (f.reversibility >= 0.85 && f.confidence >= 0.85 && f.urgency < 0.5 && f.senderTrust >= 0.5) return "AUTO";

// 5. Default → QUEUE. "I'll look at it on my own schedule" is the dominant bucket.
return "QUEUE";

That's the whole decider. Every threshold is a named constant in one object above it, not a magic number sprinkled through a prompt. Order matters — earlier branches win. I can read this in thirty seconds, write a unit test for each branch, and change the policy without touching the model or re-running an eval.

Try doing any of that to "I asked GPT-4o to pick a tier and it picked QUEUE." You can't test it. You can't diff it. You can't explain to yourself why message #4,012 got hidden. The decision isn't anywhere — it's smeared across a weight matrix and a paragraph of prompt.

Why "consistency over genius" falls right out of it

Once the model's only job is to score four signals, the question stops being "which model reasons best about email policy?" and becomes "which model reads the same four signals the same way every time?"

Those are different questions with different answers. The first one points you at the biggest, most expensive model. The second one points you at a cheap, fast, low-variance one — because a frontier model's extra reasoning, applied to a 30-word email, mostly buys you more ways to have an opinion, which is variance, which is the enemy when you've already moved the judgment into a rule. That's why the cheap model won the last post. It wasn't a cost compromise. Splitting scorer from decider is what made the cheap model the correct choice, not just the affordable one.

And because the contract is "four features → tier" and nothing else, the model isn't load-bearing for correctness — it's load-bearing for perception. Proof: when the LLM is down or rate-limited, a keyword fallback produces the same four features with zero model calls, and the exact same rule runs on top. The plumbing doesn't change. The only thing a better model buys you is sharper feature scores on the genuinely ambiguous mail — which is why the one place I'll spend a frontier model is a dial that escalates only the low-confidence tail, and nowhere else.

What this buys you that "let the model decide" can't

Auditability. The policy is a file. Code review covers it. A regression test pins every branch.

Stable learning. When I correct a misclassification, the correction doesn't go fight the model for control of the answer. It becomes an example that nudges the feature scores toward the right values, and the rule — the spine — stays fixed. The thing that learns and the thing that decides are separated on purpose.

A blast radius you chose. AUTO's thresholds sit deliberately high (reversibility ≥ 0.85, confidence ≥ 0.85, trusted sender) so the system structurally cannot auto-handle a destructive or low-trust action. That floor is a number I can point at, not a behavior I'm hoping the model keeps exhibiting.

The honest part

This doesn't make the model's judgment good — it makes the decision layer honest. Garbage feature scores still produce garbage tiers; the rule only guarantees that identical scores always map to the identical tier, and that I can see why. The thresholds were hand-tuned against 50 emails, and calibrating them from accumulated real corrections is still ahead of me, not behind. The keyword fallback, by design, can't emit PUSH — so a total LLM outage degrades urgent mail to "visible in the queue," never "silently hidden," but it does degrade. I'd rather write that down than pretend the split is free.

The takeaway is portable

This isn't really about email. Any time you're handing an LLM a decision with consequences, you can ask the same question: does the model need to decide, or does it need to read? Separate "what the model perceives" from "what the system does about it." Put the second half in code you can read, test, and stand behind. You get auditability, you get to use a cheaper model, and you stop being surprised by your own product.

The judge, the rule, and the thresholds are all in the open — AGPLv3: github.com/k08200/klorn. The decider is packages/api/src/tier-policy.ts, about sixty readable lines. Go see how few of them there are.

I let GPT-4o and a cheaper model fight over my inbox. GPT-4o lost.

yongrean — Wed, 24 Jun 2026 16:59:28 +0000

Here's the scoreboard. Same 50 emails, same prompt, same 4-tier task:

Model	Accuracy	Note
`google/gemini-2.5-flash`	88%	100% recall on urgent mail — never missed one
`google/gemini-2.5-pro`	82%	the "smarter" sibling
`openai/gpt-4o`	82%	the reflex pick
anything cheaper than flash	< 80%	failed my floor, didn't ship

The cheap model didn't tie the expensive ones. It beat them by six points and never missed an email that should have woken me up. The two models I'd have reached for on instinct — the obviously-smarter ones, the ones that cost several times more per token — both came second.

I almost didn't run this comparison at all. That's the part worth your time.

The task

I'm building an email firewall. Every inbound message gets exactly one of four tiers:

SILENT — recorded, never shown (marketing, receipts, FYI)
QUEUE — visible when I choose to look, no notification
PUSH — actually interrupt me
AUTO — reversible, hands-off (classified only, for now)

That's the entire output surface. No suggestion cards, no "AI thinks you should reply" badges. One label per email.

The thing doing the labeling is what I call the judge. It's the part I'd assumed needed a good model — reading an email and deciding whether it's allowed to ring your phone feels like a judgment call, and judgment calls are what you buy a frontier model for.

So I had gpt-4o wired in and I was ready to leave it there. Then I did the boring thing and measured it.

What "measured" means here

The eval set is committed to the repo: packages/api/eval/judge-eval-set.json. Fifty emails, synthetic and PII-free, hand-labeled to encode one specific person's policy — QUEUE is the default, SILENT is narrow (clear marketing only), PUSH is urgent and confident, AUTO is reversible and not urgent. The tier mix is 21 QUEUE / 13 PUSH / 12 SILENT / 4 AUTO.

One command runs a model against it:

pnpm eval:judge   # tsx scripts/poc-accuracy.ts --in=eval/judge-eval-set.json

I ran it across the models I was actually choosing between. Flash won. Not "won on cost, tied on quality" — won on quality, and it happens to be the cheap one. I pinned production to it and wrote the result into the commit message so future-me can't quietly pretend the expensive model was a sacrifice I made for the budget:

flash is not a compromise — it scores 88% / 100% PUSH recall, beating gemini-2.5-pro and gpt-4o (both 82%).

Why cheap wins here

A frontier model sells you reasoning depth. Long chains, hard problems, hold-ten-things-in-your-head problems. Email triage is none of that. It's a short, repetitive, read-four-signals-and-be-consistent problem. You're not paying for capability that moves this needle — you're paying for capability you never touch, and a bigger model's extra "thinking" mostly buys you more chances to overthink a 30-word email.

There's an architecture reason too, and it's the load-bearing one. The LLM never picks the tier. It scores four features per email — confidence, sender trust, reversibility, urgency — and a ~20-line deterministic rule maps those four numbers to PUSH/QUEUE/SILENT/AUTO. The model is a feature-scorer, not a decider. So I don't need a model that reasons brilliantly about email policy. I need one that reads four signals the same way every time. Consistency, not genius. That's exactly the job a cheap fast model is good at — and exactly the job where a bigger model's cleverness becomes variance you don't want.

It also means the policy is auditable without the model in the loop. I can read the rule. I can test it. If the model's down, a keyword fallback produces the same four features so urgent mail still gets through. None of that works if you let the LLM free-hand the answer.

Before you @ me

This is 50 emails. It's small on purpose — it's one person's mental model written down, not a benchmark, and I'm not going to dress it up as one. The set is synthetic, so it tests whether the model applies my policy consistently, not whether it can read the real world. A different inbox with a different owner would draw the lines somewhere else and might rank the models differently.

I'm also only claiming what I measured. Flash hit 100% recall on PUSH — it never sent an urgent email to a quiet tier. I'm not going to invent per-tier numbers for the models that lost; I have their headline accuracy and that's what I'm putting my name on.

What I'm not walking back: on the one task I actually care about, on the set that's sitting in the public repo for you to open, the expensive models lost. That result was stable enough to bet production on.

The lesson is annoyingly cheap

Most of us never run this comparison. "Use the best model" is the default, the best model is the expensive one, and the leaderboard agrees, so why would you waste an afternoon proving the obvious?

Because the leaderboard has never seen your task. MMLU doesn't know what you mean by "urgent." The only eval that ranks models on your problem is the one you write — and when you write it, the ranking stops matching the price tag surprisingly often. The frontier model isn't smarter at your job. It's just smarter at the jobs in the press release.

Write the small eval. Run the cheap model against it before you reach for the expensive one. Worst case you confirm the obvious. Best case you cut your bill and your accuracy goes up, which is a sentence I didn't expect to type either.

The judge, the eval set, and the deterministic rule are all in the open — AGPLv3, OpenAI-compatible, point it at Ollama or vLLM and keep your mail on your own box: github.com/k08200/klorn. The eval set is packages/api/eval/judge-eval-set.json. Open it, label it your way, and go find out which model actually wins on your inbox.

Treat upstream catalogs as mutable: how a free-tier model SKU retirement broke my AI agent

yongrean — Thu, 11 Jun 2026 15:24:22 +0000

Tuesday afternoon, every autonomous cycle in my agent started returning the same error:

[AGENT] Cycle failed: 404 No endpoints found for model: google/gemma-2-9b-it:free

The model hadn't changed in my config. The provider hadn't gone down. The endpoint just... wasn't there anymore. OpenRouter had retired the :free SKU mid-week — no notification, no deprecation window, just gone. Every background classification, every briefing generation, every proactive scan started failing in the same way.

I had a fallback. That was the embarrassing part.

The fallback that didn't fall back

My createCompletion() wrapper had been catching the documented provider failure modes for months:

402 insufficient_credits → walk to next provider
403 daily_quota_exceeded → walk to next provider
429 rate_limited → backoff + retry

What it didn't catch: "the model you asked for doesn't exist anymore." A 404 No endpoints found propagated as a generic error and killed the cycle. The fallback chain never even got consulted because nothing in the existing branches matched.

The mental model was wrong. I'd been treating the model catalog as fixed configuration — something you set once and forget. In reality it's upstream state that can mutate at any moment, just like any other dependency. The retirement was a feature of the provider's catalog management, not a bug.

The fix: walk the free-model chain on retirement signals

The actual patch was short. Two PRs:


ts
// Before: only walked on credit/quota/rate failures
if (isCreditError(err) || isKeyLimitError(err)) {
  return walkFallbackChain(...);
}

// After: also walk when the model itself is gone
if (isModelUnavailableError(err)) {
  markModelUnavailable(model);
  return walkFallbackChain(...);
}
isModelUnavailableError matches on:

HTTP 404 with No endpoints found in body
HTTP 400 with model_not_found code
Anything else the provider emits when the SKU is gone
markModelUnavailable puts the model on a 24h cooldown so the next cycle doesn't try it again immediately. When the catalog refreshes (providers add new SKUs all the time too), the cooldown expires and we retry.

The fallback chain itself is per-provider:


const OPENROUTER_FALLBACK_CHAIN = [
  'meta-llama/llama-3.3-70b-instruct:free',
  'google/gemma-2-9b-it:free',
  'mistralai/mistral-7b-instruct:free',
  'qwen/qwen-2.5-7b-instruct:free',
];
When one entry 404s, we walk to the next. When all of them fail, we fail over to the secondary provider (Gemini direct), which has its own chain. Only when every chain across every provider has been exhausted does the agent give up and surface AllProvidersExhaustedError to the user.

What I should have done from day 1
Three rules I'm internalizing:

1. The upstream catalog is mutable. Hardcoding a single model ID is the same antipattern as hardcoding a single CDN URL. Always have a list. Always make the list cheap to rotate.

2. Distinguish "this model is unavailable" from "the provider is unavailable." They're different failures with different recovery paths. Treating them the same way means you either over-rotate (give up the provider when only one model is gone) or under-rotate (give up entirely when the provider is fine).

3. Cooldowns, not blacklists. When a model disappears, don't kill it forever. Put it on a window. Providers add models back, or you might be hitting a transient 404. A 24h cooldown is much friendlier than a permanent deny-list that requires a code change to undo.

Why this matters beyond one provider
If you're running an agent in production, your model isn't your only upstream dependency:

Vendor's catalog can change
Pricing can change (:free → :paid is a real failure mode)
Rate-limit policies can change
Authentication schemes can change (Google's AQ.-prefix keys rejected by their own OpenAI-compat endpoint is a fun one — I had to write a native adapter for it)
The pattern is the same: treat every assumption about the upstream as a potential dynamic value, and make the recovery path the default, not the exception.

Agents that survive in prod have failover chains, cooldown windows, and degraded modes built in from the start. Not because the upstream is unreliable — because the upstream is alive, and alive things change.

I've been writing about Klorn, an open-source attention firewall for Gmail, where this kind of failure mode hits constantly because the agent runs continuously. Repo: github.com/k08200/klorn · Doctrine: deterministic-floor.md.

If you've shipped agents to prod, what other upstream-mutation failure modes have caught you off-guard?

MCP CI gates need retry receipts for flaky downstreams

yongrean — Mon, 08 Jun 2026 04:43:52 +0000

MCP CI gates need to distinguish two very different failures:

the server is actually broken
the downstream dependency is temporarily flaky

If both become hard failures, CI gets noisy.
If both are ignored, the gate stops meaning anything.

So I shipped @k08200/mcp-probe@1.12.0 with explicit sidecar retry policy for tool-call dry-runs.

The problem

A readiness gate that calls real MCP tools can hit transient downstream failures:

503 Service Unavailable
502 Bad Gateway
504 Gateway Timeout
rate limits
short network timeouts

But auth and permission failures are different. A 401 or 403 usually means the agent will fail in production too.

Those should stay visible unless the contract explicitly says otherwise.

Retry is opt-in per tool

mcp-probe now lets a sidecar contract define retry behavior per tool:

{
  "tools": {
    "logs_query": {
      "input": {
        "query": "service:web status:error",
        "timeframe": "1h"
      },
      "retry": {
        "attempts": 3,
        "delayMs": 1000,
        "retryOn": [429, 500, 502, 503, 504, "timeout", "rate limit"]
      },
      "expect": {
        "status": "pass"
      }
    }
  }
}

The important part: retry is not global magic.

It only happens when the sidecar explicitly opts in.

Receipts still show the flake

If a call fails once and passes on retry, the final result can pass, but the receipt still records every attempt.

That means CI can tolerate a transient downstream blip without pretending the run was clean.

Example shape:

{
  "tool": "flaky_read",
  "status": "pass",
  "source": "sidecar",
  "attempts": [
    {
      "attempt": 1,
      "status": "fail",
      "error": "503 Service Unavailable: transient downstream"
    },
    {
      "attempt": 2,
      "status": "pass"
    }
  ]
}

That is the distinction I want MCP CI gates to preserve:

hard failures should block
transient failures can be retried
pass-after-retry should still leave a receipt

Install

npm install -D @k08200/mcp-probe

Or run directly:

npx @k08200/mcp-probe@latest --config mcp-probe.config.json --github-summary --receipt-file mcp-probe.receipt.json

GitHub release: https://github.com/k08200/mcp-probe/releases/tag/v1.12.0

npm: https://www.npmjs.com/package/@k08200/mcp-probe

Every "autonomous AI agent" is a customer-support ticket waiting to happen

yongrean — Sun, 07 Jun 2026 16:23:09 +0000

I'm tired of writing apology emails for my own AI.

Last month an agent I was dogfooding cancelled a calendar event I actually cared about. Two weeks before that, a different one auto-replied to an investor with what read like a hostage note from a Slack bot. Both companies have raised more money than I'll see in five years.

The pattern across every "agentic AI" demo on my timeline is the same:

Agent does a thing
Agent emails the user that it did the thing
The thing was wrong
The company ships a fix the following Tuesday

I stopped trusting them. Then I built one that can't do this.

The wedge: agents that wait

Klorn is an approval layer between AI agents and your Gmail / Calendar. The agent does the thinking — reads the email, checks your calendar, drafts the reply, creates the event proposal. Then it stops. Nothing fires until you click approve.

Sounds boring. The constraint is what makes it real.

The constraint that kills "act first, apologize later"

Every meaningful action in Klorn is signed with a payload hash before it fires. send_email literally cannot execute without an ActionReceipt that matches the hash of what was shown to you.

There's an invariant test in the repo that fails the build if anyone — me, a future contributor, an AI agent (the irony) — tries to bypass it. Remove the approval check, the test fails, the build fails, the deploy fails.

You cannot ship a Klorn version that sends emails silently. It's architecturally impossible.

This is the part nobody is building. Every "autonomous agent" demo on my timeline is one feature flag away from the next apology email.

What I shipped this week

The agent loop now runs end-to-end:

Meeting request hits inbox → tier-classified (PUSH / QUEUE / SILENT / AUTO)
Klorn reads the email, checks the calendar for conflicts
Drafts the reply and the calendar event proposal
Both wait as PendingActions in your decision queue
One click → fires

Plus a production bug that would have killed a less paranoid agent: OpenRouter retired a :free model SKU mid-week. Every autonomous cycle died with 404 No endpoints found. The existing failover only covered 402 / 403 / 429 — not "the model is gone." Shipped a multi-model fallback chain on the same provider so losing one upstream SKU never kills the agent.

That fix is the kind of thing you only ship when you trust the boundary the agent runs inside.

Stop hype-cycling, start gating

If you're shipping an "autonomous AI agent" in 2026, three questions:

Can a user prove what was approved is what was sent?
Can a future contributor bypass your approval check?
What is your invariant test?

If the answers are "no", "yes", and "we don't have one" — you're building the next apology email. Stop.

I'd rather build the firewall.

60-second walkthrough above (YouTube · Shorts cut).
Try it free: klorn.ai. PRO auto-applied during private beta.

If you've actually been thinking about where agents should and shouldn't act on their own, I'd love your honest take — even one-line replies. Disagreement especially welcome.

tools/list is not a readiness check for MCP servers

yongrean — Mon, 01 Jun 2026 06:48:53 +0000

The first version of mcp-probe checked the obvious things:

can the MCP server initialize?
does tools/list work?
are tool schemas present?

That was useful, but not enough.

The more I tested real MCP workflows, the clearer the problem became:

tools/list is self-report. CI needs a receipt.

An MCP server can advertise a clean tool catalog and still fail every real call because OAuth handoff, scopes, downstream credentials, row limits, tenant boundaries, or response shapes are broken.

So the latest release of mcp-probe focuses less on "does the process start?" and more on "is CI enforcing the contract an agent actually depends on?"

The new bootstrap flow

npx @k08200/mcp-probe@latest init \
  --target @your-org/your-mcp-server \
  --discover \
  --lock-tools \
  --github-actions

This creates:

mcp-probe.config.json
.mcp-probe.json
.github/workflows/mcp-probe.yml

The important part is what happens during --discover.

mcp-probe connects to the server, reads the live tools/list catalog, and generates a starting contract from the observed tool schemas.

Schema-aware sidecar samples

Older generated samples were too naive. If a schema said:

{
  "type": "object",
  "required": ["location", "count"],
  "properties": {
    "location": { "type": "string", "enum": ["Chicago", "New York"] },
    "count": { "type": "integer", "minimum": 1 }
  }
}

the old fallback might produce empty strings or zero values. That often hit input validation and never tested the real call path.

v1.11.0 now uses schema hints:

default
enum
numeric minimum
string minLength
nested objects
array minItems

So the generated sample becomes:

{
  "location": "Chicago",
  "count": 1
}

It is still only a starting point. You should review generated samples before running them with production credentials, especially for mutating, admin, export, or environment-inspection tools.

Catalog locking

The other new piece is --lock-tools.

With --discover, mcp-probe now writes the observed tool names into expectedTools, so CI fails if a required tool disappears.

With --lock-tools, it also writes allowedTools, so CI fails if unexpected tools appear.

That matters for low-trust agent surfaces. If a server suddenly exposes delete_user, export_all, or rotate_api_key, I do not want that to silently become available to an agent just because tools/list still returns valid JSON.

Example config:

{
  "timeoutMs": 10000,
  "servers": [
    {
      "name": "my-mcp-server",
      "target": "@your-org/your-mcp-server",
      "probeTools": true,
      "toolsFile": ".mcp-probe.json",
      "expectedTools": ["search", "read_record"],
      "allowedTools": ["search", "read_record"]
    }
  ]
}

Receipts

For CI, the workflow can also persist a redacted receipt artifact:

npx @k08200/mcp-probe@latest \
  --config mcp-probe.config.json \
  --github-summary \
  --fail-on-warn \
  --receipt-file mcp-probe.receipt.json

That receipt is the thing I want CI to trust: not the server claiming it has tools, and not an agent claiming what happened later, but an independent probe that actually ran against the boundary.

Try it

npx @k08200/mcp-probe@latest @modelcontextprotocol/server-memory

GitHub: k08200/mcp-probe

Release: v1.11.0

I am especially looking for real Datadog, Supabase, and Gmail MCP recipes. The public fixtures are useful, but the real value is catching auth handoff, permission, tenant-scope, and response-contract failures in CI.