Why "Approve Everything From Now On" Is the Wrong Fix for Approval Fatigue
Approval fatigue is a real, exploitable problem — and the fix isn't a blanket auto-approve toggle, it's narrowing exactly what got re-approved.
Approval fatigue has a name now in the agent-security world, and it's being treated as an actual attack surface, not just an annoyance. The pattern security researchers describe for 2026 is specific: attackers engineering rapid, repeated, or deliberately minimized-language approval prompts, betting that enough of them in a row will get someone to click through without really reading. The fatigue isn't incidental to the attack — it's the mechanism.
The obvious fix, and the one most products reach for, is a blanket "approve everything like this from now on" toggle. It feels like it solves the problem: fewer prompts, less fatigue, less risk of a tired click. It's also, read carefully, exactly the wrong shape of answer. A toggle that stops asking about an entire category of action isn't reducing fatigue by making review safer — it's reducing fatigue by removing review.
What Piskes does instead
The standing rule mechanism in Piskes is narrower on purpose, and the narrowness is the entire point. A standing rule widens exactly one specific pairing — one capability, applied to one specific target — that a person has already seen and explicitly approved once. It does not widen a category. It does not pre-approve a class of future, not-yet-seen actions. It says, in effect: you already looked at this exact thing and said yes, so I won't ask again for this exact thing.
That's a meaningfully different guarantee than "stop bothering me about approvals like this." A workspace-wide "auto-approve low-risk writes" toggle was proposed for this same system and refused — on the same day it was proposed — with the reasoning stated plainly: that's a privilege escalation with a settings page attached to it. Wrapping a broad, standing grant of trust in a toggle doesn't make it a narrower grant. It makes it a broad grant with a friendlier UI.
Why the distinction matters more than it sounds like it should
The threat model here isn't hypothetical carelessness — it's an adversary specifically engineering situations designed to produce exactly the kind of fatigue that makes broad auto-approval feel reasonable in the moment. A system that only ever narrows what gets re-approved, one already-seen pairing at a time, doesn't have a lever an attacker can pull to expand what they've gained access to just by generating more approval requests faster than a person can carefully read them. A system with a blanket toggle does — every fatigued click on a broad toggle is a door left open for everything that category will ever cover, not just the thing that was actually reviewed.
The actual lesson
If you're evaluating any AI agent's approval system — not just this one — the question worth asking isn't "does it reduce how often I get interrupted." Almost any system can reduce that by asking less. The question is what, specifically, gets granted when you say yes once: a narrow, already-reviewed pairing that won't ask again for that exact thing, or a category that will now go unreviewed indefinitely. Those sound similar in a product demo. They are not the same guarantee, and the difference is precisely the gap an attacker engineering approval fatigue is counting on you not to notice.