Blog · Essay
Why human presence assurance is now a required control
For twenty years, “logged in” meant “a person is here”. That assumption has quietly stopped being true. Here's what has to replace it.
18 October 2026 · 5 min read
The old assumption
For twenty years, the web ran on a simple idea: if someone is logged in, a person is there. Passwords, then two-factor codes, then identity checks with documents and selfies all made the same bet. Prove who you are once, at the door, and everything you do afterwards is treated as yours.
It was a reasonable bet. Doing anything on a website took a person: someone had to read the page, find the button and press it. Automation existed, but it was clumsy and easy to spot.
What changed
Three things changed at once.
First, automation that behaves like people became cheap. In Thales's dataset, 53% of internet traffic in 2025 was automated, and AI-enabled bot attacks grew 12.5 times in a year (Thales, 2026 Bad Bot Report). Not all of that traffic is harmful, but the tools behind it are the same.
Second, AI agents started acting for people. Daily requests from AI agents on Cloudflare's network grew more than 1,700% in a year (Cloudflare, “The Internet has a second audience”, September 2026). Many of those agents do useful work for real users. Sometimes they do more than their users intended: in a 2026 vendor survey of more than 380 security professionals, 49.8% reported or suspected that an AI agent had taken an unintended or unauthorised action (Salt Security, State of Agentic AI & API Security, 2H 2026).
Third, real accounts are operated by someone else. A session that started with the right person can be driven minutes later by a script, a remote operator or a hijacked browser. Every identity check was correct. It simply stopped being relevant.
Identity is not presence
Identity answers “who is this?”. It's checked once, and the answer stays true for days. Presence answers a different question: “is a person at the controls right now?”. That answer can change from one minute to the next.
A guard checks your badge at the door. That tells them who came in. It doesn't tell them who is sitting at the desk when a transfer is approved upstairs an hour later.
For most of the web's history, those were the same person. Now they often aren't.
Why one-time checks fail
A puzzle at sign-up, a face scan at onboarding, a code at login: each one is a moment. Pass it and you're trusted for the rest of the session.
Sign in
password, MFA
check who you areSession
time passes
control can changeAction
withdraw, pay,
approveDecision
your server
asks HEIP
The risky part isn't the moment you're checked. It's what happens after: the withdrawal, the payout change, the purchase an agent makes on your behalf. That's exactly where one-time checks have nothing to say.
Puzzles have a second problem. They cost every real person a little time, and software keeps getting better at solving them. A control that annoys your customers and still lets automation through is losing on both sides.
What a presence control needs to be
If presence is the missing check, what should it look like? Six properties matter.
- Continuous. It has to follow the whole visit, not one snapshot, because a moment is easy to fake and a whole visit isn't.
- Invisible to real people. If people have to do something, it's a puzzle by another name.
- Tied to the action. The answer must be about this withdrawal, in this session, right now, and impossible to reuse for anything else.
- Private. It should establish that a person is there without learning who they are: no identity, no biometrics, nothing they type.
- Explainable. Every decision needs reasons a team can review.
- Safe to roll out. Teams need to watch it on real traffic before it affects anyone.
Standards are moving the same way. NIST SP 800-63B-4 recognises monitoring a session after sign-in as a way to reduce risk, and asks that it be done with privacy in mind (NIST SP 800-63B-4, Session Management, July 2025).
Where it fits
A presence control doesn't replace anything you already run. Identity checks still tell you who opened the account. Sign-in still proves ownership. Bot management still filters obvious automation at the edge. Fraud scoring still looks at the transaction.
Each answers a different question. Presence adds the one none of them ask: at the moment of this action, is a person in control? Its answer can stand on its own, or become one more input to the decision you already make.
What this means for teams
Start where automation costs you the most. For an exchange, that's withdrawals. For a payments company, payouts and beneficiary changes. For an AI product, the moment a person approves what an agent is about to do. For a marketplace or SaaS product, sign-ups and offer claims.
Watch before you enforce. Run the check on real traffic without blocking anyone, and compare what it would have decided with what you already know.
Decide what “step up” means for your users. When the answer is uncertain, the right response is rarely a block. It's a passkey, a one-time code or a second approval: a step a person completes in seconds and a script can't.
Presence has to be shown
Human presence used to be implicit. Being logged in was enough to assume it. That's no longer safe, and the actions that matter most are the ones where the assumption fails quietly.
Presence now has to be shown, at the moment it matters. That is the control HEIP adds. If you'd like the idea explained with everyday examples, read Why human presence?