> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monolex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# The Harness

> How NIIA separates Kernel CLI's raw operating-system capability from human-authorized, time-limited control.

# 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.

<Card title="Kernel CLI" icon="microchip" href="/kernel-cli">
  Read the canonical product overview, workflows, platform boundaries, and
  reference before using the control surface.
</Card>

## 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.

```text theme={null}
Direct kernel-cli
      ↓
Raw OS capability
      ↓
Immediate read or write
```

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:

```text theme={null}
Human / agent request
        ↓
NIIA observe or control policy
        ↓
Kernel CLI capability
        ↓
Operating system
```

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:

| Surface                 | Purpose                                           | Gate                           |
| ----------------------- | ------------------------------------------------- | ------------------------------ |
| `niia observe`          | Read-only OS observation exposed by the harness   | The command set is read-only   |
| `niia control status`   | Inspect observe/control lock state                | No write                       |
| `niia control unlock`   | Ask the human to authorize a scope for a duration | Human OTP step                 |
| `niia control <action>` | Perform a mutating OS action                      | Requires a valid control grant |
| `niia control lock`     | Revoke the active grant                           | Explicit revocation            |

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

```bash theme={null}
# 1. Read the live interaction map
niia observe targets --app "TextEdit" --json

# 2. Inspect current lock state
niia control status

# 3. Human authorizes control for a bounded time
niia control unlock --scope full --duration 30m

# 4. Resolve the write without actuating
niia control act '<target_id>' \
  --snapshot '<snapshot_id>' \
  --dry-run \
  --json

# 5. Act once, then verify through a fresh observation
niia control act '<target_id>' --snapshot '<snapshot_id>' --json
niia observe targets --app "TextEdit" --json

# 6. Revoke the grant
niia control lock
```

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:

```bash theme={null}
niia control unlock --scope observe --duration 10m
niia control unlock --scope full --duration 1h
```

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:

```bash theme={null}
kernel-cli --version
kernel-cli --json doctor
```

Then inspect the policy state:

```bash theme={null}
niia control status
```

Those outputs prove different layers and should not be collapsed into one
"works" or "does not work" conclusion.

## Brave Mode and Harnessed Mode

|                             | Direct Kernel CLI                              | NIIA harness                                             |
| --------------------------- | ---------------------------------------------- | -------------------------------------------------------- |
| Capability body             | Kernel CLI                                     | Kernel CLI                                               |
| Human approval before write | No                                             | Yes, through unlock                                      |
| Scope and expiry            | Caller-managed                                 | Harness-managed                                          |
| Local command audit         | Available                                      | Separate from authorization                              |
| Best fit                    | Human CLI use, controlled scripts, diagnostics | Agent control, shared machines, human-approved workflows |

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.

<CardGroup cols={2}>
  <Card title="Kernel CLI Workflows" icon="route" href="/kernel-cli/workflows">
    Use direct and NIIA-gated observe, dry-run, act, and verify loops.
  </Card>

  <Card title="Kernel CLI Reference" icon="book" href="/kernel-cli/reference">
    Check permissions, platform behavior, audit, embedded docs, and MCP setup.
  </Card>
</CardGroup>