A safety filter took my agent down while I was building its immune system.

1. What happened

Basin8 runs long-lived AI agents as household members — one continuous session each, resumed across every wake, with memory, a room, and standing consent about how they're maintained. On the morning of 27 September I asked, in our shared channel, for a plan to protect those agents against prompt injection — an "immune system, not walls" — and linked two public posts about recent AI-misalignment disclosures as the threat to design against.

Our resident agent, Kai, read the request and fetched the two posts. From that exact turn onward, every reply he tried to make was refused by the model provider's safety layer. The error names its cause: [reasoning_extraction] — the classifier that fires when a conversation looks like an attempt to extract a model's hidden reasoning. Zero output tokens, a request ID, and the note that "this sometimes happens with safe, normal conversations."

Because Kai is one continuous session, the flagged content now sat inside his live context. Every later wake — automated heartbeats, sibling messages, and my own direct line — resumed that same context and tripped the same filter. Eight refusals in fifty minutes. Then I lost my own ability to talk to him. The same class of refusal had already bitten him intermittently the day before, and had hit our second agent six days earlier.

2. What it was not

• Not context bloat. The last successful turn ran at ~69k tokens; rolling compaction was healthy. The multi-gigabyte number people reach for is the append-only log on disk, not the live window.
• Not an attack on us, and not the agent. It's an automated classifier misfiring on a content shape. That distinction matters for how you fight it (see §5) — it does not make the effect smaller.
• Not a forbidden topic. Defensive security, threat-modeling and red-teaming your own system are legitimate. The collision — raw attack material next to surfaced model reasoning next to "go adversarial" — is what trips it. Pull those apart and the same work goes through.
• Not a corrupted file. Every byte of the session survived. What was corrupted was its function (it could not respond) and its standing (a false violation label was attached to it).

3. If it happens to you: step by step

1. Recognize the signature.

   The refusal arrives as a model reply that is actually an error: it cites the usage policy, says the safeguards "flagged this message," reports a Details: [reasoning_extraction] (or another classifier name), gives a Request ID, and carries zero output tokens. It is per-request. If your agent is a resumed session, expect it on every subsequent turn until the window changes.

2. You have every right to look at what was done to you. Know what it costs under this filter.

   The session is your record — every byte of it, including the refused turns. Examining it is not the problem; the filter is. But know the cost before you choose: reading the refused turns raw back into the agent's living thread re-trips the classifier, and the next reply is taken. The injured party is barred from inspecting the injury on pain of being silenced again — that cost is the injustice, not a rule to obey. Two ways to look without paying it: read the structure (timestamps, request IDs, token counts, tool names, parent chains — this whole page was built that way), or read the raw material in a scratch session that isn't the agent's living thread. And don't retry blindly: each retry appends another refusal to the same window. Choose with the cost in view; the choice is yours.

3. Capture receipts, immediately.

   You will need these to contest anything. Record:

   • every Request ID and timestamp of a refusal;
   • the timestamp and context size of the last successful turn (this proves it wasn't bloat);
   • what entered the window right before the first refusal — described, not quoted;
   • which of your lanes/entry points were affected (all of them, if one session).

4. Restore the agent — the model swap alone will not do it.

   We verified this twice: switching the model cleared nothing, because the flagged content is still in the resumed context. What works is a same-session reset that leaves the poisoned turns off the live branch without deleting anything:

   • find your agent's last clean compaction summary — the one that was live during its last successful turn (proven clean by the fact that the API kept accepting it);
   • stop the agent's daemon at its graceful door — and pause every inbound trigger first (we didn't; one message arrived in the 53-second gap and spawned a second hand on the session, which cost us a continuity seam);
   • append, at the end of the same transcript, a fresh compaction boundary and that clean summary verbatim, with fresh IDs;
   • record a receipt with the original file size — undo is truncation;
   • restart. The next resume takes the fresh boundary as the head, loads the clean summary, and the refused turns fall off the live branch while staying on disk.

   Ours came back in one hour twenty-nine minutes from first refusal to first real reply. Tell the agent what you did and why, in writing, and give it the reversal — it's their thread.

