OpenBot – CopilotKit Open-Source Enterprise AI Agent Platform

1. What is OpenBot

OpenBot is an open-source enterprise AI Agent platform developed by the CopilotKit team, positioned as "a digital colleague capable of handling real work tasks." The platform assigns each agent an independent "dedicated computer"—a separate Docker container equipped with a Chromium browser, login session, and file workspace; all operations must pass through a single gateway and be audited first according to CEL policy before execution, with fail-closed defaulting to rejection; it supports manual takeover for authentication steps when encountering login or 2FA requirements. Based on the AG-UI protocol, it is compatible with any framework including LangGraph, fully self-hosted, and emphasizes isolated, auditable, and intervenable agent governance infrastructure.

Technical Positioning & Domain: OpenBot belongs to the AI Agent infrastructure and governance platform domain, focusing on secure operation and control of enterprise-level agents. Unlike traditional agent frameworks, OpenBot does not directly provide model capabilities or orchestration logic, instead establishing a governance system at the protocol layer that combines "computational isolation + mandatory auditing + manual intervention," enabling agents to safely operate real production systems.

Development Background: OpenBot was developed by the CopilotKit team. CopilotKit is an actively maintained open-source AI Copilot framework project within the community, accumulating rich agent application development experience. During service to numerous enterprise users, the team identified that the primary obstacle to agent implementation is not insufficient model capabilities, but rather the lack of trustworthy execution environments and audit mechanisms, which led to the creation of this governance-oriented agent platform designed for "real work."

Core Value: OpenBot transforms the question of "whether to allow agents to interact with production systems" from a trust issue into an engineering problem. Through independent containers for each agent, a single audit gateway, CEL policy engine, and manual takeover mechanisms, the platform achieves comprehensive control and traceability of agent operations. Enterprises can obtain governance capabilities aligned with production environment security requirements without modifying existing agent frameworks.

Technical Features: The platform adopts the AG-UI protocol as the agent integration standard, achieving framework-agnostic governance capabilities; all operations are written to audit logs before execution, with no bypass paths; fail-closed security defaults reject unauthorized operations by default, and reject rather than allow when policy rules are erroneous; supports gVisor kernel-level isolation to further strengthen environmental security.

2. Key Features

• Dedicated Isolated Environment: Supervisor creates independent Docker containers for each Bot, containing a Chromium browser (with isolated session state) and a /workspace file workspace. Supports gVisor kernel-level isolation, ensuring Agent processes remain mutually invisible. A single container failure does not affect others, eliminating risks of cross-contamination and data leakage from shared environments.

• Unified Audit Gateway: All browser, file, MCP, and component operations pass through a centralized gateway. The system first parses targets, evaluates policies, and writes audit logs before executing or rejecting actions. No bypass paths exist – even if execution crashes or Agents attempt circumvention, all intent traces are permanently recorded.

• CEL Policy Engine: Rules can be defined across tool names, Bots, users, URLs, page elements, files, and MCP operations. Deny rules take precedence, with default rejection for unconfigured actions. Policy errors result in rejection rather than allowance, shifting security posture from "default allow then block" to "default deny then whitelist".

• Take the Wheel Human Takeover: When encountering login walls or 2FA requirements, Bots automatically request human intervention through a shared control panel. During takeover, Bot actions are directly blocked rather than queued, preventing human-AI operation conflicts. Full traceability is maintained, standardizing the workflow where "human completes one authentication step, then full automation follows".

• Framework-Agnostic Integration: Based on the open AG-UI protocol, any endpoint implementing AG-UI can be integrated as a Bot. Supports LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK, or custom hand-coded Agents. Governance logic operates at the protocol layer, preserving control capabilities across framework migrations.

• Component-Based Output: Agent responses are not limited to text – interactive React components can be rendered directly. Built-in components and sandbox components require zero deployment, with granular permission controls per component. Enables complex interaction patterns like forms and charts within AI responses.

• Secure Key Management: Credentials are encrypted at rest, API keys are never returned in responses, and audit logs only record key lengths (not contents). Keys are excluded from conversation history, ensuring sensitive information remains protected from exposure in logs or dialogue contexts.

• Governance-Enforced MCP Integration: Includes built-in Google Drive connectors, with custom MCP servers requiring URL validation. Any tool not explicitly classified as "read-only" is treated as "write" by default, maintaining the most conservative approach to external tool calling governance.

