OpenBot Writes Audit Rows Before Running Computer Actions
Explore OpenBot, an AI agent governance framework that enforces audit logging before actions run using a single gateway, CEL policies, and gVisor isolation.
Stock photo for illustration only, not from the actual event
- OpenBot records audit rows before any computer action runs.
- A single gateway routes computer, file, MCP, and component actions.
- CEL policies evaluate rules with a default-deny fail-closed mechanism.
- Shipped as an alpha developer template rather than a hosted SaaS product.
A core principle detailed in the OpenBot README centers on execution ordering. When an AI bot performs an action on its assigned computer, the gateway resolves the target using a server-held snapshot, evaluates the relevant policy, writes the audit log row, and only then executes the computer command. As the documentation emphasizes, no execution path exists without the audit record being created first.
The project tagline notes that every action is decided before it happens and recorded afterward. Specific features anchor this trust claim within a single gateway that handles interactions across computers, files, MCP servers, and system components. Routing everything through one gateway that both decides and records forms the boundary between an agent that can merely use your tools and one safe enough to approach them.
Decision-making relies on CEL policies, allowing rules to inspect parameters such as tool.name, intent, bot.id, actor.id, page.url, page.host, element.*, key, file.*, and mcp.*. Deny rules are evaluated prior to allow rules, a missing policy permits nothing, and any broken rule defaults to a refusal rather than an opening, a design philosophy termed fail closed. When a refusal occurs, the gateway explicitly names the blocking rule.
Stock photo for illustration only, not from the actual event
Shell commands operate through this exact gate. While a bot can execute commands within its workspace and install required dependencies, administrative rules can block shell access entirely or filter out specific commands, logging the attempt in either case. These shell executions inherit standard variables including PATH, locale, terminal, and proxy settings while remaining isolated from the broader deployment environment.
By centralizing command routing through a single gateway and pairing it with granular CEL evaluation and gVisor container isolation, OpenBot addresses the fundamental security challenges of granting autonomous AI agents direct system access. This architecture ensures strict governance without sacrificing developer flexibility in building multi-tool agent workflows.
Regarding sensitive data handling, the system logs only that a secret was requested and its duration rather than the secret value itself. The activity dashboard tracks executed, read, and saved actions alongside outputs, though saved files log path and size metrics instead of raw contents, with administrators reviewing logs via /admin/audit.
Human intervention flows seamlessly into the audit trail when a bot hits login walls or 2FA prompts, logging events as computer.help_requested, computer.control_taken, and computer.control_released. While a human operator takes the wheel, concurrent bot actions are refused rather than queued.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment