Why we removed Docker sandboxing from KORVIN, what the decision revealed about honest AI architecture, and what it means for open-source security tools.
Disclaimer: This article documents a personal technical experiment on my own infrastructure. The configurations, rules, and steps described reflect what worked in my specific environment and should not be treated as security advice, professional recommendations, or guaranteed protection against any threat. Every environment is different. Always validate independently, test in a non-production setting first, and consult qualified security professionals before applying any security-related configuration to production systems. NosisTech LLC accepts no liability for outcomes resulting from use of this content.
The sandbox was removed before this series ended. This post is about why, and what that decision revealed about building AI tools honestly.
The Original Design
KORVIN’s early architecture included a Docker-based sandbox for isolated code execution. The design was technically sound. Commands ran inside throwaway Alpine Linux containers with no host filesystem access, no persistent state, a 512MB memory ceiling, and a hard 30-second timeout. When the container terminated, everything inside it disappeared. The host VPS was untouched regardless of what ran inside.
The code worked. The architecture was defensible. It was also never actually used by anything in the system.
The Problem With Unused Infrastructure
A security feature that exists in code but is not called by anything is not a security feature. It is a liability. Here is why that distinction matters.
When an open-source project publishes a README that lists sandboxed execution as a capability, and the dashboard displays a status indicator that says sandbox active, users form an expectation. They assume their commands are being isolated. They assume the feature is real. If that assumption is wrong, the project has not just misled its users, it has misled them specifically about security, which is the one domain where false confidence causes the most damage.
KORVIN’s dashboard was showing sandbox active. Nothing was calling the sandbox. That is not a minor documentation inconsistency. That is a false security claim in a security tool. It had to go.
What the Removal Required
Removing the sandbox meant removing every file that depended on it. The sandbox executor itself. The auto-patcher that imported it. Every status indicator in the dashboard that referenced it. Every mention in the README, the project structure documentation, and the skills definitions. Every import in every file that referenced a module that no longer existed.
IThe fifth post in this series was originally planned as a showcase of sandboxed execution. That post became this one instead.
What Was Not Removed
The reason Docker sandboxing was removed was not that the concept is wrong. Isolated execution is the correct architecture for an AI agent that runs commands. The reason it was removed is that it was not integrated, not maintained, and making claims about it that were not true.
The code will come back when there is a specific command that needs it, when the image is pinned to a verified digest rather than a floating latest tag, and when the integration is real and tested end to end. At that point it will be documented as working, not as planned.
What Is Actually in KORVIN
This is the final post in a five-part series. Here is what KORVIN actually is, verified and working as of this writing.
KORVIN is a personal AI agent. It listens to your voice, remembers your conversations across sessions, and answers questions using live web data. It runs on your own infrastructure, communicates through Telegram (other options are being planned) , and never routes your conversations through third-party servers. A live dashboard gives you a real-time view of your agent and your server, accessible locally by default, or exposed securely through a tunnel if you choose to reach it remotely.
Think of it as a private, self-hosted assistant that knows your context, responds to your voice, and is always available.
For users with technical backgrounds, KORVIN includes security-oriented commands, VirusTotal lookups for URLs, IP addresses, and file hashes, and on-demand CVE research with patch recommendations. These outputs are informational and require human judgment before any action is taken. They are additions to the core agent, not the reason it exists.
KORVIN is available at github.com/nosistech/korvin. The npm package is published at @nosistech/korvin. It is built by one person, runs on a single VPS, and is operated by voice. The goal was always a personal AI that works the way you think, not another security dashboard.