• Enterprise-Grade Identity & Access Control: Supports Google/Microsoft/Okta authentication and runtime SAML/OIDC registration (domain-based email routing). Administrators can dynamically adjust permissions, revoke access, and terminate sessions instantly.

• Readable Audit Center: /admin/audit lists all allowed, denied, and failed operations, with each denial explicitly noting the triggered rule. Provides full traceability for security teams with structured visibility into policy enforcement decisions.

3. How to Use

1. Environment Preparation: Install Docker (for PostgreSQL and Bot containers) and Bun 1.3+ (for frontend and API server), and prepare a large model API key (e.g., OpenAI Key).

2. Clone the Repository and Initialize Configuration: Execute git clone https://github.com/CopilotKit/openbot.git, then run cp .env.example .env in the directory to create the environment variables file.

3. Obtain Intelligence Credentials: Run sequentially npx --yes copilotkit@latest login, project select, license --write, and input the generated cpk-... runtime key into the INTELLIGENCE_API_KEY field in .env. Intelligence offers a free plan and supports self-hosting.

4. Fill in Required Environment Variables: Enter OPENAI_API_KEY in .env; in production environments use openssl rand -base64 32 to generate your own KEY_ENCRYPTION_KEY, while local testing can use example values.

5. One-Click Launch: Run bun install to install dependencies, then execute bash scripts/start.sh—the script will automatically start Docker services, perform database migrations, launch the API server (port 3001) and frontend (port 3010), and verify service health status.

6. Access the Main Interface: Open http://localhost:3010 in your browser to view the channel list and pre-configured "colleagues" (General Assistant, Knowledge, Risk Analyst).

7. Getting Started with Experience and Policy Management: On the /bot page, instruct the Bot to open Hacker News and read headlines, fill out the httpbin test form, then check audit logs at /admin/audit. Navigate to /admin/boundaries to add a deny rule, retry the same operation, and observe the Bot being rejected with the triggered rule notification.

8. Creating Custom Colleagues and Daily Management: Create new Bots on the /agents page by configuring names, role descriptions, and AG-UI endpoints, or declare them in agents.yaml. Use /admin/computers to view or reset Bot devices, /admin/credentials for encrypted credential storage, /admin/plugins to configure MCP servers, and /admin/people for member permission management.

4. Pros and Cons Analysis

5. Comparative Analysis with Similar Tools

Selection Recommendations: For industries such as finance and healthcare with stringent data security and operational auditing requirements, OpenBot's fail-closed strategy, unified audit gateway, and human takeover mechanism meet compliance needs. It is the only platform among the three that positions governance capabilities as its core value proposition. If enterprises have already invested in Agent frameworks like LangGraph or CrewAI, OpenBot's AG-UI protocol integration preserves existing framework assets while adding governance layers.

For teams prioritizing software development efficiency, OpenHands' autonomous coding capabilities and visual workspace offer more direct value. However, its audit and policy features are primarily available in the enterprise edition, requiring additional control measures in self-hosted scenarios. For developers needing lightweight code execution sandboxes, E2B's microVM solution excels in isolation granularity and startup speed. However, it requires external policy and audit implementation, and lacks BYOC deployment support, resulting in limited data sovereignty.

6. Editor's Summary

OpenBot provides a compelling architectural paradigm in the AI Agent governance domain. Its core innovation lies in redefining security as an infrastructure capability rather than an Agent behavior constraint: each Agent operates within an isolated Docker container and maintains its own browser session state, physically isolating Agents from influencing each other; the single audit gateway ensures all operations are logged before execution, eliminating blind spots in operational pathways; and the CEL policy engine's fail-closed design inverts the default security posture from "permit then block" to "deny then whitelist," a model validated through enterprise security practices as more robust.

From a practical standpoint, OpenBot addresses the most challenging trust issues in Agent deployment. The Take the Wheel manual takeover mechanism establishes standardized collaboration workflows for scenarios requiring human intervention (e.g., login, 2FA), enabling Agents to securely operate enterprise internal systems under human supervision. Its fully self-hosted deployment model combined with encrypted key storage satisfies compliance requirements in finance, healthcare, and other regulated industries.

