Operator Actions & Human Approval

Mutating work against Acme Corp endpoints lands on Actions. A human reviews the payload, Approves & runs or Rejects, and the timeline keeps the handoff.

What operators buy is not only remote access: it is clear, attributable history of work that crossed a human decision. Cohort 01 keeps humans in that loop by default.

The approval transaction

Every consequential request should read as one path:

Request (human or AI) → plan → HITL review → execute → verify → resolve

Example: an AI agent proposes installing Chrome on every laptop at Acme HQ. FlowRMM MCP queues a restricted package request. An operator sees named requester, Scope, Impact, targets, and plan on Actions, then Approves & runs or Rejects. Agents execute; verification and audit stay available on portal and mobile Actions/Activity.

Requester and approver show as people, not anonymous GUIDs, when the operator directory is seeded from portal seats.

What waits for a human

FlowRMM separates information gathering from environment change:

Structurally safe reads (validated whole-command) may run without a per-run decision.
Raw mutations, sensitive reads, unclassified syntax, and gated runbooks queue on Actions.
Blocked patterns are rejected before an approval item is minted.

Authorization / HITL, Scope, and Impact are separate labels on the review surface:

Decision	Question
Authorization / HITL	May this run now, or must a person approve?
Scope	Who or what is affected? (endpoint, site, client, group, company, …)
Impact	What disruption could it cause? (`low` → `urgent`)

Caller-supplied assessment text never grants authority. The server revalidates the command or reviewed runbook at dispatch.

Review on Actions

Restricted work moves through PENDING → APPROVED / REJECTED → DISPATCHED → COMPLETED / FAILED.

The Actions page is a review surface: queue on the left, payload / output / audit timeline on the right. Approve, Reject, and Retry appear only when a decision is still needed. Mobile Inbox uses the same approval rules (including four-eyes); it cannot weaken policy.

Default production posture is four-eyes: approver differs from requester. Governance can allow HITL self-elevate only for selected client environments (or Unassigned) when every target is in an allowed environment.

Bounded autonomy (still reviewed)

Governance Action autonomy may auto-approve selected low/medium Impact kinds in scoped environments. High and urgent stay human. Raw run_command changes remain HITL.

A saved, reviewed runbook is the explicit exception:

observe diagnostics may dispatch without per-run HITL when policy allows.
remediate_within_bounds may dispatch on one exact endpoint only.
Reboot, user-presence, urgent Impact, human_only, and blocked always stay gated.
MCP request_runbook_execution is stricter: it always creates a human-required request.

Runbook autonomy decides whether a step *may* skip HITL; the caller’s role decides whether *this* token may dispatch it. Both must agree. Prefer the narrow runbook.autonomous role for reviewed-runbook dispatch instead of over-granting actions.execute.

Guardrails and MCP

Policies classify tools as allowed (observation under whole-command validation), restricted (needs Approve & run), or blocked.

MCP clients share the same Actions queue:

Inspect → request for mutations.
Human review → Approve & run or Reject.
FlowRMM executes the approved immutable action and keeps the audit trail.

Request-only tools (request_package_install, request_package_uninstall, request_runbook_execution) do not approve or dispatch even when the MCP identity also has actions.execute.

What this public guide skips

Private PROTOCOL routes, Key Vault keyring rotation, and dense agentic-triage internals stay out of the marketing docs. Use this page to judge the Approve & run path on Acme Corp endpoints in your Cohort 01 environment.

Related guides

Want hands-on help evaluating Cohort 01? Book a demo or apply for Cohort 01.