> ## 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. # Physical Harnessing: OTP and Policy > How NIIA adds a human OTP step to software policy before time-limited Kernel CLI control. # Physical Harnessing: OTP and Policy Every AI safety mechanism in 2026 has one thing in common: it lives inside the AI's execution environment. YAML policies. Prompt instructions. Configuration files. Sandbox rules. The AI can read them. The AI runs inside them. And what AI can read, AI can — in theory — circumvent. NIIA's OTP adds a different factor: a human completes an authorization step outside the agent's normal command and policy loop. ## The Problem with Software Harnessing ``` YAML policy (NVIDIA OpenShell): File on disk → AI's sandbox reads it → enforces rules Attack: modify the file, escape the sandbox, exploit the policy parser Prompt rules (Claude Computer Use): System prompt → "always ask permission before accessing new apps" Attack: prompt injection overrides system prompt Config file (Codex sandbox): JSON config → defines writable paths, network rules Attack: the AI generates a command that the policy doesn't anticipate All three: The constraint and the constrained run in the SAME environment. Sophisticated enough AI can find the gap. ``` Software policy remains necessary, but the policy and the authorization factor should not be treated as the same control. ## Physical vs Software Constraints ``` Software constraint: Rule lives in AI's environment → AI can potentially interact with it Strength: as strong as the implementation Weakness: same-environment attacks (injection, escape, manipulation) Human authorization factor: Approval is completed outside the agent's normal execution loop Strength: independent factor before a bounded grant Weakness: requires human action (slower) ``` A locked door is harder to bypass than a "please don't enter" sign, no matter how sophisticated the reader is. ## How NIIA OTP Works ``` 1. AI (or human) requests elevated access: $ niia control unlock --scope full --duration 1h 2. NIIA server sends OTP to human's email: [email] Your OTP: 847291 (expires in 5 minutes) 3. Human enters OTP in terminal: $ Enter OTP: 847291 4. Access granted for specified scope and duration: [unlocked] scope=full, expires=2026-04-01T12:00:00 5. After duration expires: [locked] All control commands blocked again. ``` The intended OTP flow uses a channel reserved for the human: * The human's email account * On the human's device * Protected by the human's authentication This separation only holds when the OTP channel and entry step are not also delegated to the agent. The agent should not retrieve, infer, or enter the OTP on the human's behalf. ## Attack Surface Comparison | Control | What it helps with | What it does not replace | | --------------------- | --------------------------------------------- | --------------------------------------------------------------------------------- | | Prompt rules | Intent and behavior guidance | Runtime enforcement | | Sandbox/config policy | Filesystem, process, and network boundaries | Human approval for a specific OS write | | Human OTP step | Explicit authorization before a bounded grant | OS permissions, target verification, phishing resistance, or safe workflow design | OTP is one factor in a layered design. It reduces self-approval risk only when the human channel remains separate and the human verifies what is being authorized. ## Two-Layer Architecture NIIA separates capability from control into two independent binaries: ``` kernel-cli (raw capability): Exposes OS observation, control, and machine telemetry. No NIIA approval gate; OS permissions and runtime limits still apply. = The engine. niia observe/control (harness): Read-only observe surface + OTP-gated, time-limited control. Selected Kernel CLI capabilities behind human authorization. = The steering wheel + brakes + seatbelt. ``` ``` Other tools: ┌─────────────────────────────┐ │ Capability + Constraint │ │ same binary, same context │ └─────────────────────────────┘ AI can inspect both NIIA: ┌─────────────────┐ ┌──────────────────┐ │ kernel-cli │ │ niia control │ │ (capability) │ │ (harness) │ │ raw capability │ │ OTP-gated │ └─────────────────┘ └──────────────────┘ ↑ ↑ Body performs Human authorizes the operation the control scope ``` The agent may request an unlock, but it must not complete the human OTP step. The human controls the grant. The harness gates the capability. ## Why This Matters More Over Time ``` 2024: AI is helpful but limited. Software constraints are sufficient. AI can't bypass a well-written YAML policy. 2025: AI is capable and autonomous. Software constraints mostly work. Edge cases emerge. Some policies are circumvented. 2026: AI agents control desktops, write code, deploy to production. Software constraints are necessary but not sufficient. 80% of orgs report risky agent behavior. 2027+: AI is deeply integrated into infrastructure. Software constraints become the weak link. Physical constraints become the standard. ``` The smarter AI gets, the better it gets at finding gaps in software constraints. Physical constraints don't have gaps — they have locks. ## In connector.json ```json theme={null} { "agents": [ { "model": "claude", "capabilities": { "pty": true, "kernel": { "observe": true, "control": { "allowed": ["ax-press", "key", "type"], "requires_otp": true, "scope": "deploy-workflow", "max_duration_ms": 3600000 } } } } ] } ``` The connector.json declares what the agent CAN do. The OTP determines WHETHER it can do it right now. The declaration is software. The gate is physical. ## Summary ``` Software policy: Rules constrain the allowed execution surface NIIA OTP: Human authorization unlocks a bounded capability Neither layer replaces the other. The OTP channel must remain outside the agent's control. This is the difference between "the workflow permits this" and "the human authorized this now." ``` A note on the word: the harness in this spec is the **control** sense — a gate designed to keep authorization outside the agent's normal execution loop. That boundary depends on keeping the OTP channel and entry step human-controlled. The philosophy docs use the same word for the **memory** harness (monomento, monoflow, niia), whose goal is the inverse: removing the *felt* boundary between the human and the AI layer — see [Monobrain: The Unnamed Conversation](/articles/philosophy/monobrain). One harness hardens the edge of action; the other dissolves the edge of identity.