RIO: Runtime Intelligence Orchestration

Runtime Intelligence Orchestration (RIO) is a fail-closed authorization and audit protocol designed to govern autonomous AI agents. As AI systems transition from passive advisors to active participants in digital environments — capable of moving funds, managing infrastructure, and accessing sensitive data — the risk of unaligned or malicious execution increases.

RIO addresses this by decoupling the "intelligence" of the agent from the "authority" to execute. Built on a Three-Loop Architecture (Intake/Discovery, Execution/Governance, Learning), RIO translates goals into structured intents, enforces policy and approvals before execution, controls and verifies actions, generates v2 cryptographic receipts with intent_hash, action_hash, and verification_hash, and maintains an immutable signed ledger. The Learning Loop feeds outcomes back into policy refinement without bypassing governance.

The rapid advancement of Large Language Models (LLMs) has birthed a new era of autonomous agents. These agents are no longer confined to chat interfaces; they are integrated into business workflows via APIs, database connectors, and cloud infrastructure. However, this integration introduces a critical "speed asymmetry": AI can propose and attempt actions at machine speed, while human oversight remains at human speed.

Traditional security models — such as prompt engineering, system instructions, or model alignment — are advisory. They rely on the AI's "willingness" to follow rules. In a production environment, this is insufficient. A single hallucination or prompt injection can lead to irreversible consequences, such as unauthorized financial transfers or data breaches.

RIO shifts the paradigm from advisory to structural governance. It treats AI as an untrusted requester and places a hard execution gate in front of every sensitive action. By requiring a cryptographic "proof of approval" at the moment of execution, RIO ensures that the human remains the ultimate authority, without sacrificing the efficiency of AI-driven orchestration.

RIO is built on a Three-Loop Architecture that governs the complete lifecycle of AI-driven actions:

The Intake / Discovery Loop translates vague goals into structured intents before governance begins. It validates incoming requests, detects missing information, uses AI-assisted refinement to clarify ambiguous goals, and produces a well-defined structured intent. Also known as the Intake Translation Layer, Universal Grammar Layer, or Goal-to-Intent Layer.

The Execution / Governance Loop controls and authorizes all actions before execution. It enforces policy evaluation, risk scoring, human approval workflows, execution gating, post-execution verification (computing intent_hash, action_hash, and verification_hash), v2 receipt generation, and signed ledger recording. No execution occurs without authorization. All actions produce receipts. All receipts are recorded in the ledger.

The Learning Loop improves future decisions and governance policies. It analyzes patterns from the audit trail, proposes policy updates, and enables replay/simulation. Learning cannot bypass governance, cannot execute actions directly, and policy updates must go through governance before deployment.

The system is fail-closed by design. If any component cannot positively verify a required condition, the execution gate remains locked. This ensures that no action is ever taken in an unrecorded or unauthorized state.

RIO enforces governance through the pipeline within the Execution/Governance Loop. Each stage produces a specific data structure that is passed to the next, ensuring a continuous chain of custody:

1. Intake — The AI agent submits a raw intent (or vague goal, which is refined by the Intake/Discovery Loop). 2. Discovery & Refinement — If the request is vague, AI-assisted refinement produces a structured intent. 3. Classification — The system identifies the action type and assigns a risk category. 4. Policy & Risk Evaluation — The Policy Engine checks the intent against active rules. A risk score is calculated. 5. Authorization — If the risk exceeds the threshold, a human approver is notified. Upon approval, an Execution Token is generated. 6. Execution Gate — The gate verifies the token signature, timestamp, nonce, and kill switch. 6b. Post-Execution Verification — Computes intent_hash, action_hash, and verification_hash (SHA-256) to cryptographically bind intent to action. 7. v2 Receipt Generation — A signed receipt is generated containing all hashes, risk data, policy decision, and three ISO 8601 timestamps. 8. v2 Ledger Entry — The receipt is recorded in the signed hash-chained ledger with its own ledger_signature.

Denial receipts are generated for blocked or denied actions, ensuring the audit trail covers every decision — not just successful executions.

The RIO protocol is governed by ten core invariants that must be maintained at all times:

