OpenTrApp
A desktop application that runs an autonomous CLI agent inside a five-container security perimeter on your own computer, so a compromised agent or a malicious skill is contained instead of catastrophic.
Context
OpenTrApp is a cross-platform desktop application that runs an autonomous CLI agent inside a five-container security perimeter on the user’s own machine, controlled from a Telegram chat. It is open-source under the MIT license. It ships pre-wired for OpenClaw, and the perimeter is designed to extend to other CLI agents. The agent’s reasoning stays in the vendor’s API, which is Anthropic’s for OpenClaw, so only the agent’s execution layer runs locally.
The problem
Autonomous CLI agents execute shell commands, read files, and load skills from third-party registries. Run with default settings, an agent has the same operating-system privileges as the person who started it. A 2026 study of one such registry classified 11.9 percent of its published skills as malicious, 341 out of 2,857. The risk is therefore concrete rather than theoretical. A single bad skill, a prompt-injection attack, or a compromised agent inherits the whole machine. OpenTrApp exists to answer one question. How do you run these agents so that the blast radius of a compromise is contained, without pretending the risk can be removed entirely?
Approach
The answer is defense in depth across five containers, each with a single job, connected by internal networks.
- The agent container runs the agent itself with a read-only root filesystem, every Linux capability dropped, a custom syscall profile, and only the sandboxed workspace mounted.
- The supply-chain container defends what the agent loads. It scans every skill against 87 patterns mapped to the MITRE ATT&CK framework and runs a Content Disarm and Reconstruction pipeline before anything is allowed in.
- The application-policy container holds the API keys and injects them into each request, so the agent container never reads the literal key. It also enforces a domain allowlist, and it has no internet attachment of its own.
- The network-policy container is the only one attached to the internet. It drops private-range traffic at the kernel and pins its DNS to a secure resolver. It holds elevated network capability but no secrets.
The load-bearing property is that separation. No single container ever holds both the API credentials and the elevated network capability, so compromising one part does not hand an attacker both the keys and the door.
What’s interesting
This is honest security engineering rather than a safety claim. The project states plainly that containing an autonomous agent is an open research problem, and that the perimeter raises the cost of a compromise without eliminating the possibility. A documented threat model names the residual risks, and a written comparison weighs the design against alternatives such as Firejail, gVisor, virtual-machine isolation, and scanner-only approaches. The same rigor runs through the supply chain. Every release ships a CycloneDX software bill of materials, a keyless cosign signature, and SLSA Build Level 2 provenance, and the repository carries CodeQL analysis and an OpenSSF Scorecard.
Outcome
The result is a cross-platform desktop application for Linux, macOS, and Windows, built on Tauri with a Rust backend and a React frontend, installable with no terminal interaction and published open-source at opentrapp.com. It is verified by 56 Rust unit tests, 74 frontend tests, 25 end-to-end Playwright tests, a 42-check manifest validator, and a TypeScript strict pass, all run in continuous integration on every push and every release. This is the project I point to for security-first thinking about autonomous agents, which is the problem I most want to keep working on.
The stack is Tauri, Rust, TypeScript with React, Podman or Docker for the container perimeter, and Telegram for the chat interface.