Security & responsibility

Power with permission

Your infrastructure. Your permissions. Your AI doing the work. Linux administration carries real consequences, so the owner stays in control and the system must show what it did.

Built for responsible operations

Power with
boundaries

Remote systems access is serious. We don't want AI to guess its way through your servers. RiotFleet's architecture emphasizes identity, authorization, observable execution, and recovery.

Scoped authorization

Different operators and capabilities can have different permissions.

Authenticated control paths

Remote Hands requests go through an authenticated Fleet controller and an enrolled node agent, not a public command box anyone can use.

Evidence before claims

Job submission is not proof of success. Operations should return verifiable results and explicit error states.

Preserve the existing stack

RiotFleet is designed to augment your Linux environment, not replace your OS, monitoring, or normal controls.

Reversible deployments

Backups, staged changes, validation and rollback belong in serious operational workflows.

Customer isolation

Multi-customer identity and isolation are core design requirements; availability and maturity vary by release.

A real authorization test

Permissions in practice

RiotFleet's internal October 18, 2026 test recorded both permitted Linux service operations and a denied request. These are dated engineering results—not proof that every deployment or dangerous action has been tested.

Allowed: supported service control

On an enrolled test node, authenticated requests enabled and started cockpit.socket. A separate status query returned active and listening. Internal evidence records: 420–422 and 430.

Denied: protected service

In the same acceptance exercise, a service-start request against a protected workload was denied by configured policy. Internal evidence record: 429. The denied request was not treated as permission to act.

Human authority is not optional

An AI request is not itself authorization: supported actions run within the access granted to the connection and operator. Human approval prompts for high-risk actions must be verified for a specific release and deployment; these tests do not establish a universal approval workflow.

Read the recorded allowed and denied operations. This page does not promise specific certifications, service levels, or universal compatibility.