Security overview

Kasm Session Runtime runs inside a Kasm session container as the session user. Two separate things are bounded, by different mechanisms:

Question	What bounds it	Where it is enforced	Page
What can the model ask the runtime to do?	The tool registry: declared tools, closed parameter lists, prerequisites, budgets	The runtime, before any input reaches the desktop	What the model can do
What can the runtime process itself read, write and connect to?	The session container, and the session user’s own rights inside it	Kasm and the container runtime. The runtime adds no kernel-level confinement of its own	What the runtime can reach

The first boundary only applies when the runtime’s own loop is using a model. The runtime works without one: scripted scenarios, browser control over the Chrome DevTools Protocol and an outside agent driving the session over MCP or HTTP need no model in the runtime. See When you need a model.

Tool registry around the model

When the runtime runs its own agentic loop (a scenario with a goal:), the model can only call the tools declared for that run. A call to a tool that is not declared is rejected as malformed and costs the model part of its retry allowance. Parameters are checked against each tool’s schema, and prerequisites such as “observe the screen before a pointer action” are checked before the tool runs.

The design follows Forge (Zambelli): the guardrails that depend on meaning (which tools exist, what they require first, what counts as a failure) are enforced in the runtime’s code and never left to the prompt.

What the model can do lists the limits of this boundary. The main one is that the scenario author decides the vocabulary. A scenario can declare its own tools, including ones that run literal shell commands, and the registry then offers them to the model. The guardrail is review of the scenario file; shell access is present in the binary.

Container around the process

The runtime process has the session user’s rights inside the session container. It can read what that user can read, including the home directory and any mounted persistent profile, and it can open network connections to anywhere the container can reach. There is no Landlock, seccomp or other process confinement today.

The checks the runtime does make:

• An outside caller must present the session token on every request that acts (MCP, the HTTP interface, the raw DevTools proxy).
• The browser’s DevTools endpoint must be on the local machine unless an operator sets KASM_RUNTIME_CDP_ALLOW_REMOTE.
• File transfer is confined to the session user’s home directory and /tmp.

Details, and what each check does not cover, are on What the runtime can reach.

The container as the boundary

An outside caller on MCP or HTTP is an agent with its own reasoning. The runtime gives it shell, proc.spawn and raw-coordinate input.click, because narrowing those would slow the caller down without removing anything: what the caller could do with a shell it could also do by driving the desktop. The runtime’s own loop is narrower because a small model benefits from a closed vocabulary.

The security question for a deployment is therefore what the session container holds and what it can reach: which credentials are in its environment, what is mounted, and what its network can talk to. Kasm controls those through the workspace configuration.

Limits of these claims

• The runtime does not stop a caller that holds the session token from doing anything the session user can do.
• The runtime does not restrict where the process sends data. A wrong KASM_RUNTIME_VISION_ENDPOINT sends screenshots of the session to that address.
• Screenshots are not redacted. See Secrets and evidence.
• The runtime records evidence of what happened in a run. It does not make a deployment compliant with any standard.

Next

• What the model can do
• What the runtime can reach
• Secrets and evidence