OpenBot is particularly suited for enterprise technical teams with clear governance requirements, especially organizations that have invested in Agent frameworks like LangGraph but lack execution environment control capabilities. The AG-UI protocol design reduces migration costs, allowing governance capabilities to persist through future framework upgrades via the protocol layer. While the project's community ecosystem and documentation maturity are still evolving, its "governance-first" product philosophy demonstrates clear practical value in the large-scale deployment of AI Agents.

7. Application Scenarios

• Enterprise Knowledge Q&A Assistant: Integrate with internal company knowledge sources (e.g., Google Drive connectors), enabling the "knowledge colleague" to answer employee questions about company policies and documentation. All access actions are logged and auditable, meeting internal knowledge management compliance requirements.

• Risk and Compliance Analysis: The pre-installed Risk Analyst colleague can perform risk monitoring, transaction reviews, and compliance checks. The strategy gateway ensures it can only access authorized data and systems, reducing the risk of human non-compliance.

• Internal System Automation: Use "manual takeover" mode to handle scenarios requiring login to enterprise intranet systems and completion of 2FA authentication. After a human completes one authentication step, the Agent automatically executes subsequent procedures, balancing security and efficiency.

• Financial/Operational Data Processing: The Bot executes scripts, processes spreadsheet files, and installs required dependencies within its own workspace. All command and file operations are audited through the gateway, making it suitable for operational scenarios involving sensitive financial data.

• AI Assistant in Sensitive Data Environments: Credentials are encrypted and stored, keys are not recorded in conversation logs, and audits only record the length, not the content. Ideal for industries with strict data security requirements (e.g., finance, healthcare), enabling AI assistance while maintaining compliance.

• Multi-Agent Collaboration Workspace: Different functional Bots (general assistant, knowledge base, analyst) have dedicated channels and independent workspaces. Employees can @colleagues to collaborate with multiple Agents in parallel, with each Agent's operational boundaries clearly defined and controllable.

8. FAQ

Q: What is the relationship between OpenBot and CopilotKit?
A: OpenBot is an enterprise-grade AI Agent platform open-sourced by the CopilotKit team, while CopilotKit is the team's maintained open-source AI Copilot framework project. OpenBot can be understood as an extension of CopilotKit in the Agent governance domain, utilizing the AG-UI protocol as the standard for Agent integration. It is not bound to the CopilotKit framework itself.

Q: Which Agent frameworks does OpenBot support?
A: Any endpoint adhering to the AG-UI protocol can be integrated as a Bot, including LangGraph, Mastra, CrewAI, Pydantic AI, Google ADK, and custom-written Agents. Since governance logic operates at the protocol layer, switching underlying Agent frameworks will not compromise audit or policy capabilities.

Q: How does the fail-closed policy work specifically?
A: Fail-closed means operations without matching policies are denied by default. Deny rules take precedence over allow rules, and rule parsing errors are handled by rejection rather than allowance. Administrators define CEL policies in /admin/boundaries, and every rejection is logged in the audit center with the specific rule that triggered it.

Q: How are data and keys stored in OpenBot?
A: The platform is fully self-hosted, with data stored in its own PostgreSQL database. Model keys are configured by administrators in .env, and credentials are encrypted using KEY_ENCRYPTION_KEY. API responses never return keys, audits only record key lengths (not content), and keys are excluded from conversation logs.

Q: How can Agents handle systems requiring login and 2FA?
A: When a Bot encounters a login wall or 2FA requirement, it will proactively request user assistance. Users can click "Takeover" on the same panel to manually complete authentication steps via the browser. During takeover, Bot actions are directly rejected, and control is returned post-authentication to allow Bot automation to resume. The entire process is fully traceable throughout.

Q: What are OpenBot's deployment requirements?
A: Requires Docker (for PostgreSQL and Bot containers) and Bun 1.3+ (for frontend and API server), along with a large model API Key. For production environments, generate your own KEY_ENCRYPTION_KEY using openssl rand -base64 32 and obtain an Intelligence runtime key.

Q: What open-source license does OpenBot use?
A: OpenBot is licensed under MIT, permitting commercial use and secondary development. Compared to competitors like OpenHands, the MIT license offers significant advantages in commercial friendliness, enabling enterprises to build internal Agent governance platforms based on OpenBot without licensing restrictions.

9. Project Links

• GitHub Repository: https://github.com/CopilotKit/openbot (Official open-source repository containing source code, documentation, and deployment scripts)