Command & Control
Two related things live under this name, and they are at very different stages: a real, operationalsecurity mediation pipeline that already governs every active KAI OS capability, and Desktop Operator -- a real, extensively-tested, but not-yet-activated scaffold for future controlled desktop interaction. This page keeps them clearly separate rather than letting one borrow the other's credibility. Generated August 11, 2026. Generated from the KAI OS repository during the latest website data-sync run. Not live.
Every stage below is real architecture, not a diagram invented for this page. Status reflects what's actually true of that specific stage today -- not the pipeline as a whole.
An agent or a human operator states what it wants to do -- a specific capability, on a specific target, for a stated reason.
For desktop-level tasks: a synthetic task planner breaks the request into steps before anything is attempted. Real scaffold, not live.
The request is checked against a default-deny SecurityPolicy -- an agent can only act within a capability it has been explicitly, individually granted.
The exact capability requested is independently re-evaluated against the policy on every single call -- never cached, never trusted from a prior check.
LOW-risk capabilities proceed without a human in the loop; anything classified higher-risk requires an explicit human approval gate before execution.
Only one code path is allowed to actually call an agent's execute() method -- the ControlledExecutor. Nothing else in the system is permitted to bypass it.
Content-safety scanning and filesystem-boundary checks run against the actual result before it's accepted -- rejecting the record if a check fails, not just logging a warning.
Every outcome -- allowed, denied, rate-limited, kill-switched, or failed -- is written to an append-only audit log with secrets redacted, whether or not the action itself succeeded.
The default-deny policy, capability check, approval gate, controlled execution chokepoint, content-safety validation, and audit logging are real, tested, and actively enforced -- right now, for every one of the 3 active capabilities. This is not a simulation and not a future plan.
Real, extensively tested architecture -- not yet wired to observe or control anything live. The package's own module documentation explicitly states it does not yet activate automation.
Approval and kill-switch gating are foundational design principles built into the architecture from the start, ahead of any live automation.
Desktop Operator has real code for task planning, controlled adapters, execution simulation, screenshot-based observation, and a human review queue -- each with its own dedicated test suite. None of it is wired to observe or control a real desktop today. That's a deliberate build order: the approval gating, kill switches, and audit trail were built before any live automation, not added afterward. The package's own module documentation states this directly, not as a caveat buried in a report -- it's the first thing it says.
Nothing on this page claims Desktop Operator currently observes, clicks, types into, or otherwise controls this machine or any other. When that changes, it will change here first.
This page will be updated the moment any part of Desktop Operator moves from "In Development" to live -- not retroactively, not in a batch with unrelated changes.