OpenBot: Self-Hosted AI Coworkers with Sandboxed Browsers and CEL Governance

Deploying autonomous agents inside an engineering team often exposes a painful dilemma. If an agent is granted direct access to a developer’s workstation, it can manipulate files, read browser cookies, and access sensitive corporate portals without oversight. Conversely, if the agent is locked inside a text-only chat window, its practical utility drops to answering abstract questions.

The OpenBot project, released by CopilotKit under the MIT license, resolves this tension through architectural containment. Instead of letting agents run loose on a host machine, OpenBot provisions each AI coworker with its own isolated virtual computer. Every browser click, file mutation, and tool invocation is intercepted and audited by a security gateway before execution.

The Architecture of Isolated AI Coworkers

OpenBot is designed as an infrastructure template that runs entirely on local or self-hosted hardware. A single Docker Compose command brings up a multi-tier environment where network isolation prevents the agent from probing internal services:

Services and Port Topology

The runtime consists of decoupled microservices designed to prevent privilege escalation:

To prevent arbitrary code in an agent container from accessing the database directly, Docker Compose isolates PostgreSQL on a dedicated internal data network. Only the backend API server joins both networks.

Action Governance via Common Expression Language

The core innovation in OpenBot is that the agent computer does not decide security policy. Instead, the backend API gateway acts as an enforcement boundary. Before any tool call reaches the computer container, the gateway evaluates the action against declarative Common Expression Language (CEL) rules.

CEL Policy Inspection Attributes

The policy engine inspects full context for every invocation:

• tool.name: The identifier of the requested tool.
• intent: The model-stated rationale for the action.
• page.url and page.host: The active browser destination.
• element.ref and element.role: Specific DOM target details.
• command: Shell strings destined for the terminal.
• file.path: Target filesystem coordinates inside the container.
• initiator.kind: Distinguishes unattended scheduled runs (routine) from active human sessions (person).

Fail-Closed Security Policy

The rule engine follows strict defensive principles:

1. Deny Overrides Allow: Deny rules are evaluated before allow rules. If an action matches a deny condition, it is rejected immediately regardless of allow lists.
2. Fail-Closed Default: If an administrator policy is missing or contains syntax errors, the server refuses to permit actions and halts startup.
3. Immutable Audit Trail: Every decision (allowed or denied) is committed to PostgreSQL with timestamps and initiating actor IDs. If an allowed action subsequently encounters a runtime error, a secondary failure audit row is appended.

The AG-UI Open Protocol: Framework Agnostic Coworkers

A common barrier in enterprise agent adoption is vendor lock-in. Adopting an agent harness often forces teams to rewrite their agents in a proprietary framework.

OpenBot avoids this by adopting AG-UI (Agent-to-User Interaction Protocol). AG-UI defines a standard contract for exchanging turns, rendering rich interactive UI components, and streaming execution thoughts.

Because governance occurs at the protocol boundary rather than inside the model loop:

• A Python agent written with LangGraph or Pydantic AI can run alongside a TypeScript agent built on Mastra.
• Agents return interactive components (forms, tables, confirmation buttons) rather than only raw text.
• Human operators can observe the live browser viewport and intervene when an agent requests assistance.

Self-Hosting and Deployment

Getting OpenBot running on a local workstation requires Docker and Bun 1.3 or newer:

# Clone the repository
git clone https://github.com/CopilotKit/openbot.git
cd openbot

# Install dependencies across the workspace
bun install

# Configure environment variables
cp .env.example .env

# Start database and containerized computer services
./scripts/start.sh

By default, .env.example sets OPENBOT_SINGLE_USER=true, allowing local evaluation as an administrator without configuring an OAuth provider. In shared deployments, this flag is disabled to enforce role-based access control.

Practical Considerations

When planning a deployment of OpenBot, several factors should be weighed:

1. Host Resource Utilization: Because each coworker container runs a full headless Chromium browser, running five or more concurrent agents requires adequate RAM (typically 2GB to 4GB per active agent).
2. Model Token Costs: Agents interacting with complex web pages consume substantial input tokens for DOM trees and visual screenshots. Pairing OpenBot with context-compression tools like RTK helps mitigate operational expenses.
3. Alpha Development Status: OpenBot is under active development. Core configuration schemas and supervisor APIs may change between minor versions.

Conclusion

OpenBot demonstrates that deploying autonomous AI agents does not require surrendering system security. By combining container-level sandboxing, deterministic CEL policy enforcement, and the open AG-UI standard, it offers engineering teams a trustworthy template for hosting AI coworkers on their own infrastructure.

Sources

• OpenBot GitHub Repository
• Official OpenBot Portal
• AG-UI Protocol Specification
• OpenBot Architecture Documentation
• OpenBot MIT License