Agent Canvas at Liberty Labs

A plan based on source inspected on 6 November 2026. The proposed service is not deployed.

The intended experience is straightforward: an invited Liberty Labs member opens openhands.liberty-labs.org, signs in through Liberty Labs, connects their own DigitalOcean account, and starts an agent. Their conversations, files and provider credentials belong to their workspace. Their ability to operate an agent does not give them permission to edit the publication.

DigitalOcean can provide all agent execution. Canvas still needs a Node host, and the current code needs additional isolation before it can safely serve several invited users. The existing implementation and the intended DigitalOcean PRs provide much of the transport and provider integration. The work for Liberty Labs is to make identity, ownership and resource lifetime explicit around them.

This note develops that plan. “DigitalOcean only” means no host-local execution backend and no second execution provider. It still leaves a website to host, credentials to protect, connections to carry and resources to clean up.

Three places the system runs

The browser runs the Agent Canvas interface: backend selection, conversation views, model settings and file controls. It sends requests and displays events. Agent tools do not execute in this browser interface.

The Canvas Node bridge holds the DigitalOcean management credential, calls the provider API, opens port-forward tunnels and proxies HTTP and WebSocket traffic. The DigitalOcean guest is a microVM running the OpenHands Agent Server and its workspace. Shell commands, file changes, browser tools and model calls happen there.

Canvas already has a frontend-only launch mode that omits the host Agent Server and automation service. A remote DO guest appears through Canvas’s generic Agent Server adapter, whose internal name is local. That label describes the protocol adapter; it does not move execution onto the website host.

The proposed arrangement is:

Member's browser
       |
Canvas gateway ---- Liberty Labs identity
       |                     |
Private member bridge     Existing D1
       |
Member's DigitalOcean guest
       |
Member's selected model provider

Liberty Labs keeps its planned Cloudflare Worker and authoritative D1. A separate Linux control host runs the gateway, private member bridges and cleanup supervisor. A small operational database records Canvas sessions, resource ownership and unfinished operations. It does not copy publication writing or become another membership authority.

Today’s Node tunnel implementation uses real TCP listeners and long-lived sockets. Persistent credential storage also needs host facilities. Cloudflare’s Node compatibility does not make this bridge a drop-in Worker: its net implementation does not support net.Server. Keeping the existing Node component on a conventional host is the simpler first step.

Why a login page is not enough

The current bridge has one admission key and one active DigitalOcean connection. Multiple saved connections let one operator switch accounts or teams. They are not separate website users.

A synthetic probe against both current main and the pending PR stack made the consequence concrete. Two admitted callers could see the same saved provider connection and reuse the same tunnel. Signing one connection out could select another stored connection. The probe used fake credentials and provider responses, with no real resources or model calls.

For a small invited group, I recommend a private bridge container per member, selected by an authenticated gateway. Each container gets its own credentials, state, internal key and restricted filesystem. Containers accept traffic from the gateway only. A process sharing the same operating-system identity and files with every other process would not provide the same isolation.

The gateway must still check ownership. A browser-supplied session ID cannot choose another member’s container or resource. Even two members using the same DigitalOcean team must see only their own LL-managed sessions. Every operation stays bound to the selected account throughout its lifetime; switching accounts in another tab must not reroute an in-flight request.

Guests must be separate too. The Agent Server has instance-wide authentication and profile stores. Today’s Canvas DO path deliberately relies on the authenticated provider tunnel around a keyless guest. That boundary needs verification, including the absence of an unprotected public ingress. The bridge’s private key is not a guest credential.

Browser state also needs attention: cached conversations, backend metadata and open sockets must be partitioned or cleared when the signed-in member changes.

A shared Node service carrying a user identity through every store, request and tunnel remains a credible later alternative. It would use fewer processes, but require broader changes and stronger concurrency testing.

The same invitations, a separate session

Liberty Labs should remain the only authority on who is invited and active. The proposed agent-use permission belongs to Engel and active invited members; publication administration remains Engel’s alone.

