The Most Attentive User She's Ever Seen

Nkechi Okonkwo is not a real person, though her problems very much are. She is a composite, assembled from conversations, conference hallway grumbles, and the particular weariness of people who've spent careers calibrating security controls around human behavior and now find themselves staring at something that behaves nothing like a human but carries perfectly valid credentials. Her colleagues call her "Timeout." She earned the nickname. She does not love it.

We spoke over video. Behind her: a whiteboard covered in session flow diagrams, a framed printout of what appeared to be NIST SP 800-63B Section 5.2, and a mug that read "REAUTHENTICATE." She was eating crisps throughout.

You've spent over a decade tuning session policies at a major retail bank. What does that actually mean day to day?

Nkechi: It means I'm the person who decides when your banking session dies. Inactivity timeouts, re-authentication triggers, device fingerprint thresholds, behavioral scoring. All the invisible machinery that determines whether the system still believes you're you after you logged in.

NIST 800-63B lays out the framework: for AAL2, which is where retail banking lives, you get up to an hour of inactivity and twenty-four hours total.¹ But those are ceilings. We tune tighter for sensitive operations. Wire transfer? You're getting re-challenged. New payee? Re-challenged. The whole architecture assumes a human sitting at a screen, doing human things at human speed, with human interruptions.

What kind of human interruptions?

Nkechi: The NIST FAQ says it plainly: the reauthentication timeouts are "intended to mitigate situations where a user's device is left logged in but unattended, such as if the user walks away from a terminal."² Someone goes to make tea, forgets they're logged in, and an opportunistic attacker sits down. The inactivity timer catches that. Activity resets the clock. It's elegant if your threat model is humans with bladders.

And now?

Nkechi: Now I have things operating sessions that do not have bladders.

When did you first notice agents showing up in your systems?

Nkechi: We noticed them as anomalies before we understood what they were. Our behavioral biometric layer builds a profile for each customer: typing cadence, mouse movement, scroll patterns, how long they spend reading a page before acting.³ When someone's behavior deviates from their baseline, we score that deviation. High enough score, we trigger friction. Step-up authentication, session termination, whatever's appropriate.

And we started seeing these sessions that were... perfect. Same IP every time. Same browser fingerprint. Same navigation path. Same typing rhythm. No typos. No hesitation. No scrolling back up to re-read something. Just relentless efficiency.

That sounds like it should be reassuring.

Nkechi: You'd think. But our systems were trained on the opposite assumption. The behavioral biometric model catches inconsistency: someone logs in with valid credentials but types differently, navigates hesitantly, searches for things the real customer would know where to find.⁴ That's your account takeover signal. A human attacker who stole a password but doesn't know the layout.

So when we see excessive consistency, the system doesn't know what to make of it. Paste events instead of keystrokes. No continuous mouse movement between clicks. Key hold times that are mechanically uniform. Research shows these patterns are highly discriminating. Behavioral features alone can distinguish agents from humans with near-perfect accuracy in lab conditions.⁵

But detecting them was never the hard part.

What is?

Nkechi: Policy. (She sets down the crisps for the first time.)

I can tell you something non-human is operating a session. Fine. But is it the customer's agent, doing what the customer asked? Is it malware? Is it a third-party service the customer authorized last Tuesday and forgot about? My detection system doesn't know. It just sees behavior that doesn't match the human baseline.

And the session infrastructure I've spent fourteen years building was designed to answer one question: is the person who logged in still here?¹ It was never designed to answer who authorized this action or what were the boundaries of that authorization or does this specific transaction fall within what the customer intended when they set this thing up three hours ago.

NIST actually anticipated part of this, didn't they? The authentication intent concept?

Nkechi: They did, and it's the right instinct pointed at the wrong threat. Authentication intent in 800-63B is about making sure the claimant responds explicitly to each authentication request. It's a countermeasure against malware acting as a proxy, something using your authenticator without your knowledge.¹ That phrase matters: without your knowledge.

A legitimate agent is acting with your knowledge. You set it up. You told it what to do. You just aren't there for every individual click. The standard anticipated unauthorized automation. It hadn't considered what happens when the automation is invited.

What about the timeout structure specifically?

The twenty-four-hour absolute timeout still applies, but that's a blunt instrument. A lot can happen in twenty-four hours if nobody blinks.

So what do you actually want?

Nkechi: (long pause)

I want to know what was authorized. Not just who logged in. I've always been able to verify that. I want to know: this agent is about to initiate a payment. Did the customer authorize payments? Up to what amount? To which recipients? For how long? And I want that mandate to be something I can inspect at the session layer, not something I have to infer from behavioral signals that were designed for a completely different purpose.

The RPA world figured some of this out years ago. Unattended bots got their own identities, their own credential vaults, their own audit trails.⁶ They didn't just borrow a human's session and hope for the best. But web agents today are operating through browser sessions that were issued to humans, carrying human ambient authority, and my entire policy stack treats that session as proof of human presence.

NIST 800-63B actually says the RP shouldn't treat an access token as proof of presence.¹

Nkechi: Section 5.1. Right there in the text: "The RP SHALL NOT interpret the presence of an access token as an indicator of the subscriber's presence in the absence of other signals." The standard already knows tokens don't prove presence. But the practical infrastructure, the timeouts, the behavioral scoring, the re-auth triggers, all of it still operationally assumes that session activity equals human presence. The standard is ahead of the implementation. Which is a polite way of saying we haven't caught up.

If you could redesign the session layer for this world, where would you start?

It never really did, honestly. But when the only thing operating a session was a human making conscious choices, the pretense held. It held because humans are slow and deliberate and occasionally distracted, and all of those qualities gave the system natural checkpoints. Remove those qualities and the pretense collapses.

Last question. Do you still like being called Timeout?

Nkechi: (smiles) Less and less. The things I'm worried about now don't time out.

Footnotes

1. NIST SP 800-63B-4, "Digital Identity Guidelines: Authentication and Authenticator Management," July 2025. https://pages.nist.gov/800-63-4/sp800-63b.html ↩ ↩² ↩³ ↩⁴ ↩⁵

2. NIST SP 800-63 FAQ, "Q-B09: Why are the timeout requirements so short for AAL2 and AAL3?" https://pages.nist.gov/800-63-FAQ/ ↩

3. OLOID, "Behavioral Biometrics Explained: A Detailed Guide." https://www.oloid.com/blog/behavioral-biometrics ↩

4. Getfocal.ai, "Behavioral Biometrics: How It Stops Digital Fraud in Banking." https://www.getfocal.ai/blog/behavioral-biometrics ↩

5. FP-Agent (arXiv 2605.01247, May 2026), as discussed in Fayolle et al. (arXiv 2606.30119, June 2026). Behavioral-only features achieved F1 0.9994 in closed-world agent-vs-human classification. ↩

6. UiPath documentation on unattended robot identity and credential management; audit log retention policies (6-month searchable, 24-month archive). ↩