Browser Session

The browser session is the runtime form of the portal decision. It does not open unless assignment, token, one-time grant, policy, and target data match.

CerberusLite controls whether the browser session opens, who can attach to an existing session, and which capabilities remain available while work is active.

What CerberusLite checks

• Is the session pass valid?
• Is the connect grant one-time and tied to the right session?
• Is the origin and runtime security context valid?
• Is a duplicate controller trying to attach?
• If the user is a viewer, is there an approved viewer grant?
• What does runtime policy allow for input, clipboard, upload/download, read-only, and recording?

Controller and viewer

The controller operates the working surface. A viewer can attach only when approved and sees the existing session without taking control. Viewer input and clipboard paths are blocked at the session layer, so observation and control stay separate.

Runtime policy

At launch, a policy snapshot is carried into the browser session. It controls:

• graphical or terminal session type,
• read-only state,
• server input permission,
• clipboard copy and paste permission,
• upload and download permission,
• recording requirement,
• graphical-session capabilities such as secure attention.

Policy changes how the session behaves at runtime.

What is visible?

The user sees the working surface in the browser. Input works only when permitted; viewer and read-only states apply input and clipboard rules.

When the session closes, state changes and the related event connects back to evidence.

Session lifecycle

The session first enters an issued or starting state. If CerberusLite passes validation, the working surface connects. If the browser disconnects, the system separates normal close, detach, and target-unavailable behavior where possible.

A second controller cannot attach to the same active session. Viewer attachment uses a separate approved scope and limited role, so observing and controlling are not treated as the same capability.

Input and clipboard rules

Mouse, keyboard, and clipboard paths depend on session policy. If policy denies a path, the browser action does not reach the target. This matters most for viewer and read-only cases.

Applying policy in the session layer is stronger than hiding a button in the interface. Even if a visual control is wrong, the session layer keeps denied paths closed.

Closure behavior

Closure has several causes: the user may end work, the target may become unavailable, access may be revoked, or a kill switch may run. Each case creates a different evidence reason.