Hi Product Hunt — I’m Adem, the maker of RunOnMine. AI agents become useful when they can do more than generate text. They need to read files, run commands, inspect a browser and sometimes operate desktop software. The easy architecture is to give the agent broad machine access and let the OS account become the trust boundary. I wanted a more explicit boundary. That became RunOnMine: an open-source, local-first MCP security gateway that sits between the AI client and a machine you own. The core model is: requester + connector + tool + resource + local policy -> allow / ask / deny That led to a few product decisions I care about: • file tools stay inside roots selected by the owner • dangerous actions can stop for an exact local approval • remote connectors cannot approve their own dangerous requests • remote administrator execution is denied • MCP HTTP stays on loopback rather than becoming a public listener • browser automation uses an isolated profile with network protections • audit history makes machine actions inspectable • Emergency Lock is a separate owner-controlled stop path The important part is not making machine automation look harmless. Shell, browser and desktop tools can create real side effects. RunOnMine is a policy/approval boundary, not a sandbox. The first public beta supports macOS, Windows and Linux. It is written in Rust and licensed under Apache-2.0. I’m also being explicit about the beta gaps: macOS is currently ad-hoc signed rather than Developer ID signed/notarized, Windows is not Authenticode signed, and an independent external security review is still pending. The release includes SHA-256 checksums and CycloneDX SBOMs, and the threat model is public. I’d especially like feedback on one question: where should an agent be allowed to act automatically, and where should the machine owner always be asked?

RunOnMine

Local policy and approvals for AI agents on your machine

Local policy and approvals for AI agents on your machine