You hadn't. Not this. Not now. Not against that system.
This is the failure mode nobody talks about until it's expensive: the gate existed. It opened at the wrong time and never closed.
The Two Gates That Rot
Every agent platform hits a moment where some operations feel heavier than others. Reading a record is fine. Writing a record is probably fine. But deleting a production database, deploying to a live org, modifying the authorization model itself. Those need something more than a valid session.
The two most common answers are session tokens and confirmation prompts. Both are reasonable first moves. Both rot in different directions.
Session tokens encode "this user is who they say they are." They don't encode "this user is actively thinking about this specific operation at this specific moment." That's a good fit for login flows, identity federation, multi-step operations where re-authing every call would destroy usability. It's the wrong fit when you need to know if the person who approved something this morning is paying attention right now.
That gap is the problem. A session token from this morning says nothing about whether you're operating against the right target, in the right context. It encodes identity, not intent.
Confirmation prompts try to solve the intent problem. "Are you sure?" before you proceed. This works exactly once per user, maybe twice. After that, it's a reflex bypass. Anyone who's done infrastructure work knows what the "are you sure?" moment feels like after the hundredth time. Your hand is already moving to accept before your brain has processed the question. The cognitive load has collapsed to zero because your pattern-matching has learned that confirmations always come before routine operations, and routine operations are fine.
This isn't user error. This is what happens to any friction that becomes predictable. Friction you can anticipate is no longer friction. It's a ceremony. And ceremonies are what you do to continue, not what makes you pause.
The Drift Problem
There's a name for this in security: consent fatigue. The thing that happens when users have clicked through enough permission dialogs that they stop reading them. The dialogs didn't go away. The cognitive engagement did.
Confirmation prompts in agent interfaces rot the same way. Once you've been through the flow enough times to know what comes next, the prompt no longer creates a meaningful pause. It creates muscle memory. The whole point of the gate was to interrupt momentum, to force a deliberate beat where a human verifies intent. When the interruption becomes rote, the gate is open. Not broken. Still there, technically. But the thing it was meant to enforce has evaporated. From a safety standpoint, that's exactly the same as the gate not existing.
The other failure mode is timing. Even if the confirmation prompt still works in the moment it appears, it encodes approval for a specific operation at a specific time, with whatever context was live in your head when you confirmed. Thirty minutes later, the agent is operating under that approval in a different context. Different target, different conversational branch. The original approval doesn't map to what's being executed.
The approval was real. The coverage was bounded. The gate treated it as unlimited.
What Sudo Actually Got Right
The Unix sudo model solved a harder version of this problem decades ago.
Sudo's authentication timeout doesn't question whether you're trustworthy. It questions whether this moment is covered by that approval. The system assumes your attention drifts. It assumes you might have walked away, that someone else might be at the keyboard, that the threat model from ten minutes ago might not match right now. The timeout forces re-engagement.
The NOPASSWD semantic does the opposite: for operations safe enough to run without per-invocation verification, remove the gate entirely. This matters. Gates on low-stakes operations are exactly how high-stakes gates lose their meaning. They get lumped together as "the thing you click through." If everything requires a gate, the gate means nothing.
Operational security adds another layer with the two-person rule. Banking dual control, nuclear launch authorization, NORAD procedures for irreversible operations. The principle isn't distrust. It's scope. Some decisions are too consequential to be made by a single authorization signal. The structure of approval needs to match the blast radius.
Capability-based security adds a different dimension: rather than asking "is this user authorized in principle?", it asks "does this invocation carry the right to do this thing?" The capability is presented at the moment of use. Authorization isn't ambient, it's attached to the specific request.
Same principle, different angles: authorization should map to intent, and intent is bounded in time and scope.
The Per-Utterance Turn
The pattern that actually solves this is per-utterance authorization. For operations above a certain blast-radius threshold, the authorization phrase has to appear in the same message as the risky request. Not a previous message. Not the session preamble. This message. This utterance.
It does several things at once.
First, it makes authorization physically co-located with intent. You cannot pre-authorize from earlier in the conversation. Typing the authorization phrase and making the request are the same action. This isn't a "did you log in" check. It's a "are you present and purposeful right now" check.
Second, the blast radius is exactly one operation. No window, no timeout to manage, no session state to reason about. After this message, the authorization is gone. The next risky operation needs its own explicit signal. This is capability-thinking applied to conversation: the capability is attached to the utterance, not the session.
Third, and most importantly: it doesn't rot. You cannot habituate to a gate that requires active, specific effort in the same moment as the request. Confirmation prompts fail because they become rote ceremony. A phrase that only matters when you include it in this specific message cannot become rote. Every instance requires deliberate action.
When This Is Right, and When It Isn't
This pattern is not right for everything.
The temptation, once you have a working safety primitive, is to apply it everywhere. That's exactly how you recreate confirmation fatigue on a different mechanism.
Per-utterance authorization fits a specific profile: operations that are rare, with asymmetric blast radius, where the downside of running without intent is severe. Deploying to production. Modifying authorization models. Irreversible deletions. Actions with downstream consequences that are hard or impossible to unwind. The qualifier isn't "sensitive." The qualifier is: if this runs without the user actively meaning it right now, what does recovery look like?
For high-frequency, lower-stakes operations, this gate is wrong. Gate every read operation behind an authorization phrase and you'll have collapsed all cognitive differentiation between "routine" and "irreversible" within a week. The gate's meaning comes entirely from how rarely it appears. Apply it too broadly and you've rebuilt the confirmation fatigue you were escaping.
This is a tiering problem: which operations warrant per-utterance gates, and which are better handled by session context, rate limiting, or no gate at all? Getting that line right is where most of the actual work lives.
What It Feels Like to Use
For gated operations, the interface states the requirement explicitly. Not buried in documentation. Stated clearly, in context, at the moment of relevance.
You can't click through it. You have to compose a message containing both your intent and your authorization. That forces a moment of articulation: you're stating what you want to do, and simultaneously stating that you mean to do it. These two things are usually identical. Occasionally they're not. That gap is exactly where errors live.
Think about how a surgeon calls out the steps of a procedure before beginning. It feels like ceremony, but the ceremony is doing work. It forces an externalized statement of intent that can be checked against the actual situation. The pause isn't the point. The articulation is.
The audit story is better too. A risky operation can be traced to a specific message containing explicit authorization. Not "the user was logged in." The user included this phrase, in this utterance, at this timestamp. Durable. Specific. Human-generated.
The Principle Underneath
Match your authorization model to the blast radius of your operations.
Session tokens are right when you need to know who someone is. Confirmation prompts are right when you need a speed bump, not a genuine barrier. Per-utterance authorization is right when the consequences of running without deliberate intent are severe enough that you'd rather have the operation fail than run without certainty.
Every safety gate costs something. Friction, usability, cognitive overhead. The only way that cost is worth paying is if it's applied where it actually buys something. A gate with no blast-radius differentiation trains users to ignore all gates.
Gates should be sparse, specific, and impossible to habituate to. The ceiling of what a single gate can protect is bounded by how rarely it appears.
The next question is how you assemble multiple gates into something coherent. How they interact. What a principled authorization architecture looks like across a whole system. That's a harder design problem, and it requires thinking at a different level.