A session shaped nothing like an ordinary request
A sandboxed execution environment isolates arbitrary running code from the broader system, containing what it can reach regardless of what the code itself attempts. This differs from plugin sandboxing, which restricts one specific extension to its own declared, narrow permissions — a general-purpose sandbox has to contain code whose actual behavior isn't known or declared in advance, since running arbitrary, unreviewed code is the entire point of the environment.
An interactive notebook or REPL session is a common, concrete example: a long-lived context where a person runs code interactively against real data and real systems, often for an extended period, with access considerably broader than any single API request would ordinarily be granted — because nobody scoped the session down to one specific operation the way an ordinary request gets scoped by design.
Scoping what the session can reach, not just who started it
Authorizing who may start a notebook session is necessary but not sufficient — the more consequential question is what that session, once running, can actually reach for its entire duration. A session authorized once at the start and then left with broad, unreviewed access for hours afterward is a standing-access problem wearing an interactive-tooling disguise, and it deserves the same scrutiny any other long-lived, broadly-scoped credential would.