The publication’s secure cookies are deliberately host-only. Sharing them across the parent domain would weaken an existing boundary. Instead, Canvas should receive a narrowly scoped grant through a short sign-in handoff and establish its own secure session.

The handoff needs a fixed callback, browser-bound state and PKCE protection, a short-lived single-use code, and a server-to-server exchange. LL rechecks active membership before issuing and exchanging the code. Canvas receives no publication signing key, Google token or direct D1 access. Its grant cannot authorize editing or sharing publication content.

This is new integration work. LL already revalidates active members against D1, but it does not yet issue Canvas grants. Account revocation must deny subsequent Canvas operations and invalidate old grants. Reconnection is another authorization check, not permission to reuse an earlier decision indefinitely.

Open streams need an explicit rule. The proposed first target is a renewable authorization lease of at most 15 seconds: revocation denies new requests at their next check and closes existing streams within that tested bound. This is a design target, not behavior already demonstrated by a deployed system.

The checks cover provider settings, resource creation and deletion, files, terminals, model profiles, event streams and downloads. UI visibility cannot substitute for protection on those routes. Browser mutations also need exact Origin and CSRF checks; sibling subdomains can be same-site without being the same origin.

Logout requires durable login and grant records. Deleting a cookie cannot invalidate a copied credential. LL logout should revoke the source login and its Canvas grants, and a revoked login must not mint replacements. Existing stateless LL sessions would need a fresh tracked login before receiving their first Canvas grant.

Connecting an account and a model

The first setup flow can stay small:

1. Accept the normal LL invitation and sign in through LL.
2. Connect the member’s own DigitalOcean account and confirm the displayed team.
3. Choose an allowed sandbox size and understand its lifetime policy.
4. Attach to the guest and configure an explicit model profile.
5. Start work, reconnect, pause or stop the member’s own registered resources.

A DigitalOcean management token does not automatically configure Canvas’s model. DO can also supply inference, and suitable DO credentials can authenticate it, but the model/profile choice is explicit and inference remains separately billable. Prefer a narrowly scoped model credential over giving an agent guest a broad provisioning token. DO model access keys

The costs belong in three understandable groups:

Cost	Account responsible
Publication and Canvas control host	Liberty Labs
Agent execution and retained DO resources	The member’s selected DigitalOcean account
Model inference	The member’s selected model account or key

No price is assumed here. DO documents separate runtime, storage and network dimensions, and no per-session Harness Runtime spending cap. Application limits are necessary, but they are not an exact currency budget guarantee. Runtime pricing

Current Canvas configures the model after attaching to a guest, so execution cost can begin during setup. Missing DO credentials must block provisioning; a missing model credential must block conversation creation and running. Neither case may fall back to Engel’s account, a host model key, another member’s connection or local execution.

Closing a tab is not cleanup

The gateway records a creation attempt before contacting DO, then records the returned config and session IDs. It opens the tunnel, verifies readiness and the actual Agent Server version, and makes the guest available to that member. Conversation events return through the same protected proxy.

On reconnect or host restart, the gateway restores ownership and credentials before rebuilding authorized tunnels. It should not wake every remembered sandbox merely because the website restarted.

Disconnect, pause, cancel a turn and destroy a sandbox are different actions. Closing transport can leave a paid session alive. Canvas emits keep_warm: false for its new configs, while DO’s own OpenHands flow describes a keep-warm default. Existing configurations can differ, and tunnel activity can affect idling. The effective lifecycle needs testing rather than an assumed timeout. DO’s OpenHands and Canvas guide

Cleanup needs durable jobs and a supervisor. A create request can time out after the provider has created a resource; a process can crash before recording success. Retrying blindly can create duplicates. Cleanup must reconcile known operations and never delete unrelated resources by a broad name match.

