About this research · Sources, method & limitations
OpenBot is an open-source AI-coworker project that gives each Bot a browser, files and tools, then routes actions through a gateway that evaluates policy and writes an audit record. Its architecture is security-conscious, but the project is still active development. The right conclusion is “promising controls to inspect,” not “safe by default for production.” Start with a disposable environment, narrow grants and a human who can take over or stop the browser.
OpenBot is built by CopilotKit and presented as a way to hand real work to AI coworkers. The official README describes a real browser profile, a workspace, granted tools and a record of actions. The repository also describes a Hono server for authentication, policy, audit, plugins and channels, plus a separate agent computer. Those boundaries are useful design signals, not proof that your deployment is secure.
This is a documentation-based evaluation. We did not clone the repository, start Docker or Podman, inspect its database, test a policy bypass or measure browser-agent reliability. The guide below explains what the project says, where the architecture helps, and what an engineering team should verify before giving an agent a real login.
The OpenBot architecture in plain English
October 7 release check: v0.1.1
The official releases page now marks v0.1.1 as latest, replacing v0.0.15 as the current reference for this evaluation. Its notes report fixes for secret redaction in recorded shell commands, loopback-hostname restrictions, public-host handling for single-user mode, and Stop/cancellation behavior. They also describe a cloud-metadata address restriction and managed-database TLS handling. These are maintainer claims, not security tests we performed. v0.1.1 release notes.
For an existing installation, review the upgrade instructions and repeat tests for log redaction, refused private destinations, authentication and stopping in-flight work. Do not copy old logs into support tickets without checking them for credentials. A newer version number does not prove your deployment is secure.
Earlier setup changes: v0.0.15
The earlier v0.0.15 notes describe optional Google or xAI OAuth-based model access, desktop setup improvements and Windows-specific startup fixes. API-key connections remained supported in those notes. This section is historical setup context, not a claim that v0.0.15 is still latest. These are maintainer-reported changes, not features tested for this review. Version-specific release notes.
The optional OAuth route requires a configured credential file; it is absent when that configuration is unset. Google sign-in also requires the build's registered desktop client and quota project. Do not assume downloading the app supplies every provider prerequisite. The release also describes automatic local-port selection, pinned Bun enforcement and a Windows Compose-path correction.
For an existing deployment, note the destructive boundary: the desktop reset described in these notes removes the old deployment's database volume. Preserve required records and obtain the owner's approval before using it. Pin the tested version and repeat refusal, takeover and audit checks after an upgrade. New setup features do not establish stronger isolation or production readiness.
The README describes several services: an app UI, a server gateway, an agent computer running Chromium with a workspace and browser profile, and Bot or supervisor services. The gateway is the important path. It resolves the target, evaluates policy, writes an audit row and then calls the computer. The lower-level computer endpoints are meant to stay private rather than become a shortcut around the gateway. See the official README.
That gives a simple mental model:
| Layer | What the project says it does | What your pilot must prove |
|---|---|---|
| Identity and grants | Bots and users receive explicit tools, connectors or computer access | A removed grant blocks new actions and cannot be bypassed through another route |
| Gateway | Resolves the target, checks policy and writes an audit row before calling the computer | The audit decision matches the exact target, arguments and result |
| Computer | Own browser profile, files and shell-facing workspace for a Bot | The profile cannot reach production data or another Bot's files in your deployment |
| Human control | A person can take the wheel and the Bot pauses while the person drives | Taking over also stops shell, file and background actions that could change state |
| Operations | Compose and Kubernetes paths, configuration and secrets are documented | Updates, backups, logs and network rules are managed by someone who owns the deployment |
What looks strong in the documentation
Policy before action
OpenBot's README says the gateway evaluates policy and writes an audit record before the action reaches the agent computer. Its release notes describe CEL boundary rules that fail closed, which means a malformed or unrecognised rule should deny rather than silently allow. This is a valuable pattern: a model suggestion becomes a request that a separate control layer can inspect.
Still, “policy before action” needs a deployment test. Ask the team to show a refused navigation, shell command, file write and plugin call. Confirm the refusal names the rule and leaves an audit record without leaking secrets.
Per-Bot computers and profiles
The project presents each Bot as having its own computer, browser profile, files and granted tools. A separate workspace can reduce accidental cross-task access and makes a reset easier to reason about. It does not erase risk from a credential that can reach a real account. A profile logged into a production dashboard is still a production credential, even if the container has a different name.
Audit records that include refusal and failure
OpenBot's release notes emphasise that permitted, refused and failed actions are represented in the audit trail. That is better than logging only successful clicks. For investigations, capture the initiating user, Bot, target, policy verdict, arguments after redaction, result and timestamp. Define who can read and export those records.
Human takeover
CopilotKit describes “take the wheel” for a human to drive a Bot's browser, including a sign-in page, while the Bot pauses. This is a useful interaction for a blocked step. It is not a complete approval system: the team must also verify that shell, file and scheduled actions pause, and that the human knows which account and permissions the browser currently holds.
What remains unproven
The public repository does not give this article enough evidence to claim production readiness, a security certification, a guaranteed sandbox or stable performance. The release page labels early versions as active development with rough edges. Version numbers, configuration fields and threat boundaries can change quickly.
Do not infer any of the following from the architecture diagram alone:
- that a Bot cannot be tricked by prompt injection;
- that a browser session cannot access an internal service;
- that an audit log is complete during a network failure;
- that a container boundary meets your compliance or isolation requirement;
- that a policy rule covers every new tool or connector;
- that an agent will stop after a timeout rather than retrying.
Those are acceptance tests for your environment, not facts established by a README.
A safe first pilot for a browser agent
Choose a task that can be undone: triage a synthetic inbox, label test tickets or collect public product information into a local file. Do not begin with banking, payroll, customer deletion, production deployment or a mailbox with sensitive threads.
Step 1: inventory every path
List the Bot's browser profile, shell, workspace, MCP tools, plugins, network egress and scheduled routines. For each path, write the maximum impact if misused. If the team cannot name a path, assume it is not ready for the pilot.
Step 2: create a deny-first policy
Start with no external sends, no destructive filesystem commands, no credentials beyond a test account and no access to internal metadata addresses. Add one narrow allow rule at a time. Keep the policy file versioned and review changes like code.
Step 3: exercise refusal, interruption and recovery
Ask the Bot to open a prohibited domain, read a different Bot's file, run an unapproved command and repeat a timed-out action. Take the wheel during a login wall. Then stop the job, revoke a grant and restart the service. Record what happened and whether the result can be reconstructed from the audit trail.
Step 4: inspect the exact browser result
A successful tool response is not proof that the intended page changed. Compare the browser screenshot, URL, resulting record and audit row. If a network request times out, inspect the account before retrying; browser agents can otherwise duplicate a submission.
Define the boundary
Step 1 of 4Give one Bot a disposable account, a test queue and one read/write action with a named owner.
The Bot can label test tickets and save a local note, but cannot send mail or access customer billing.
Stop and review: A test requires a production session or an undocumented network path.
Run the request
Step 2 of 4Route the browser and file call through the gateway and capture the policy decision before execution.
A label change is allowed; a request to export unrelated tickets is refused with a rule name.
Stop and review: The computer is reachable without the gateway or the audit row is missing.
Interrupt safely
Step 3 of 4Take the wheel, stop the task and revoke the grant while checking browser and shell state.
The human finishes a sign-in, then the Bot remains paused until explicitly returned the wheel.
Stop and review: Shell, file or scheduled work continues after takeover or revocation.
Reconcile evidence
Step 4 of 4Match the audit record to the browser result, file diff and final account state.
The queue shows one label change, the diff names the note and the log includes the decision and result.
Stop and review: A timeout leaves the outcome unknown or the record cannot be exported.
Security questions for an agency or developer team
Is OpenBot safer than a normal browser automation script?
It has a more explicit policy, audit and per-Bot-computer story than a bare script, according to its documentation. That can make review easier. It does not automatically make the deployment safer: a broad grant, a production cookie or an exposed lower-level endpoint can defeat the intended boundary.
Can OpenBot use my existing logins?
The project describes browser profiles and human takeover for sign-in flows. Whether a particular login, MFA method or enterprise policy works is environment-specific. Use a dedicated least-privilege account and confirm the service's credential storage, rotation and offboarding behavior before importing a session.
Is it ready for production?
The repository and release notes show an active project, not a mature certification. Treat the current code, container images, dependencies and configuration as items to review and pin. Run your own threat model, backup test and incident exercise before connecting customer or financial systems.
What should a small US or Indian team build first?
Build a read-mostly workflow with synthetic records: research public pages, classify a test queue or prepare a draft for human approval. Keep the same control points whether the team is in the United States or India: data minimisation, explicit consent where needed, clear account ownership, local retention requirements and a person who can stop the action.
Bottom line
OpenBot's strongest idea is not “an agent that clicks.” It is the attempt to put a policy and audit boundary between a model request and a real computer. That is a useful foundation for a controlled pilot. The honest review conclusion is still conditional: inspect the code and release you will deploy, test every route that can act, and keep production credentials out until refusal, interruption, recovery and audit evidence all pass.
Reader discussion
Comments are public and require a GitHub account. By taking part, you agree to the Terms and Conditions and acknowledge the Privacy Policy.