Overview
RunOnMine is a local-first security gateway between an AI assistant and a machine you own. It gives AI controlled access to files, terminals, browsers, and desktop applications while keeping execution policy, credentials, approvals, and audit records on the local machine.
The product is built around a simple principle: useful AI automation should not require turning a computer into an unrestricted remote shell. Every request passes through an explicit security boundary that can evaluate who is asking, which tool is being called, which resource it targets, and whether the action needs local approval.
The problem
AI agents become much more useful when they can act on a real computer, but machine access changes the risk model immediately. A raw shell, broad filesystem permission, daily browser profile, or publicly exposed MCP endpoint can turn a productive automation into an authority problem.
The difficult part is not exposing another tool. It is preserving enough capability for useful work while making the boundary understandable and enforceable.
RunOnMine treats that boundary as the product rather than hiding it behind configuration.
Product approach
The system separates capabilities and evaluates them independently:
- Files are constrained to directories the user explicitly selects.
- Terminal and processes are evaluated through policy and can require exact local approval.
- Browser automation runs against an isolated browser profile with network and private-address protections.
- Desktop control respects the permissions and limitations of the current operating-system session.
- Remote connectivity uses managed outbound connections while the MCP server remains on loopback.
- Emergency Lock provides an immediate way to stop the agent, managed connectors, queued approvals, and temporary credentials.
New connectors begin with a conservative Safe policy. Broader Developer and Automation policies are available when the user deliberately needs more authority.
Request and approval model
A tool call does not go directly from the AI client to the operating system.
- An AI client sends an MCP request through a configured connector.
- RunOnMine evaluates requester identity, connector identity, selected roots, policy, resource scope, and any exact-action approval requirement.
- The request is allowed, held for local approval, or denied.
- The result is returned to the client and the local audit trail is updated.
Remote connectors cannot approve their own dangerous actions, and remote administrator execution is blocked by a non-bypassable safety ceiling. This keeps the human checkpoint on the machine that actually owns the authority.
Connection model
RunOnMine supports several connection modes without requiring the MCP service itself to listen publicly:
- local stdio for the smallest local surface;
- authenticated loopback HTTP when an HTTP transport is required;
- managed Cloudflare connectors for remote access;
- OpenAI Secure MCP Tunnel integration.
The distinction matters because the connector and the machine-execution boundary remain separate. Remote connectivity can be enabled without converting the local MCP runtime into a general public network service.
Architecture
The project is a Rust workspace split into focused applications and crates for the CLI, agent, desktop control center, optional helper, core policy and storage, MCP handling, OAuth, browser automation, connectors, and platform-specific integration.
Local state uses SQLite, while secrets are kept in the operating-system credential store or the documented encrypted fallback for headless environments. The audit system is tamper-evident and avoids storing raw secrets or command payloads.
The desktop application exposes the security model as a product surface: connection state, permissions, approvals, policy, audit information, diagnostics, and emergency controls are visible rather than buried in runtime files.
Security engineering
RunOnMine is deliberately explicit about what it can and cannot protect.
The project includes selected-root filesystem enforcement, cleared shell environments, isolated browser state, connector identity checks, local approvals, deny rules, secret-store integration, diagnostics, audit verification, and an optional privileged helper that is absent by default.
It is a security boundary and approval system, not a sandbox. Shell, browser, desktop, and privileged tools can still make destructive changes when the user grants that authority. The product therefore focuses on least privilege, clear scope, and recoverable operational controls instead of presenting machine automation as harmless.
Release engineering
The public beta is packaged for macOS, Windows, and Linux, with a combination of desktop and headless builds depending on platform and architecture. Release work includes platform acceptance tests, checksums, SBOM generation, dependency and security gates, clean-install evidence, and dedicated packaging workflows.
The first public beta is v0.1.0-beta.1. It is still pre-release software: the current macOS build is ad-hoc signed rather than Developer ID notarized, and the Windows installer is not yet Authenticode signed. Those limitations are documented directly instead of being hidden from users.
My role
I developed the product direction, trust and permission model, Rust architecture, desktop control experience, connector strategy, browser and machine-access boundaries, test and acceptance system, and the open-source release process.
The project brings together the areas I am currently most interested in: AI agents, local-first software, operating-system integration, security boundaries, and infrastructure that remains understandable to the person whose machine is actually doing the work.
Current status
RunOnMine is open source and available as a public beta. The current release supports real local and remote MCP workflows across macOS, Linux, and Windows while the signing, packaging, compatibility, and security model continue to harden toward a stable release.