A prompt lands on your phone: Approve sign-in? You didn’t sign in to anything. Five years ago, that was the moment the training kicked in: don’t approve it, report it, someone has your password. In two years’ time, the same prompt will get a different response: “it’s probably just my agent”, tap, approved, back to lunch.
That tap is the whole problem, and I don’t think the industry has noticed it yet.
We spent a decade teaching hesitation
Security awareness training has one crown jewel. Not the phishing simulations, not the annual e-learning: the single heuristic that actually stuck. Never approve a prompt you didn’t start.
It stuck because it is simple, it requires no technical knowledge, and it maps onto real attacks. Push-bombing (bombarding a user with MFA prompts until they approve one out of exhaustion) is how Uber’s 2022 breach began, and it has been a staple of real intrusions ever since. The defence was never technology. It was a user who thinks “I didn’t ask for this” and refuses.
Vendors reinforced it. Number matching in Authenticator exists precisely to force a moment of conscious connection between the sign-in and the approval. The entire model assumes one thing: legitimate prompts are prompts you initiated, seconds ago, on purpose.
Agents break the assumption, not the technology
Now put an agent in the loop. As covered in You Can’t MFA an AI Agent, agents act in your security context, with your permissions. But increasingly they also initiate: they hit a resource that demands step-up authentication, they need a fresh consent grant for a new scope, they schedule work for 3am and the prompt fires when they get there.
Every one of those prompts is legitimate. Every one of them is also, by definition, a prompt you did not start. The heuristic doesn’t degrade gracefully; it inverts. Once “prompts I didn’t start” become routine, the user’s only remaining strategies are to deny everything (and break their own workflows) or approve everything (and break the security model). People will approve everything. The workflow depends on it, and the workflow always wins.
We trained people to hesitate, then shipped a product that only works if they don’t.
“Copilot needs your approval” is the perfect pretext
Attackers do not need to break the authenticator. They need their prompt to be indistinguishable from the noise we taught users to expect, and agents manufacture that noise legitimately, all day long.
Look at what the prompt actually tells you today: an application name, a location, maybe a number to match. It does not tell you which agent triggered it, whether it is one of yours, or what it is about to touch. There is no primitive in the current stack for “verify this request came from my agent, doing the task I gave it”. So a phishing pretext of “your assistant needs you to re-approve access” arrives with the same shape, the same timing plausibility, and the same authority as the real thing.
This is the same cultural failure I wrote about in the joiners, movers and leavers problem: the system quietly trains people into the insecure behaviour, then blames them for it afterwards. Nobody chose to build an approval reflex, the same way nobody chose access sprawl. It emerges from a hundred reasonable decisions, and it is fully deniable right up until the incident report.
What actually holds the line
Some of the answer is already shipping, some of it barely exists, and knowing which is which is the useful part.
Start with the good news: phishing-resistant methods survive this. A passkey cannot be push-bombed: there is no remote “approve” button, because the ceremony requires the authenticator to be locally present. Microsoft retiring SMS and voice codes in favour of passkeys closes the remote-approval hole for sign-in. That part of the story is genuinely good news.
The risk doesn’t vanish, though. It migrates to consent. What passkeys do not fix is the OAuth consent screen and the step-up grant, which is exactly where agent workflows live. Consent screens are coarse, scope-blind in practice (nobody reads them), and about to become the most-clicked dialogs in corporate life. Treat consent governance (admin consent workflows, app allow-listing, scope review) as the new front line.
The long-term fix is agents with their own identity, so prompts can say so. That is the approach from the agent identity toolbox: agents as first-class principals with their own identity and scoped permissions. A prompt that says “Agent: invoice-processor, owned by you, requesting scope X” is verifiable. A prompt that says “Microsoft 365” is a coin flip.
And update the training before the reflex forms. If your awareness programme still says “never approve a prompt you didn’t start”, it is about to start lying to your users. The replacement rule is harder but honest: know which prompts your agents generate, and treat everything outside that pattern as hostile. That requires actually telling users what their agents do, which most organisations currently could not answer for themselves.
The uncomfortable summary
We finally got the human side of authentication nearly right, and we are now introducing a class of actor that generates false positives for every instinct we just finished installing. The awareness budget of the last ten years bought us a workforce that hesitates. The agent rollout of the next two will pay people, in saved time, to stop.
Whoever solves “is this really my agent?” at the prompt level is solving the next decade’s phishing problem. Until then, the honest advice is unglamorous: fewer agents with broader access, more agents with narrower access, consent governance turned all the way up, and users who know exactly what their software does in their name. If that sounds like the same advice as the castle walls post, it is. The wall keeps moving. The discipline doesn’t.
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
