The safety model

"An AI with console access" is a sentence that should make any admin nervous. This page lays out exactly what stands between a proposed action and your server, so you can judge it instead of trusting it.

Off by default, all the way down

Every server starts with all action classes disabled and the kill switch engaged. A freshly paired server cannot run anything. Actions only become possible after you explicitly enable a class in the Action center and arm the server. Until then, MCTotem is observe-only.

The kill switch

One control stops everything: no dispatch, no execution, regardless of class settings or pending approvals. The plugin caches the switch state and defaults to paused, and it only unpauses on a cryptographically signed control message. A network blip or a plugin restart can never spontaneously arm actions.

Every action is signed

Actions are signed with Ed25519 using a per-server keypair generated at pairing. The private key never leaves our worker and is stored sealed (AES-256-GCM); your plugin holds only the public key. The plugin verifies the signature, the expiry (10 minutes or less), and the kill switch on every action before executing. A bad signature, an expired envelope, or a paused server is rejected and reported. Delivery rides the plugin's existing outbound connection; the plugin never opens an inbound port.

The denylist is enforced twice, independently

A hardcoded command denylist (op, deop, stop, restart, ban-ip, pardon-ip, reload, execute) is absolute and overrides any allowlist you configure. It is enforced in our backend AND independently inside the plugin, so even a compromised backend could not push a denylisted command past your server. Beyond commands, denied substrings block access to secrets and privilege escalation (server.properties, rcon, ops.json, sudo, path traversal, shell metacharacters). The full list is in the action classes reference.

Two structural rules sit on top: a plugin toggle can never disable the MCTotem agent itself, and a restart request never issues a console stop.

Backups and rollback

A config edit takes a timestamped backup before touching anything, and applies its diff all-or-nothing: if any part fails, nothing is written. One click restores the newest backup. Delivery is deduplicated by action id, so a retried dispatch can never double-apply an edit.

The audit log

Every transition an action makes (proposed, approved, dispatched, executed, failed, rejected, rolled back, expired) is recorded as an immutable audit row with the actor and timestamp. You can see the full history in the dashboard. There is no code path that executes an action without leaving this trail.

What this adds up to

For MCTotem to damage your server, an action would have to be proposed by our pipeline, pass schema validation, survive the denylist twice (once on infrastructure you can decompile), carry a valid Ed25519 signature, beat a 10-minute expiry, find the kill switch disarmed, and get past your own approval unless you opted that class into auto-run. That chain is the answer to "is it safe to let it act".

The safety model

On this page