Revoking LL access stops interactive use, while a restricted background capability cleans up the user’s already recorded resources. If the user revokes their DO token first, the service must report unresolved resources and the account-side recovery action. It cannot substitute Engel’s credentials.

File retention is a separate decision. Guest conversations and files live with the guest’s storage. DO offers persistent workspaces, but the inspected Canvas flow does not automatically attach one. We should not promise that work survives destructive Stop and recreation until that behavior is implemented and verified.

What the intended PRs contribute

The investigation considered current upstream main together with this dependency stack, still open when checked on 6 November:

• #18706: browser authorization-code/PKCE sign-in and credential refresh.
• #18707: programmatic agent access and sandbox preparation moved into Node.
• #18711: one-time device pairing links and QR codes.

The stack needs reconciliation with current main; #18706 had conflicts. Durable provider sign-in, explicit bridge opt-in and the synthetic DO stand-in are already in main. The investigation did not produce or validate a combined build.

The inspected OAuth addition still sends a public hostname to a loopback callback and offers manual pasting of the return URL. A proper hosted callback remains work for this service. PAT entry is the simpler first account-connection flow.

Pairing currently transfers broad Canvas authority. It is not an invitation system. Pairing and unscoped agent-key admission should stay disabled until they can issue limited capabilities bound to an LL member and resource.

The implementation plan

First, reconcile and pin the code. Integrate the intended PR stack with current main in isolation, preserving main’s opt-in and dependency changes. Record the resulting Canvas/client versions and check the actual DO guest template against the required Agent Server contract.

Second, establish a supported DO-only control mode. It must work from an empty browser without starting a host Agent Server or automation service. The existing frontend-only mode helps, but its public-launch restriction and session-key bootstrap mean it is not already the complete LL hosting recipe.

Third, implement the LL handoff. Add scoped, revocable grants, active-member validation and logout lineage to the existing application. Prove the protocol with synthetic members before connecting it to the operational gateway. Any database changes preserve existing writing and membership.

Fourth, add ownership and lifecycle management. Introduce private member containers, an operational resource registry, encrypted credentials, concurrency reservations, size/lifetime limits and cleanup recovery. A single-host database and supervised jobs table can be sufficient initially; a separate queue cluster is not inherent to interactive Canvas use.

Untrusted agent code stays in the DO guest. Management tokens stay on the control side, and the Canvas host carries no LL signing keys, private writing or local execution credentials. Guest-accessible model/tool keys remain accessible to that guest’s code. Agent-generated HTML and previews must not execute with the authenticated Canvas origin.

Fifth, prove the boundaries before invitations. Use two independent synthetic users and guests to test anonymous denial, active-member admission, revoked-member denial, cross-user resource IDs, missing credentials and absence of operator fallback. Exercise HTTP and WebSocket streams, reconnects, shared-browser identity changes, quota races and cleanup after crashes or provider errors. Confirm that ordinary members still cannot edit LL publication content.

A separately authorized hosted trial must then verify real callbacks, provider scopes, transport, guest compatibility, lifecycle and recovery. The work so far establishes source behavior and a synthetic shared-state failure; it does not establish a deployed integration or live DO behavior.

Decisions before the first invitation

Four choices remain concrete enough to make now:

• Accept private member containers on a separate control host for the first cohort, or invest immediately in a shared service designed around per-user state.
• Start with PAT entry and encrypted durable credentials for recovery, or require hosted DO OAuth from the first invitation.
• Choose sandbox sizes, per-user and total concurrency, maximum lifetime and retention before destructive Stop.
• Accept the proposed 15-second stream-revocation bound and login-linked logout, or require tighter coordination.

The implementation starts from a viable execution path. The missing part is the service boundary: who may act, which resources belong to them, and what happens when their session or invitation ends.

Dated source baseline

The source inspection used Canvas main at 22e3057, SDK main at f19fb2c, and the pending stack at 5c302df. PR status and provider documentation are dated observations, not promises about a later release. No paid agents, provider resources or deployment were used to prepare this plan.