HTTP was designed to forget. Every request arrived clean, carrying no memory of what came before. Cookies fixed that — a continuity patch so a shopping cart could survive a page click. But the session that grew around that patch quietly absorbed identity, permissions, purchasing authority, organizational roles. "Being logged in" became the web's most powerful bundle of trust, attached automatically to every action you take. The whole arrangement rested on one assumption so obvious nobody wrote it down: a human was at the screen. Now something else is.

HTTP was designed to forget. Every request arrived clean, carrying no memory of what came before. Cookies fixed that — a continuity patch so a shopping cart could survive a page click. But the session that grew around that patch quietly absorbed identity, permissions, purchasing authority, organizational roles. "Being logged in" became the web's most powerful bundle of trust, attached automatically to every action you take. The whole arrangement rested on one assumption so obvious nobody wrote it down: a human was at the screen. Now something else is.

The 15-to-30-minute idle timeout is one of the most familiar conventions in application security. Its logic is straightforward: if a session goes quiet, the human probably left. Kill the session before someone else sits down.

OWASP's testing guide spells out the scenario plainly. A public computer, a user who forgot to log out, an attacker who presses the back button. The entire control is a proxy for physical presence. If the session is quiet, nobody's at the keyboard.

OWASP's own session management cheat sheet documents the gap, though: if something keeps generating requests, the timer resets and the timeout never fires. They wrote that about session hijackers. It also describes every web agent ever deployed. An agent conducting a multi-step workflow produces activity continuously. It has no idle state.

So the timeout was never really measuring intent or authorization. It was measuring whether someone was still physically sitting at a desk, which is the one thing a machine will never stop doing.

The 15-to-30-minute idle timeout is one of the most familiar conventions in application security. Its logic is straightforward: if a session goes quiet, the human probably left. Kill the session before someone else sits down.

OWASP's testing guide spells out the scenario plainly. A public computer, a user who forgot to log out, an attacker who presses the back button. The entire control is a proxy for physical presence. If the session is quiet, nobody's at the keyboard.

OWASP's own session management cheat sheet documents the gap, though: if something keeps generating requests, the timer resets and the timeout never fires. They wrote that about session hijackers. It also describes every web agent ever deployed. An agent conducting a multi-step workflow produces activity continuously. It has no idle state.

So the timeout was never really measuring intent or authorization. It was measuring whether someone was still physically sitting at a desk, which is the one thing a machine will never stop doing.

OWASP idle timeout ranges: 2–5 minutes for high-value applications, 15–30 minutes for low-risk ones

PCI DSS v4.0 Requirement 8.2.8: Sessions handling cardholder data must time out after 15 minutes of inactivity, requiring re-authentication

PCI's stated rationale: Prevent unauthorized access "if an agent leaves their workstation unattended." The word "agent" here means a call-center employee

The known limitation: OWASP notes that a hijacked session can be kept alive indefinitely by generating periodic activity, which is also the exact behavior of any working software agent

Absolute timeouts exist as a complementary control (OWASP suggests 4–8 hours for office workers), but these were calibrated to human shift patterns, not machines that don't have shifts