Prompt-bombing wins when every extra MFA check trains the team to auto-approve the one that matters.
MFA fatigue—also called push-bombing or prompt-bombing—is a credential-access attack that pairs a stolen password with a flood of authentication push requests, betting the exhausted user approves one just to make it stop. Most teams respond to it by adding more prompts—which is exactly what produces the fatigue, and the bypass behavior, in the first place. The fix isn't asking harder. It's asking at the right moment.
The attack works because the defense over-asks
CISA's Scattered Spider advisory lists repeated MFA prompts among the group's credential-access techniques—one tool in a kit that also includes plain social engineering, as the same group's help-desk password-reset attack on Marks & Spencer showed.
The usual response to this pattern is to add more MFA checkpoints—gate the VPN, gate the login, gate every sudo, gate every new terminal window. Each one is defensible in isolation. Together, they train the exact behavior the attack depends on: constant re-prompting produces notification blindness that trains reflex approval—tapping "approve" stops being a conscious security decision and becomes muscle memory. Verizon's 2025 DBIR found prompt bombing behind more than 20% of Social-engineering actions in that year's Public Sector breaches—a narrower population than the industry as a whole, and the report itself attributes some of the jump to better reporting on the technique, not necessarily more of it. Either way, the mechanism is the one every security team already recognizes: the moment MFA stops feeling meaningful, it stops working as a control. It's still logged as "MFA enabled" in the compliance report; it's no longer actually deciding anything.
That's the real failure mode: not that MFA is weak, but that it's asked at the wrong unit. Every extra prompt that isn't actually gating anything risky is training the team to auto-approve the one that is.
Ask "is a human here?" at the moment it matters
A completed MFA challenge answers one question, at whatever unit a given system scopes it to today: is a human here, recently? Checkpoints pile up when a control keeps re-asking that same question at every session boundary instead of scoping it to the moment it actually matters.
Alpacon checks this on an Auth0-backed deployment—where identity runs through Auth0, not a directory or local accounts. The baseline is checked at the first privileged action, not blanket-gated at terminal entry: a read-only, low-sensitivity session can stay on a login-fresh MFA check with nothing further asked. What escalates beyond that baseline is narrower and more concrete: opening a terminal, a file transfer, or a command session as an OS account that isn't your own pulls the check forward to the moment that session opens—and, on the Enterprise plan, a workspace can set that same entry-time check as a compliance floor for every interactive session, not just the escalated ones. What none of that does is ask again just because you opened a second terminal window: contexts opened from the requesting client inherit the proof for the length of the recency window, measured from the moment of authentication, rather than re-demanding it when another context opens. What a given session is actually allowed to do is a separate question, handled by the session's own scope limits, not by re-asking MFA.
An agent can't inherit a human's presence, and shouldn't need to
The scoping question gets sharper once an AI agent is the one running commands, because "is a human here" stops being answerable the same way. In Alpacon's presence model, user-level presence is a fact about a human, and an agent-mode session cannot produce it or inherit the human's: it is never issued a presence challenge at all, clearing that gate only on the strength of the human approval its session already carries. That's not a gap in the presence model—it's the same scoping discipline applied one level down. An agent was never the unit presence was measuring in the first place, so an agent's privileged work is gated by its own up-front session approval instead, plus human review on the specific commands the risk lane routes to a person. The question "is this actor allowed to be here" and the question "is this specific action allowed" stay separate gates, whether the actor is a contractor's laptop or an agent acting on its behalf.
Scoping the check doesn't mean scoping the risk away
None of this argues for asking less. It argues for treating a real answer as real for the person who gave it, not discarding it the instant they open a new window. A security team auditing its own MFA policy should ask: is this control keyed to who's here, or to what they just clicked open? Only one of those is worth re-checking.
If your current MFA policy re-checks presence every time someone opens a new session or a new terminal—rather than treating a recent, unchanged fact as still true—that's worth auditing before the next push-bombing wave finds the fatigue point your policy built. The scoping question—what unit is this control actually checking?—is the same question that shows up everywhere else in execution control: least privilege, session scope, command judgment. MFA fatigue is just the version of it that shows up first, because it's the control the user feels every day.
