Skip to main content

​
The Harness

Kernel CLI is the body. NIIA is the gate. That separation lets one OS capability surface serve humans, scripts, MCP clients, and agents without pretending that raw capability is the same thing as permission to use it.

Kernel CLI

Read the canonical product overview, workflows, platform boundaries, and reference before using the control surface.

​
Why a Gate Exists

Direct Kernel CLI writes execute immediately. A command can press a button, type text, send a key, change a window, run a platform script, or alter system state without asking NIIA for approval. This is brave mode: the user has intentionally exposed the raw binary to a human, script, or agent.
The raw binary also maintains a local mutating-command audit log by default. That log is evidence after execution; it is not an authorization boundary and does not stop a write.

​
NIIA Owns the Policy Layer

NIIA invokes the standalone Kernel CLI body while keeping the permission gate in NIIA. The layers remain independently inspectable:
This distinction matters during upgrades and debugging. A current NIIA harness does not prove that the installed Kernel CLI binary is current, and a healthy Kernel CLI binary does not prove that NIIA has granted control.

​
The Current Command Contract

The installed NIIA surface separates read and write commands: Read-only does not mean non-sensitive. Accessibility trees, screenshots, clipboard data, app databases, and logs can reveal private information even when they do not modify the machine. A product may apply additional policy to those reads.

​
The Human-Gated Flow

The agent should not obtain, infer, or enter the OTP on the human’s behalf. The human participation is the point of the control boundary.

​
Scope and Time

niia control unlock supports a bounded scope and duration:
The available durations are 10m, 30m, 1h, and 4h. full covers observe and write authority; the harness can keep sensitive observation policy separate from control policy. Use the shortest practical duration and call niia control lock when the task finishes instead of waiting for expiry.

​
What the Harness Does

The harness can:
  • require an explicit human authorization step before control,
  • limit authorization by scope and time,
  • keep read and write command surfaces separate,
  • refuse a mutating command while locked,
  • revoke an active grant,
  • preserve a visible boundary between policy and capability.

​
What the Harness Does Not Prove

An unlocked harness does not guarantee that an OS action will work. The target machine may still lack:
  • the expected Kernel CLI version,
  • Accessibility, Screen Recording, or protected-data permission,
  • an interactive desktop session,
  • Linux AT-SPI or helper tools,
  • Windows UI Automation visibility or OCR language support,
  • a fresh target handle,
  • an app state that supports the requested semantic action.
Run the raw health probe before diagnosing the harness:
Then inspect the policy state:
Those outputs prove different layers and should not be collapsed into one “works” or “does not work” conclusion.

​
Brave Mode and Harnessed Mode

The capability can be the same while the access model is different.

​
The Deeper Pattern

A body answers, “what can this system do?” A harness answers, “who may ask it to do that, under what conditions, and for how long?” Keeping those questions separate is what makes the boundary inspectable. Kernel CLI can remain complete. NIIA can remain strict. The human can see which layer granted capability and which layer granted authority.

Kernel CLI Workflows

Use direct and NIIA-gated observe, dry-run, act, and verify loops.

Kernel CLI Reference

Check permissions, platform behavior, audit, embedded docs, and MCP setup.