No Execution Without Authorization — No action can be performed unless a valid, unconsumed Execution Token is presented. No Authorization Without Policy Check — An Execution Token can only be generated after the Policy Engine has evaluated the intent. Fail-Closed Enforcement — Any failure in a dependency must result in a blocked action. Single-Use Approvals — Every Execution Token and its associated signature are single-use. Cryptographic Binding — The signature must be bound to the exact payload presented for approval.

Timestamp Freshness — Execution Tokens have a maximum lifespan (default 300s). Every Action Produces a Receipt — Every execution attempt, whether successful or blocked, must generate a cryptographic receipt. Tamper-Evident Audit Trail — All receipts must be recorded in a hash-chained ledger. Identity Attribution — Every action must be attributed to both the requesting agent and the authorizing human. Immutable History — Ledger entries cannot be modified or deleted.

RIO v2 uses a multi-layered cryptographic model to ensure that the audit trail is both authentic and tamper-evident.

A v2 receipt is a JSON object containing: receipt_id, intent_id, action, requester, approver, decision, execution_status, risk_score, risk_level, policy_decision, intent_hash (SHA-256 of intent + action + requester + timestamp), action_hash (SHA-256 of action + parameters), verification_hash (SHA-256 of intent_hash + action_hash + execution_status), verification_status, three ISO 8601 timestamps (request, approval, execution), receipt_hash, signature (Ed25519), previous_hash, and protocol_version.

The v2 ledger is a signed hash chain where each entry E_n contains: block_id, receipt_id, receipt_hash, previous_hash, current_hash (H_n = SHA256(E_n.data + H_(n-1))), and ledger_signature (Ed25519). This structure ensures that any modification to any entry invalidates all subsequent hashes, and the per-entry signature provides independent verification. The Receipt Verifier and Ledger Verifier enable independent audit of individual receipts and the full chain.

RIO is designed to mitigate critical threats in autonomous AI environments: Unauthorized Execution (mitigated by service boundary + service-to-service auth), Ledger Tampering (mitigated by hash-chained ledger entries), Token Reuse (mitigated by single-use nonce/signature registry), Privilege Escalation (mitigated by independent ECDSA signature verification), Kill Switch Bypass (mitigated by fail-closed design), and Missing Audit Trail (mitigated by ledger write as a prerequisite for execution).

Policies are defined as a set of rules that map actions and parameters to risk levels. The engine evaluates intents in real-time, returning a verdict of ALLOW, BLOCK, or REQUIRE_APPROVAL.

Risk is calculated using a 4-component scoring model: Base Risk (inherent risk of the action type), Role Modifier (adjusts based on the agent's role), Amount Modifier (scales based on financial or data volume), and Target Modifier (adjusts based on target system sensitivity).

Policies follow a strict versioning lifecycle: PROPOSED → APPROVED → ACTIVATED → INACTIVE (or ROLLED_BACK). Only one policy version can be ACTIVATED at any time, ensuring deterministic evaluation.

The Learning Loop is the third loop in RIO’s Three-Loop Architecture. It records all system interactions in a Governed Corpus, providing a rich dataset for learning and policy refinement.

The Replay Engine can replay historical intents through the pipeline in three modes: Exact Replay (verifies the system produces the same result), Modified Policy (simulates how a new policy would have handled past intents), and Modified Role (tests how different role assignments would change outcomes).

The Policy Improvement Loop follows four steps: Record (capture intents and outcomes), Analyze (identify patterns of friction or risk), Simulate (test new rules against the corpus), and Deploy (activate refined policies with confidence). Critically, the Learning Loop cannot bypass governance: all policy updates must go through the Execution/Governance Loop before deployment, and the Learning Loop cannot execute actions directly.

Invoice Payment Approval — A finance agent identifies an outstanding invoice. RIO intercepts the payment request, requiring a Manager's approval for any amount over $1,000.

GDPR Data Deletion — An agent tasked with data privacy receives a deletion request. RIO ensures the deletion is logged and verified against the correct user ID before execution.

Production Deployment — A DevOps agent proposes a code deployment. RIO requires a Director-level signature, ensuring that no code reaches production without a human "go" decision.

Access Provisioning — An HR agent requests system access for a new hire. RIO validates the request against the employee's role and requires Admin approval for privileged access.

Agent-to-Agent Delegation — A personal assistant agent asks a travel agent to book a flight. RIO gates the final payment, ensuring the user approves the cost and itinerary.