feat(driver-tensorlake): add a Tensorlake compute driver that runs sandboxes in remote microVMs #4795

User Story

I use OpenShell to run coding agents such as OpenCode inside sandboxes.
I need each sandbox to run in its own small virtual machine on Tensorlake, not on the machine that runs the gateway.
This affects anyone whose gateway runs on a laptop, a CI runner, or a cloud machine that cannot create virtual machines.

Problem Statement

Today every OpenShell runtime runs the sandbox on the gateway's own machine, or in a Kubernetes cluster the operator runs. There is no runtime that asks a cloud service to run the sandbox in a virtual machine for you.

Impact / Why This Matters

A virtual machine is the strongest boundary around an untrusted agent. Today that boundary needs a gateway machine that can create virtual machines. Many machines cannot. Those users must settle for a container boundary or set up a Kubernetes cluster. The first is weaker. The second is a lot of work for one developer or a small team.

Proposed Design

Add a new runtime, openshell-driver-tensorlake. It is a separate program that runs next to the gateway. When the gateway needs a sandbox, the driver asks Tensorlake to create virtual machines, and Tensorlake runs them.

The CLI does not change. Users create, connect to, stop, start, and delete sandboxes as before.

Each sandbox uses two virtual machines:

• One runs the agent. It has no network connection at all.
• One runs the guard. The guard holds the credentials and the connection to the gateway. Every connection the agent makes goes through the guard, and the guard applies the policy.

The agent's machine never holds a credential.

Gateway configuration:

[openshell.gateway]
compute_driver = "tensorlake"

[openshell.drivers.tensorlake]
socket_path = "/run/openshell/tensorlake.sock"

Workflow:

openshell sandbox create --name agent-1 --policy policy.yaml
openshell sandbox exec agent-1 -- opencode
openshell sandbox stop agent-1
openshell sandbox start agent-1
openshell sandbox delete agent-1

Stop pauses the machines and keeps the files. Start resumes them with fresh credentials.

Acceptance Criteria

• With the driver configured, the normal CLI commands create, exec into, stop, start, and delete sandboxes.
• The agent's machine has no network of its own. Every connection goes through the guard and follows the policy.
• No credential is present on the agent's machine.
• Stop keeps the workspace. Start brings it back.
• If a machine dies, the sandbox shows as failed with a reason.
• The CLI shows progress while the sandbox starts.
• A docs page explains setup and the trust model.
• A real agent, such as OpenCode, runs end to end under a policy.

Alternatives Considered

• Middleware, interceptors, providers. These do not change where a sandbox runs. Only a compute driver does.
• Extend the VM driver. That driver creates virtual machines on the gateway's own machine. Tensorlake creates them elsewhere through an API. The two are different enough to keep apart.
• One machine for agent and guard. Built first, then removed. If the agent escapes, it reaches the credentials. Two machines keep the credentials away from the agent.

Agent Investigation

• The existing compute driver contract was enough. No proto change.
• A working implementation exists on a fork branch:
  https://github.com/tensorlakeai/OpenShell/tree/feat/add_tensorlake
  It includes a driver README, a docs page, a tutorial that runs OpenCode on Tensorlake end to end, and a record of an OIDC login run. It is ready to open as a PR once this issue is accepted.

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request