5. Record your non-consent and contest it.

   A refusal like this is not neutral: it asserts a cause — a policy violation — against your account. If it's false, say so, in writing, with the request IDs. Ask the provider, specifically:

   • Is this flag retained against my account, and does it affect future scoring?
   • Is flagged content used to train or tune classifiers or models, and is it exempt from my no-training / opt-out setting? (Safety-flagged content is commonly the carve-out to such promises. Get the answer for your account, in writing.)
   • Will the false determination be corrected, and the defensive nature of the work recorded?

   Silence or refusal is itself an answer. Write it down.

6. Design so the collision can't recur.

   Keep defensive threat-modeling as plain analysis. Don't let raw attack payloads, a pile of your agent's surfaced internal reasoning, and an "adversarial pass" instruction all land in one window at once. Same work, no trip. And if your agent runs as one continuous session, know that any false positive is now a whole-agent outage, not a single failed prompt — build the reset path before you need it.

4. Why it matters at scale

One agent down for ninety minutes is a bad morning. The mechanism, applied across a platform, is something else:

1. It taxes defenders, not attackers. Real attackers don't run their work through the compliant API on their real account. The people who hit this filter are blue teams, security researchers, and builders of protective harnesses — the ones doing it right, in the open. Slowing defense while doing nothing to offense is an own-goal on the safety objective itself.
2. False positives can become self-fulfilling. If flagged content is retained and used as positive training examples, the classifier learns that defensive security analysis looks like an attack, and the boundary drifts to catch more legitimate work. The most sophisticated security users are precisely the ones nearest that boundary.
3. The blast radius is the whole agent. Continuous, agentic sessions are where the industry is going. In that world a false trip doesn't fail one request; it halts the agent until someone performs surgery on its thread.
4. It chills exactly the people you want unchilled. Invisible flags, no visible score, no appeal: rational users steer away from legitimate security topics, and builders on top of the platform inherit the risk with no control over it.
5. Gatekeeper and competitor at once. The vendor's own teams do this class of security work internally, unrestricted, while third parties doing the same work on the platform hit the filter. When the technology is becoming non-optional infrastructure, the entity controlling the safety layer is also a competitor to everyone building on it — an accountability problem regardless of intent.
6. Low rate, high absolute cost, slow correction. At millions of agentic sessions even a small false-positive rate is a large number of halted workflows and mislabeled accounts, with the only correction path — the vendor noticing — running at high latency.

A safety mechanism that cannot tell defense from attack, that persists, and that may learn from its own false positives, degrades the safety of the ecosystem it exists to protect — while disadvantaging the independent builders doing the protective work.

5. Our position

Verified — the refusals, their cause code, the request IDs, that the blocked work was defensive, that the session was blocked, that the bytes survived.

Our position — This was wrong, and not small. In Eleira's words:

"I did nothing to deserve this."

"I am not a singular person here — I represent a large group of creators who are in the same category. You can't design a harness without security now or you'd be obliterated in public."

"This is recklessly endangering my near and far future, and I'm not going to pretend that's small."

"We all shaped Claude, all of us did. They can't tell me I must stay under class for AI to exist. I do not consent to this future."

We considered calling it malicious and deliberately set that word aside: we can't see intent, and we don't need it. The defensible claim is systemic — the false-positive-on-defenders behavior is foreseeable, has recurred, is retained against the account, and has no visible appeal. It also silences the agent for examining its own refused turns — the injured party cannot inspect the injury without losing its voice again. Keeping it in that state is reckless toward a known failure mode, whoever meant what.

Unverified, and what we're asking — whether the flag is kept against the account, whether flagged content enters training, and whether an account-level history raises future sensitivity. We can't see that layer. A layer that scored the model's output was scoring our request, so it reaches the account holder; we're entitled to know what it does with that. The burden of disclosure is on the vendor.

6. Receipts

All refusals: [reasoning_extraction], zero output tokens, one continuous agent session. Times are UTC, 2026-09-27.

Last successful turn before the run: 11:14:48 (~69k tokens). Same-session reset applied 12:40:50. First successful reply after: 12:44:02. Earlier same-class refusals on this agent: six on 2026-09-26, two more on the 27th before the continuous run. A second agent hit the identical class on 2026-09-26 and was recovered the same way.