In June 1994, Lou Montulli was working at Netscape on an e-commerce application for MCI. The problem was prosaic: MCI didn't want its servers storing partial transaction states. A shopping cart needed to persist somewhere. Montulli's solution was to adapt an existing concept, the magic cookie, for web communications. A small piece of data, stored in the user's browser, sent back to the server on subsequent requests. State without server memory. The first version shipped in Mosaic Netscape 0.9beta that October.
Montulli's refusal is the more telling detail. One of the popular proposals circulating at the time was to assign a unique identifier to every web browser, letting any website individually identify each user. Montulli opposed this. Cookies were designed to be site-scoped. A store could remember your cart. It couldn't follow you to the next store. The advertising industry spent the next two decades routing around that constraint, but the original design intention was clear: state management for a human user's session, scoped to individual sites.
A year later, Netscape Navigator 2.0 introduced JavaScript, and with it the need for a security boundary. The same-origin policy arrived in 1995, restricting how scripts from one origin could interact with resources from another. Its founding assumption was stated plainly: the policy existed to deny cross-origin read access,
"with the assumption that the majority of users choose to use compliant browsers."
Worth pausing on that phrase. The security model enforces rules on behalf of a human who navigates intentionally, who chooses a browser, who arrives at a site through some act of volition. The architecture assumes presence.
Somewhere in the years that followed, session state crossed a line that nobody marked. Cookies were designed to remember what you'd put in your cart. As web applications grew more complex, though, the presence of a valid session token began to function as something else entirely: proof that you were you. If the browser held the right cookie, the application treated the request as authenticated. State management became identity by convention, long before anyone formalized the equivalence.
A technical detail that rarely surfaces in web security discussions belongs here: cookies and the same-origin policy operate on different taxonomies. A cookie jar keys cookies by name, domain, and path. A web origin is defined by scheme, host, and port. Cookies predated the SOP and were never folded into it. The web's session layer and its security boundary layer don't share a coordinate system. For two decades this mismatch was manageable because the entity navigating both layers was a person who understood, at least roughly, where they were and what they were doing.
When an agent operates inside a browser session, it inherits all of this. The cookies, the local storage, the session tokens that now pass for identity. It occupies a context shaped by a human's login, scoped by a human's navigation history, protected by a security model that assumes a human is making choices. The agent doesn't "choose to use a compliant browser" in any meaningful sense. It inherits the session mechanically.
Security researchers are beginning to map the consequences. An attacker who obtains session credentials through phishing or browser extension injection is now indistinguishable from an agent operating legitimately in that same session. Same tokens, same API endpoints, same audit trail. The session had always been a convenience, a stand-in for identity rather than a boundary around it, and it worked because the thing inside it was a person. People are, if nothing else, recognizably themselves. The web built its assumptions around that recognition. Nothing in the architecture asks whether that's still true.