Add a new payee to your bank account and try to send them money right away, and in a lot of banking systems you'll hit something most security features never do: a wall that isn't there to stop you, just to slow you down. The payee gets added fine. The transfer doesn't go through, not yet. An hour, sometimes longer, then it clears. If you actually meant to add that payee, you get your money there a little later than you wanted. If someone else added that payee, using your compromised login, they just lost their best shot at moving your money before anyone noticed.That hour is the whole feature. Not the login check on either end of it. The empty hour in the middle.Two different problems, two different toolsBanks didn't build this because login security wasn't good enough. They built it because the failure mode they were worried about, an account taken over through stolen credentials, phishing, a SIM swap, doesn't look any different from a legitimate new payee at the moment it happens. The login was valid. The session was real. Nothing about the request itself was wrong. What actually stopped the fraud, in the cases where it got stopped, was time. Enough of a delay for a fraud team's backend checks to run. Enough for a customer to notice a text alert about a payee they don't remember adding. Enough for the transfer to still be sitting in a queue when somebody finally looks at it.Most access control only asks one question: is this authorized. Yes, go ahead. No, denied. A cooling-off period sneaks in a third answer, and only for a narrow slice of actions: authorized, but not yet. Logging in doesn't get this treatment. Checking your balance doesn't either. It shows up for the handful of things that are expensive and hard to undo if they go wrong, and sending money to someone you've never sent money to before is about as clean an example as you'll find.What agent security already does, and what it still doesn'tAgent tooling isn't standing still on this, and it's worth being upfront about that rather than pretending otherwise. Human-in-the-loop gating is a standard recommendation now, and it's already shipping, not just written up in blog posts. OpenAI's Agents SDK has a native flow where a tool call can pause mid-execution, wait for a human to approve or reject it, and pick back up from that exact point. Circuit breakers for agents borrow straight from distributed systems: enough failures, or crossing some risk threshold, and the breaker trips, calls get rejected until a cooldown passes.All of that catches things that look wrong. A confidence score drops. A failure count climbs past some line. An action doesn't resemble what that agent usually does. A cooling-off period on a new payee isn't answering that question at all. It doesn't care whether this specific transfer looks suspicious. It delays the whole category, every time, no matter how confident or ordinary the request seems, because someone who already has your valid login doesn't look anomalous to the system. They look like you. As far as the login flow can tell, they are you.Where that gap actually shows upPicture an agent with legitimate write access to a customer database, doing what it's supposed to do all day: small, ordinary updates, one record at a time. Now picture that same agent issuing a bulk delete across ten thousand records, because a bad prompt or a compromised upstream input told it to, using the exact same credentials it always uses. A decent anomaly-based circuit breaker has a real shot at catching that one. Ten thousand deletes is nowhere near that agent's normal pattern, and that's a genuine strength of the tooling that already exists.Now the harder version. Same agent, told through a convincing, contextually plausible instruction to delete exactly one record, the kind it deletes fifty times a day anyway. Nothing about that single action is statistically unusual. Same shape, same volume, same confidence as the other forty-nine legitimate deletes that day. An anomaly detector has nothing to grab onto, because there isn't an anomaly. There's just one wrong instruction dressed up as a normal one, and normal is exactly what a threshold-based system is built to let through.That's the case a category-based delay is built for, and it's the case current agent tooling mostly misses. Not every delete needs a pause. But a short, deliberately chosen list of actions, the ones where getting it wrong is expensive and permanent, could carry a mandatory hold regardless of how confident or routine the request looks. The same way a bank doesn't wait for a new-payee transfer to look suspicious before slowing it down.What actually has to be true for this to workNone of it matters if the delay is passive. The banking version works because something is doing something during that hour, fraud systems keep scanning, alerts go out, a customer can call in and freeze the transfer before it clears. A queued agent action sitting untouched in a review list is worthless if nobody's watching that list. The delay needs a real second channel behind it, not just a slower version of the same approve button.And it has to stay rare. The second a mandatory pause starts hitting ordinary, expected actions, people find ways around it, the queue backs up, and whoever's supposed to be reviewing starts clicking approve without reading, which is worse than never having the control at all. Banks keep this narrow: new payees, unusually large transfers, not every transaction all the time. Any agent version of this needs the same restraint, a handful of named, high-stakes actions, not a blanket rule that turns into wallpaper within a week.A smaller claim than it might sound likeThe broad idea here- add friction to risky agent actions, isn't new, and there's real funding behind the companies already doing solid versions of it. What's still open is a lot narrower than a whole product category. It's one specific design choice: gate a small set of actions based on what they are, not on whether they happen to look suspicious right now. That's something any team already building agent guardrails could bolt onto what they have, not a reason to throw it out and start over. A feature worth pushing for. Not a gap nobody's noticed.