Security
A control plane you only need to trust as far as necessary.
Nythronix is designed so that a compromised control plane does not mean compromised machines. Here are the mechanisms behind that design.
- Outbound connections only
The agent connects to the control plane itself. No inbound ports, VPN, or public IP address are needed on the machine. There is no exposed port to attack.
- End-to-end SSH encryption
The relay forwards a TCP stream, while the SSH session inside it is encrypted with your keys. The control plane sees the connection, not its contents.
- An unprivileged agent
The agent runs as an unprivileged user. A sudo policy grants elevated permissions for specific commands and a limited time. The machine owner can tighten the policy locally.
- Command allowlist and audit log
Non-interactive commands must pass an allowlist. The audit log records what ran, who ran it, and when, including actions through the CLI.
- Humans approve AI changes
Workers can read freely, but any command or MCP tool that makes changes waits for operator approval. A different person from the task author can approve it.
- Signed releases
Agent binaries are signed with Ed25519. The agent verifies the signature before updating itself and rejects any mismatch.
- Worker and skill isolation
Workers run in separate containers with outbound traffic filtering. MCP skills run in separate processes with reduced privileges.
- Temporary access by code
Access to someone else's machine uses a single-use code with a limited lifetime. The owner can revoke access at any time.
What the control plane stores
| Stored on the control plane | Never passes through the control plane in plaintext |
|---|---|
| Operator accounts and password hashes | SSH tunnel and scp contents |
| Machine inventory, tags, and agent versions | Operators' private SSH keys |
| Audit log: who did what, when, and on which machine | Database data accessed by MCP skills: the skill runs on the machine |
| Output buffer for active terminal sessions, for shared viewing | The release signing key in a self-hosted installation |
| Channel history and worker memory |
For the full description and settings, see the Security model documentation.
Self-hosting for maximum control
If your data must stay within your infrastructure, deploy the control plane yourself: Docker Compose, your own database, and your own signing key. The functionality is the same.
Self-hosted deployment