Security model
Cmdop’s security model rests on two things. The agent makes an outbound connection to its relay and keeps it open; nothing dials in, so a joined machine needs no inbound port, no port forwarding, and no VPN. And several credentials stay strictly apart: each gates exactly one thing, and none substitutes for another.
Reusing one credential where another is expected does not work — that is the point of keeping them apart, and it is usually the whole troubleshooting step.
The credentials you are responsible for
| Credential | What it gates | Who holds it |
|---|---|---|
| Fleet join key | Whether a machine may join a relay | The machine, as its durable credential |
| Relay console access | Whether a person or client may use a relay’s console and APIs | The human operating that relay |
| Connection PIN | Access to one specific machine, after relay authentication | The relay, per machine |
| Platform API key | Inference for CMDOP’s built-in engine | The host it is pasted into |
| Platform account sign-in | Account and billing surfaces in the browser | You, in the browser |
Never reuse one of these as another. Keep all of them out of shell history, source control, and URLs — Cmdop’s own links and QR codes carry addresses and short-lived one-time claim codes, never durable secrets.
Machine join
An operator joins a machine to a fleet with the fleet join key:
cmdop join <join-key>This is the entire sign-in path for a machine — there is no browser login and no
device-code flow, and cmdop login is a retired command that errors with a
pointer here. Do not hand-write token files.
Fleet owners reveal or rotate the join key under Server → Security in the web console. Rotate it whenever access must change.
Console and remote terminal access
The relay’s web console has its own administrator access, separate from the join key.
A remote terminal attach authenticates against the target machine’s own relay door and requires that machine’s connection PIN when one is armed. Your own machine’s credential is not honoured there — there is no cross-machine credential reuse for terminal access, and joining a fleet alone never grants a remote terminal session.
Only a machine reachable at its own public or custom-domain relay door can be attached to remotely at all. A LAN-only machine cannot be, which is a reachability boundary worth using deliberately.
Permission policy
Permissions gate what daemon-owned tool activity may do on a machine. Rules are matched in order with deny over ask over allow precedence, and a built-in floor of high-risk targets is always denied and cannot be overridden.
Start an unattended host in strict — everything unmatched is denied — and add
narrow rules only after testing the work it genuinely needs:
cmdop permissions mode strict
cmdop permissions allow 'execute_command(git status)'
cmdop permissions listTwo paths deliberately do not traverse this configurable gate: local interactive chat, which uses its own danger gate because you are present to answer, and inbound requests from another machine, which run under the built-in danger gate rather than your rule set. Do not treat these rules as a per-caller policy for delegated agent work.
Permissions constrain Cmdop’s tool activity. They do not replace operating-system accounts, filesystem permissions, or normal host hardening.
External MCP tools
An external MCP server is still its own trust boundary. Cmdop can discover, review, and approve a tool catalogue for a machine agent, but that approval does not secure the server process itself. If the MCP server listens over HTTP or SSE, check its SDK version, host and origin protections, authentication, and logs before approving it.
Prefer a stdio server when the tool only needs to serve the local agent that starts it. Treat any browser-reachable or network-reachable MCP server like a normal service, then approve the exact tool catalogue in Cmdop only after that surface is understood. The troubleshooting page has the concrete checklist: MCP server network boundary.
Review activity
cmdop permissions list # current rules and mode
cmdop permissions audit # recent permission decisionsCommon questions
Is it safe to let an AI agent run commands on my machine?
Tool activity is bounded by the machine’s own
permission policy, which decides what may run
before anything executes, and every decision is reviewable with cmdop permissions audit. A machine can additionally require a connection PIN before
anyone attaches. The AI acts as an operator inside those limits, not as an
unrestricted controller.
Does Cmdop open any inbound port on my machine?
No. The agent makes an outbound connection to its relay and keeps it open; nothing dials in. That means no port forwarding, no VPN, and no listening service exposed to the internet.
Can I self-host Cmdop and hold my own keys?
Yes. The relay is embedded in the cmdop binary, so you can run it yourself.
Credentials stay on your machines and in your accounts, and the several
credentials Cmdop uses are kept strictly apart, each gating exactly one thing.
Are external MCP tools covered by Cmdop permissions?
Cmdop permissions cover what a machine agent may do when it calls tools, but an external MCP server is also its own process and network surface. Review and approve the exact tool catalogue in Cmdop, and secure any HTTP/SSE server before approval. Start with the MCP troubleshooting checklist.
Reporting a vulnerability
Email [email protected] with a description, reproduction steps, and potential impact.
Cmdop